<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><div><br></div><div>Adrian</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 27, 2016 at 6:31 PM, Michael Chen <span dir="ltr"><<a href="mailto:shihjay2@gmail.com" target="_blank">shihjay2@gmail.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">Actually, our demo HIE of One will work even in your scenario if your PHR is setting resources with it properly.<br><div><br></div><div>You can set a specific scope of <a href="https://shihjay.xyz/PHR/fhir/Condition?subject:Patient=1" target="_blank">https://shihjay.xyz/PHR/fhir/<wbr>Condition?subject:Patient=1</a> for Alice that has a certain set of permissions different from Bob where <a href="https://shihjay.xyz/PHR/fhir/Condition?subject:Patient=2" target="_blank">https://shihjay.xyz/PHR/fhir/<wbr>Condition?subject:Patient=2</a>.</div><div><br></div><div>The client EMR/Health App would have to confirm the presence of said patient (with the call mentioned above) first to make sure any subsequent calls are not going to be rejected due to inadequate permissions.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 27, 2016 at 2:57 PM, Michele Mottini <span dir="ltr"><<a href="mailto:mimo@careevolution.com" target="_blank">mimo@careevolution.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">Ah, I see, thanks<div><br></div><div>This would not work with our PHR though, because a user can have access to multiple patients (e.g. Alice can access her son Bob), so the <a href="https://shihjay.xyz/nosh/fhir/Patient" class="m_2833033494769478834m_-7131190615959497770gmail-m_1252525858403073684gmail_msg" style="font-size:12.8px;word-spacing:1px" target="_blank">https://shihjay.xyz/nosh/f<wbr>hir/Patient</a>' call could return multiple patients.</div><div><br></div><div>  - Michele</div><div>  CareEvolution Inc</div><div><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>