201709 Consumer Centered Data Exchange

Consumer Centered Data Exchange

Submitting WG/Project/Implementer Group

FHIR Product Director, in association with Society for Participatory Medicine, MIHIN, NATE, DXC. Interested committees: FHIR-I, CBCC, Security, PA, PC, OO

Justification

In the connectathon process, we've tested narrow scenarios around data exchange, but interest is growing quickly in understanding what issues arise around the wide area testing across enterprises, and including the patient directly, and understanding what - if anything - the main specification or the US core IG should say about them

Proposed Track Lead

Grahame Grieve (but mentoring someone to take over after this)

Expected participants

NATE MIHIN DXC (others: add your self here!)

Scenario

Paul is a VA beneficiary living in Alaska. Because of the remoteness of his location, there aren’t a lot of specialists at VA facilities for him to see. These get outsourced to civilian specialists, so there is a need to transfer information from the specialists back to the patient's VA record.

Paul would like an app that allows him to authorize and cause relevant EMR data to be exchanged between the VA and specialist systems.

Assumption: for this connectathon stream, we will build on the Argonaut interface - that is, a pull of the data from an EMR that provides an Argonaut based patient portal.

Roles

• Client application developer : the client application that allows Paul to authorise data transfer
• Source EMR system: the provider of data that will be made available
• Target EMR system: the VA or equivalent system that will acquire the data

Authorization

For this connectathon, we assume that the data will be made available via an Argonaut interface, but we hypothesize 2 variants.

1. Simple SMART on FHIR

In this variant, we use SMART-on-FHIR directly. In this scenario, Paul takes 2 actions:

• inform the target EMR of his desire that to acquire his data from the source EMR (by URL)
• authorize the target EMR by SMART on FHIR to get data from the specialist's end-point

As pre-conditions for this, Paul must know the URL for the specialist, and have an existing relationship with the target EMR. In addition, there must be an established trust relationship between the target and source EMR.

In this variant, Paul may interact with the target EMR through a generic mobile app (see below for interface) or a target EMR specific app, or the target EMR website. Participants may choose to prototype any of these

2. Heart/UMA

In this variant, the authorization is delegated to a central server that manages the patient Authorization per the Heart/UMA specification

(todo: fill out more details)

Note: this builds on the argonaut interface by adding Heart support to it.

Roles

Roles:

• "Source Argonaut Provider": provides argonaut based access to the data. (specifically, any source EMR based on the argonaut interface)
• "Target EMR Data Acquirer": Requests data from the "Source Argonaut Provider" based on the S4S (reference?) specification
• "Target EMR registration service": Provides an argonaut based interface that allows a patient to upload a consent resource consenting to the Target EMR gathering data from the "Source Argonaut Provider" (for a generic application to authorise the connection)
• "Source Heart provider": provides an Argonaut interface that uses Heart/UMA to decide what data to make available
• "Target Heart Data Acquirer" - registers itself with the Source Heart provider per Heart specifications, then gets data
• "Heart Server" - central heart server supporting both Source Heart provider and Target Heart Data Acquirer

Scenarios - todo?

Consent Resource

Todo....