This wiki has undergone a migration to Confluence found Here

201709 Consumer Centered Data Exchange

From HL7Wiki
Jump to navigation Jump to search


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 pattern

There are 4 possible patterns for Authorising/Managing the data flow

  • Application Managed API
  • Consent based tokens
  • Full UMA
  • Direct-based Push

1. Application Managed API

Data is made available by the normal Smart-on-FHIR interface that is, an Argonaut/S4S interface. In this scenario:

  • Paul logs into the target EMR app (mobile/website), and informs the app that he wants to connect it to the source EMR (how this is done is outside the scope of the connectathon)
  • The target EMR app (re)directs Paul to the authorization URL on the source EMR
  • Paul authorises the application as he wants
  • the target EMR makes requests of the source system in an ongoing fashion per Smart-on-FHIR
  • Paul connects to the source EMR to revoke his authorization when he wants the data flow to end

This scenario requires Paul to know the URLs for both source and target, and to deal with multiple applications, and for trust relationships to exist in the background between the source and target.

Notes:

  • there is no new API/interface in this arrangement - all of this is as described today, with additional application work.
  • this is actually more complicated than a simpler alternative: Paul has an application that downloads content from the source, and uploads it to the target. This approach has 2 problems - there's no trust (provenance) associated with the target/source connection (and there's plenty of real world demonstration that this is a big problem for care providers) and flow of data depends on Paul's devices and connectivity. There is solid grounds for Paul being able to download/update data to EMRs, but this connectathon stream focuses on giving the customer control over direct data flow

2. Consent based Smart-On-FHIR

Data is made available by the normal Smart-on-FHIR interface that is, an Argonaut/S4S interface, with a consent layer. In this scenario:

  • Paul authorises an app to the source EMR (standard Smart-On-FHIR)
  • Paul posts a Consent resource to the server, or choose an existing consent statement
  • Paul asks the source server for an API token based on the consent (see 'Acquiring an API token' below)
  • Paul authorises with the target server, and gives it the API token (see 'Providing API token' below)
  • the target EMR makes requests of the source system in an ongoing fashion using the API token
  • Paul can revoke the authorise by revoking the token (see 'Revoking an API token' below)

This scenario requires Paul to know the URLs for both source and target, and to have apps authorized to both of them (could be the same app) but he doesn't have to deal with multiple applications, and trust relationships between them are not required

3. Full UMA

Data is made available by the normal Smart-on-FHIR interface that is, an Argonaut/S4S interface, but 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.

4. Direct-based Push

In this scenario, data is made available in the same format as Argonaut, but instead of a Pull based API, a push using Direct is used instead. In this scenario:

  • Paul authorises an app to the source EMR (standard Smart-On-FHIR)
  • Paul posts a Consent resource to the server, or choose an existing consent statement
  • Paul asks the source server to start pushing the data based on the consent (see 'Starting push' below)
  • the source system sends data to the target system using direct based push
  • Paul can stop the sending through the app (see 'Stopping push' below)

This scenario requires Paul to know the URLs for the source, and the right direct email address for the target, and direct support must exist for the transfer between source and target. Paul doesn't have to have any relationship with the target, deal with multiple applications, and trust relationships between them are not required

Todo: is there interest in this?

Interfaces

For pattern #2 - Consent based SMART on FHIR

Authorizing an Application

POST [base]/Consent/[id]/$authorize

Inbound Parameters:

  • jwt : JWT (as binary) - a JWT identifying the application that is being authorised to act on behalf of the user (see below for how to get that)
  • duration : Duration - how long the token should be good for. (optional: system default time limit if not provided)

Response: 200 ok with Parameters, or an error with an operation outcome. Outbound Parameters:

  • duration : Duration - maximum length of time that the token is going to be honored. No duration means that the approval is not time limited

The server returns an error if it is not able to understand the consent resource fully, or if it is not prepared to honor the consent statement (e.g. it probably won't agree to a consent that grants more than the granting application itself has been authorized to have), or if it refuses to authorize the specified application for some reason (see below for further discussion on the implementation and policy of this).

For the purposes of this connectathon, this is the suggested profile on the Consent Statement:

<Consent xmlns="http://hl7.org/fhir"> 
 <id value="[id from api]"/>
 <text> // as appropriate  // </text>
 <status value="active"/> // can only perform $getToken on active consent statements  //
 <patient>// patient data to be shared  //</patient>
 <period>// optional period  //</period>
 <dateTime value="[optional]"/>
 <actor>
   // 
    text/code description of who's going to be granted access.
    This is useful for describing the recipient, but won't have 
    any computed meaning
    //
 </actor>
 <organization>// good to fill this out for consumption, but not important  //</organization>
 <policyRule  value="http://hl7.org/fhir/ConsentDefinition/simple-oauth">  
 <purpose> // optional but not processed  //</purpose>
 <dataPeriod>// optional, enforced if present //</dataPeriod>
   // don't use this  //
 <except>  
  // the definition of http://hl7.org/fhir/ConsentDefinition/simple-oauth is 
   that only this consent statement is granted access. Anything else is 
   granted access by exception  //
  <type value="permit"/>
  // not used <period/>, <actor/>  //
  <action>
   // this consent grants the right to access data  //
   <coding>
     <system value="http://hl7.org/fhir/consentaction"/>
     
   </coding>
  </action>
  // not used <securityLabel/>, <purpose/>  //
  // repeat class for each Smart on FHIR scope  //
  <class>
    <system value="http://smarthealthit.org/fhir/scopes"/>
    
  </class>
  // not used , <dataPeriod/>,    //
 </except>
</Consent>


Notes:

  • This profile is a restricted form of the Consent resource that allows the user to consent using Smart on FHIR scopes
  • Systems that don't allow upload of consent, but allow $authorize, can use whatever consent they can understand - the client does not need to understand the consent details to call $authorize.
  • this connectathon defines the special Smart on FHIR scope "Consent/flow" that a client can ask for to indicate that it wishes to use the token management API described here in addition to read and/or write of Consent resources
  • the token returned is a secret that gives access to a patient's health data. Anyone that gets the secret has access, so it must be handled accordingly.

Acquiring an Applications JWT

The operation above requires that the client have a JWT token that identifies the application it is authorizing to act in their behalf. This JWT can be acquired by OIDC well known discovery...

 todo: be specific about how you get this

Providing API token

Once an application has been authorized, the user informs it by calling the $connect operation:

POST [base]/$connect

Inbound parameters:

  • url: uri - the end-point URL for the Argonaut/S4S end-point of the application that it is authorised to acquire data from
  • Consent : id: the resource id of the consent statement on the source system. Required read-only access, so the target knows what is authorized to access
  • duration : Duration - maximum length of time that authorization has been granted going to be honored
  • patient : id: the resource id of the patient on the target system that records are for (optional; default is the single patient associated with the authentication with the target application - it's an error if there's more than one)

Response: 200 ok or an error with an operation outcome

Acquiring Data from the Source EMR

Once authorized, the target EMR creates a JWT token:

{
  "iss": "[same identity as in the JWT above",
  "aud": "[token end-point of source EMR]",
  "exp": [short term period],
  "jti": "[some nonce]",
  "consent": "[id]"
}

and then submits this to the normal token end point (see SMART on FHIR documentation), but with a different set of parameters:

 grant_type urn:ietf:params:oauth:grant-type:jwt-bearer
 assertion={authz JWT}

The response is the standard Smart on FHIR response.

Notes:

  • the client (target EMR) does not specify any scopes in this case. Scopes are dictated by the consent resource
  • Searching on Patient on the source system using this API token will only match the Consent.patient, and only resources in that patient compartment are available

Revoking an API token

getting a list of tokens:

GET [base]/Consent/[id]/$authorizations

Response 200 ok with parameters:

  • token - tuple
    • app-id : url - previously authorized application ("iss" header from the JWT)
    • duration : Duration - how long the token is good for

Revoking a Token:

POST [base]/Consent/[id]/$revokeAuthorization

Inbound parameters:

  • app-id : url - the identity of a previously authorized application

Response: 200 ok or an error with an operation outcome

Note: any further use of tokens associated with this authorization will result in a 404 unauthorized response

For pattern #4 - Direct push

Starting push

POST [base]/Consent/[id]/$pushStart

Inbound Parameters:

  • duration : Duration - how long the application should push data for. (optional: default is system should push data until otherwise instructed)
  • address : uri - direct address (email address) where the data should be sent

Response: 200 ok with Parameters, or an error with an operation outcome. Outbound Parameters:

  • address : uri - where the data is going to be sent
  • duration : Duration - maximum length of time that the token is going to be honored. If this is missing, the source will send until otherwise installed

The server returns an error if it is not able to understand the consent resource fully, or if it is not prepared to honor the consent statement (e.g. it may not agree to a consent that grants more than the granting application itself has been authorized to have). The server may also return an error if it cannot or will not send to the nominated direct address

For the purposes of this connectathon, this is the suggested profile on the Consent Statement:

<Consent xmlns="http://hl7.org/fhir"> 
 <id value="[id from api]"/>
 <text> // as appropriate  // </text>
 <status value="active"/> // can only perform $getToken on active consent statements  //
 <patient>// patient data to be shared  //</patient>
 <period>// optional period  //</period>
 <dateTime value="[optional]"/>
 <actor>
   // 
    text/code description of who's going to be granted access.
    This is useful for describing the recipient, but won't have 
    any computed meaning
    //
 </actor>
 <organization>// good to fill this out for consumption, but not important  //</organization>
 <policyRule  value="http://hl7.org/fhir/ConsentDefinition/simple-oauth">  
 <purpose> // optional but not processed  //</purpose>
 <dataPeriod>// optional, enforced if present //</dataPeriod>
   // don't use this  //
 <except>  
  // the definition of http://hl7.org/fhir/ConsentDefinition/simple-oauth is 
   that only this consent statement is granted access. Anything else is 
   granted access by exception  //
  <type value="permit"/>
  // not used <period/>, <actor/>  //
  <action>
   // this consent grants the right to access data  //
   <coding>
     <system value="http://hl7.org/fhir/consentaction"/>
     
   </coding>
  </action>
  // not used <securityLabel/>, <purpose/>  //
  // repeat class for each Smart on FHIR scope  //
  <class>
    <system value="http://smarthealthit.org/fhir/scopes"/>
    
  </class>
  // not used , <dataPeriod/>,    //
 </except>
</Consent>


Notes:

  • This profile is a restricted form of the Consent resource that allows the user to consent using Smart on FHIR scopes
  • Systems that don't allow upload of consent, but allow $pushRecords, can do whatever consent they can understand - the client does not need to understand the consent details to call $pushRecords.
  • this API is also controlled by the FHIR scope "Consent/flow" that a client can ask for to indicate that it wishes to use the Push API control described here in addition to read and/or write of Consent resources

When the system sends data by direct, it should use the profile as described by Sending FHIR resources in Direct Messages. Data is sent as collections, when ever the data is available, batched by sending system convenience.


Stopping push

Clients can find what push processes are set up for a given consent resource:

GET [base]/Consent/[id]/$listPush

Response 200 ok with parameters:

  • token - tuple
    • address : uri - address data is being sent to
    • status : string - current status for human discussion - number of records sent, or current error message, as appropriate

Stopping a push:

POST [base]/Consent/[id]/$pushStop

Inbound parameters:

  • address : uri - Direct address to stop sending to

Response: 200 ok or an error with an operation outcome

Data will stop flowing once a 200 is returned