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
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)
NATE MIHIN DXC (others: add your self here!)
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.
- 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
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
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.
- "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?