<div dir="ltr">Adrian,<div>  </div><div>   CareEvolution offers both tethered and un-tethered patient portals / apps supporting SMART-on-FHIR. Recently we participated in an <a href="http://www.healthdatamanagement.com/news/demo-shows-fhir-can-enable-exchange-of-patient-med-information" target="_blank">ONC-sponsored project</a> that consisted in implementing something similar to the HIE of One scenario - albeit with transfer in only one direction (from the EHR = mdNOSH to the app = pNOSH). As part of that project we were the only vendor that acted as both sides: app and EHR. </div><div><br></div><div>The demo clearly showed what you call '<span style="font-size:12.8px">Portalosis</span>' - the user  has to remember and use various logins for each participating portal, so I am looking around for possible alternative approaches.</div><div><br></div><div>It seems to me that HEART has something missing / under-specified regarding patient selection and patient IDs sharing. It also look really complex to implement on top of an existing system.</div><div><br></div><div>   Regards</div><div><br></div><div>  - Michele</div><div>  CareEvolution Inc</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 28, 2016 at 12:52 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Michelle,<div><br></div><div>I really appreciate you raising this issue. The point of having a open source reference implementation for HEART would be to inform and help others with real-world data and commercial offerings. I defer the technical discussion to the coders.</div><div><br></div><div>Some of how HEART deals with patient ID interacts with solving the multiple portals problem (Portalosis, per Casey Quinlan, I think). HEART hopefully allows aggregation across separate unaffiliated FHIR endpoints some of which are tethered and others are not. Tethered or not, a FHIR endpoint that serves multiple patients will need a patient ID solution as part of resource registration with an UMA Authorization Server.</div><div><br></div><div>What should we call the solution to Potalosis? Is it a unified FHIR-accessible portal or a unified UMA Authorization Server (that has no FHIR API at all)? I admit that HIE of One is unclear about this distinction because in our case _both_ the FHIR-accessible unified portal (pNOSH) and the UMA Authorization Server (HIE of One) are dedicated to a single patient. In the model we're implementing as HIE of One, a minor child would still have her own separate pNOSH and HIE of One.</div><div><br></div><div>HEART needs to be more general than the HIE of One reference implementation. In some cases, the unified entity that solves Portalosis will be just the patient-specified UMA AS and FHIR endpoints will be tethered to various institutions, vendors, or family PHRs.</div><div><br></div><div>In other cases, the unified entity will be a patient-specified longitudinal health record with a FHIR endpoint and a patient may still have to interact with multiple authorization servers. This situation is familiar to users of today's HIEs or systems like CommonWell that avoid having a patient portal at all and expect the consent (authorization) to be managed by the various FHIR endpoints. These systems do not currently support longitudinal health records in any obvious way - such as by allowing the patient to specify a preferred FHIR endpoint - be it tethered or not.</div><div><br></div><div>The recently presented VA Privacy on FHIR use case proposes one solution to Portalosis. It involves cascading authorization servers and a patient-specified consent server that may or may not be separate from the patient-specified authorization server. I'm very glad the VA has stepped up to the implementation level and look forward to making their approach compatible with HIE of One under the thing we call HEART.</div><div><br></div><div>Where is CareEvolution in this spectrum?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Adrian</div><div><br></div></font></span></div></blockquote></div></div></div>