201801 Consumer Centered Data Exchange
Track Name
Consumer Centered Data Exchange (CCDE)
Submitting WG/Project/Implementer Group
FHIR Project Director, in association with the National Association For Trusted Exchange (NATE)
Justification
The justification for this track is to continue to develop an understanding of what the main specification of the US core IG should say about enabling consumer-centric use case. This will be the second CCDE connectathon. The inaugural connectathon spurred significant interest and participation in San Diego followed by voluminous post-connectathon discussion.
At the first CCDE connectathon in San Diego, there were two architectures predominantly employed.
Those who participated in the consumer access use case utilized the SMART on FHIR Authorization Architecture relying on RESTful API's to transport released data to the consumer’s app -- while those who focused on the Consumer Initiated Exchange Use Case focused on capturing the consumer's privacy preferences in a computable fashion via a FHIR Consent Resource and in subsequent operations utilized “Scopes” to determine what to share based in part on meta-data about the entity being disclosed to, for example, attributed providers versus other provider’s known to the data holder (i.e., part of the network but not having an active treating relationship).
Where the architecture employed for the Consumer Access use case coupled the app and flow used to capture the consumer’s authorizations (and subsequently the scopes used to generate the authorization token that resulted in data being shared) the architecture utilized by the Consumer Initiated Exchange use case does not constrain the end-point with which data may be shared with. As a result – at a higher level of abstraction as it relates to Scopes, the Consumer Access use case may be seen as a subset of the more general case.
Yet, from the perspective of a Developer, regardless of the architecture that results in their app receiving data it would be beneficial if the same scopes were employed and further that standard scopes existed across data sources regardless of use case would be beneficial to the community the goal of this track will be to elucidate the intersection of standards at the Scope level independent of architecture.
The participants of the January event aggregated around two use cases (implemented in two different architectures):
Consumer Access enabled by OAuth from a consumer controlled application – there is ambiguity in the community regarding the use of the FHIR standards to properly record when consumer access is enabled via OAuth. Striking the appropriate balance between minimizing the level of effort on the part of the consumer with the data holder's requirement to maintain an accounting of disclosures for audit and reporting purposes requires further deliberation to determine what if any modification to existing standards are needed and to provide guidance to aid developers implementing this use case in their systems. We aim to explore the various implementation considerations, doing so in a policy transparent way.
- A consumer, such as a medicare beneficiary, wishes to authorize the sharing of their health information from a Data Provider, such as CMS, with a consumer controlled app of their choice; Data Provider wishes to generate required information to capture the consumer's authorization and all necessary information to be able to report an complete accounting of disclosure.
Consumer Initiated Exchange - incorporating privacy preferences when sharing 'on behalf of' the consumer in addition to the requirement to be able to account for disclosures under HIPAA in the US, data holders are obligated to be able to share data with other entities 'on behalf of the consumer'. A number of elements are being brought to bare to address this complex requirement that intersects numerous regulatory and technical challenges including Cascading OAuth, UMA, Security Labeling Services, a FHIR-based eConsent portals and electronic Consent Management Systems. The goal of this scenario to examine how these components can empower consumers to communicate their privacy preferences to data holders who share information with covered entities on their behalf. We aim to explore the various implementation considerations, doing so in a policy transparent way.
- A consumer, such as a patient being treated by a Provider Participating in an HIE, wishes to authorize the HIE to share their health information with other providers attributed to them in the HIE. Data is shared, on-behalf of the consumer between their providers on the network without the consumer necessarily receiving a copy of the record themselves.
The affinity to these use cases were observed to be based on the architectures being employed by the participants of each use case but an important observation that has been made is that the underlying resources and gap in the standard (specifically around standard Scopes) was common across the two groups. The goal of this connectathon will be to more purposely explore the commonalities between the use cases and determine how the different architectures employed bare on the existing standards and to begin to explore the elucidation of standard Scopes that would be common to both.
Prior Connectathon track 201709 Consumer Centered Data Exchange
Relevant background
- HL7 blog - HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 1 of 2
- HL7 blog - HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 2 of 2
- John Moehrke blog - Remedial FHIR Consent Enforcement - note this is a different model than this track is following, but was used for alternative track.
- Grahame/Josh blog - Sharing Information with a Patient Case Manager
email discussion list
- mailto privacyconsent@lists.hl7.org
- archive of discussion
- signup at http://www.hl7.org/myhl7/managelistservs.cfm
- You do not need to be an HL7 member to signup for mailing lists
Proposed Track Leads
Aaron Seib and John Moerhke
Expected participants
- NATE
- John Moehrke (HL7 Security co-chair) SME on FHIR Consent
- http://test.fhir.org/r3
- HSS IDEA Lab Authors of the POET specification Mark Scrimshire & Alan Viars
(others: email aaron.seib@nate-trust.org if you are interested in getting involved)
Architectures
Both Architectures involve the following Actors:
Consumer - Gives ceremony instantiating authorization rules for an end-point (Consumer Controlled App in the case of the Consumer Access scenario); designated end-points in the Consumer Initiated Use Case) access to the resource service managed data [Patient who provides their privacy preferences - via the OAuth interaction in the Consumer Access scenario; via the Consent Service in the Consumer Initiated scenario]
Authorization Service (AuthZ) - makes authorization decisions on how an end-point access to specific data at specific Resource Service(s) according to rules (Privacy Preferences indicated by the Consumer)
Resource Service - holds data that is controlled by Consumer's Privacy Preferences (Such as an EMR, an HIE or a Payer)
End-point - the "Application" (including a Consumer App; a 3rd Party end-point indicated by the Consumer such as their PCP's EMR or their Payer's care management team; a Research Repository; etc.) that is given rights to access data on a Resource Service at the direction of the Patient.
The Consumer Initiated Scenario involves the Consent Service actor.
Consent Capture (CC) - a stand alone Service that captures the privacy preferences of the Consumer (which performs a similar function to the SMART OAuth interaction where the consumer indicates their privacy preferences interactively with the Authorization Service)
Architecture 1) Consumer Access via OAuth
- Action: Consumer Authorizes the sharing of their Health Information with an App of their choice using the SMART OAuth pattern to authenticate
- Precondition: Consumer App is registered with the disclosing system (any FHIR based system that holds PHI about the consumer such as an EMR or Payer)
- Success Criteria: Without any special effort of the part of the consumer the disclosing system retains all required information to satisfy regulatory and audit requirements
- Bonus point: Being able to handle a consumer's rescinding of their authorization to disclose
Description of Transactions
- 0 – OAuth Ceremony where Consumer interacts with OAuth flow to convey their sharing preferences
- 0’ – Saving of rules into FHIR Consent resource
- 1 – Request by App for authorization to access specific data (scope) at Resource Service (target) resulting in an authorization (token+scope)
- 2 – Request by App for access to data given token+scope
Architecture 2) Consumer Initiated Exchange - sharing 'on behalf of'
- Action: Via a user friendly interface a consumer captures their privacy preferences in a computable way
- Precondition: Data holders are subscribed to the services that enable the capture of the consumer's privacy preferences and can electronically share with end-points indicated by the consumer.
- Success Criteria: The designated recipient that the data holder is disclosing to on behalf of the consumer receive all data except that which the consumer's privacy preferences indicate should not be shared it.
- Bonus point: Demonstrate how the solution set will allow the recreation of the consumer's privacy preferences at any point in time in the past following one or more changes in preference settings.
Description of Transactions
- 0 – Ceremony where Consumer interacts with the Consent Service to convey their sharing preferences
- 0’ – Saving of rules into FHIR Consent resource
- 1’ – Authorization service uses rules from FHIR Consent resource
- 1 – Request by App for authorization to access specific data (scope) at Resource Service (target) resulting in an authorization (token+scope)
- 2 – Request by App for access to data given token+scope
Considerations regarding Commonality of Scopes regardless of Architecture
Although both of the architectures were developed independently with the intent of enabling different objectives both rely on the implementation of clearly defined Scopes.
To date Scopes have been developed independently as driven by the specific project's needs.
From the perspective of a developer, it is important that the behavior of a Scope is known regardless of the architecture as it impacts the requirements of how the application must be developed.
If every data source developed Scopes unique to them an App Developer would have to modify their application to account for the differences among data sources.
It is an objective of this track to ascertain the degree to which a standard set of scopes may be defined and the impact on the underlying standards with regards to differences among Data Source Type (are different scopes required among Payer and Provider systems - are any scopes common among the two?) and to begin the process of expounding on what those scopes may entail based on those being used by participants.
Similarly - with regards to population of the Consent Resource we intend to explore differences if any in how this resource is populated depending on the Architecture being employed.
Prioritization regarding track focus on Consent Resource v. OAuth Scope
FHIR Consent resource exists, and FHIR has Profiling capability
- *Profiling of existing FHIR Consent is possible
- *Profiling of FHIR Consent helps with those that have needs for creating rules, and patterns of rules
- *Profiling of FHIR Consent ties the CC and AuthZ actors in a way that assures that a Consent that is captured can be enforced. And prevents giving the patient a perception that they can have rules that can’t be enforced.
Oauth scope transactions (1, 2) are required regardless of architecture
- *Current SMART scopes are only sufficient for PERMIT/DENY
- *Any quilted consent requires more capable Oauth scopes
Many multiples more Endpoints and Resource Svrs exist than CC.
- *Endpoints and Resource Svrs would be developed to interact in many architectures.
- *CC and AuthZ would be paired and specific to policies (patterns) and expectations
Architecture (a) simply groups CC + AuthZ into one system, and thus is not constrained to the complexity or fidelity of the Consent Resource.
