[Openid-specs-heart] FHIR patient ID question

[Michele Mottini]

Adrian,

   CareEvolution offers both tethered and un-tethered patient portals /
apps supporting SMART-on-FHIR. Recently we participated in an ONC-sponsored
project
<http://www.healthdatamanagement.com/news/demo-shows-fhir-can-enable-exchange-of-patient-med-information>
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.

The demo clearly showed what you call 'Portalosis' - the user  has to
remember and use various logins for each participating portal, so I am
looking around for possible alternative approaches.

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.

   Regards

  - Michele
  CareEvolution Inc


On Wed, Dec 28, 2016 at 12:52 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161228/7ba4ed4e/attachment.html>