[Openid-specs-heart] FHIR patient ID question

Adrian Gropper agropper at healthurl.com
Wed Dec 28 17:52:05 UTC 2016


Michelle,

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.

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.

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.

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.

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.

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.

Where is CareEvolution in this spectrum?

Adrian


On Tue, Dec 27, 2016 at 6:31 PM, Michael Chen <shihjay2 at gmail.com> wrote:

> Actually, our demo HIE of One will work even in your scenario if your PHR
> is setting resources with it properly.
>
> You can set a specific scope of https://shihjay.xyz/PHR/fhir/
> Condition?subject:Patient=1 for Alice that has a certain set of
> permissions different from Bob where https://shihjay.xyz/PHR/fhir/
> Condition?subject:Patient=2.
>
> 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.
>
>
>
> On Tue, Dec 27, 2016 at 2:57 PM, Michele Mottini <mimo at careevolution.com>
> wrote:
>
>> Ah, I see, thanks
>>
>> 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
>> https://shihjay.xyz/nosh/fhir/Patient' call could return multiple
>> patients.
>>
>>   - Michele
>>   CareEvolution Inc
>>
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161228/87cff1ec/attachment.html>


More information about the Openid-specs-heart mailing list