SMART/FHIR x PHR

[Luiz Omori]

Hi,

Any thoughts about exposing data (in/out) from the technologies below through SMART/FHIR?

1) Microsoft's HealthVault: interesting discussion here http://www.healthintersections.com.au/?p=2070 (from Grahame).

2) Google's Fit: more like a "fitness" record per Google policy https://developers.google.com/fit/overview -> Responsible use of Google Fit

3) Apple's HealthKit: not really a Patient Health Record system as seen elsewhere. All data stored only on the user's iPhone.

Another thing, perhaps more challenging, is how could that exposed data be shared between users and providers? Personally I find HealthVault's way interesting.

Regards,

Luiz

[Adrian Gropper]

The simple question is who controls a FHIR API - the patient or the host? This question applies just as much to HealthVault, Google, HealthKit as it does to Epic and athenaHealth.

This is not really about FHIR. It came up in BlueButton Plus where we decided that hosts MUST implement dynamic registration. Now we have the discussion again, this time on THCB: http://thehealthcareblog.com/blog/2015/11/11/interoperability-accelerating-faster-than-we-think-an-interview-with-ed-park/#comment-847823

Adrian

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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/

[Josh Mandel]

Hi Luiz,

Thanks for the question! To the extent that all three of these services provide built-in APIs and support storage/query of structured data, it's possible to build SMART/FHIR bridges around them. Specifically, it's possible for the organizations providing the services (MS, Google, Apple) to build this functionality, or it's possible for motivated third parties to do likewise.

When it comes to app registration (to Adrian's point), the models vary. For Android, anyone can write an app and publish it via the Play store (though this does involve a manual registration process rather than a registration API). For iOS, there is an annual "developer program" fee (but not a per-app registration fee), plus an approval process. For HealthVault, I don't know the process (https://msdn.microsoft.com/healthvault/go-live is not entirely clear; it states, "Once the alignment between HealthVault and Microsoft Health is complete, we will update this page").

Best,

  Josh

On Thu, Nov 12, 2015 at 1:43 PM, Luiz Omori <luiz....@gmail.com> wrote:

--

[Luiz Omori]

Thanks Adrian and Josh.

 

Adrian made a good point regarding who owns the API, or who really controls the data. Going a bit of the side regarding the initial question, it would be interesting but probably a bit hard on the practical side if there were a public FHIR based PHR with UMA to centralize all non-EHR collected (e.g. Microsoft Band 2, FitBit, etc) which could be shared by the patient like in the HEART protocol. All the pieces here like OAuth2 UMA, HEART, FHIR seem to align well for that.

EHR<->EHR

 /\            /\

 |             |

 \/            \/

   PHR

If fact this PHR could also per patient request receive EHR data and thus become a central piece.

Here at Duke we are investigating a way to have easier access to some types of user collected data coming from a variety of user owned sensors. This may in some cases help provide a broader patient health view instead of punctual and sporadic Dr. visit measurements. PHR+FHIR may provide a more standard way to do that.

Regards,

Luiz

[Adrian Gropper]

Yes, Luiz,

What you're suggesting is exactly what we tried to show with the Privacy on FHIR pilot at HIMSS this year. Patient-directed exchange, as in HEART, may be the only way to cross the HIPAA CE to wearable bridge. The role of the PHR is optional. In a patient-directed exchange model, the wearable vendor can decide to implement FHIR and UMA directly and this makes the data available to the HIPAA CE without delay or loss of provenance.

Adrian

[Luiz Omori]

Thanks Adrian. I can see EHR to EHR working well with HEART, records being transferred using Blue Button/C-CDA but the information is still disperse. One (old) aspect s the storage and centralization of all this information, something Apple/Google/Microsoft have been trying to address with their own initiatives. It would be interesting if we had Personal Health Record Exchanges (PHRX) which would work as storage and brokers so in addition to supporting to/from EHR data transfer, personal sensors too (some of them may not be wearables per se) could send data to and shared per your patient-directed exchange model. Ideally those would be vendor neutral and even healthcare provider independent. The user would choose a PHRX according to her preferences and hopefully use it to centralize all her records to be shared with any provider.

All of that is not new, but maybe with big healthcare vendors working with FHIR, new security standards (OAuth2 UMA), etc, it becomes a bit easier, certainly less vendor dependent.

Regards,

Luiz

To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhir+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Adrian Gropper]

It's easy to understand HEART once you adopt the JASON perspective of separating data storage from data access authorization. Once you do that, the way to interop for all sorts of data sources (EHR, PHR, wearable, implant) becomes much easier to understand in both clinical and research use-cases.

The only thing HEART has in common with Blue Button and C-CDA is that a HEART FHIR resource also applies to _only one patient_. HEART is not about a data model or format in the sense that BB is structured text and C-CDA is XML. HEART is purely about FHIR and other restful APIs when these APIs pertain to a single patient. This single patient is the UMA Resource Owner, or the legal Principal, or the research Subject, or the Patient, or the person named Alice.

In HEART, a data storage entity (hospital, personal health records biz, wearable cloud, substance abuse treatment clinic) is willing to expose resources via a FHIR API that accepts authorization tokens one patient per resource. A single patient can have multiple resources, of course.

Once one accepts the separation of storage from authorization on the basis of single-patient resources, the discussion shifts to: What or who is the data access authorization server? There are two possible answers: Either it's the patient's own personal AS or it's some entity that is not controlled directly by the patient. In the latter case, where a single entity (e.g.: a Health Information Exchange, Epic, athenaHealth, Apple) is delegated to control access, the question becomes what governance mechanism applies to the entity and can it cover exchange across HIPAA, research, 42CFR part 2, and wearables boundaries?

HEART is designed to handle both the personal AS and the shared AS alternatives for data access authorization. FHIR, as long as it provides resources that pertain to only one patient, can be totally agnostic to what kind of AS each patient chooses. There's no reason to build any governance or policy structure into the FHIR standards. Governance and policy can live in a separate authorization layer like HEART. That's the JASON model.

The same thing that applies to data storage applies to data consumers such as apps. As long as the app is designed to work on one patient context at a time, then its FHIR API simply has to play well with whatever authorization server is protecting a particular resource.

Adrian

--

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/

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--