This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Consumer Centered Data Exchange"

From HL7Wiki
Jump to navigation Jump to search
 
(64 intermediate revisions by 2 users not shown)
Line 7: Line 7:
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
 
FHIR Project Director, in association with the National Association For Trusted Exchange (NATE)
 
FHIR Project Director, in association with the National Association For Trusted Exchange (NATE)
 +
 +
Track Orientation Presentation [[Media:20180119 - CCDE Orientation.pptx]]
  
 
==Justification==
 
==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. 
 
  
−
The participants of the January event aggregated around two use cases:
+
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 cases. This will be the second CCDE connectathon. The inaugural connectathon spurred significant interest and participation in San Diego followed by voluminous post-connectathon discussion.
  
−
'''Scenario 1) 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.
+
Key topics to continue to examine in relation to the Consent Resource and Scopes include opportunities to:
  
−
- 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.
+
* Increase understanding of Scopes currently being deployed across data sources.
 +
* Increase consumer’s trust by transparently conveying how their choices, driven by Scopes, may differ from what may be perceived in the language of an Authorization interface.
 +
* Increase understanding of the impact of Scope variances across data sources on the applications that receive data from data sources when authorized to do so by the consumer.
 +
* Increase understanding of how a Distribution Service utilizes the Consent Resource to evaluate permitted end-points to share data with.
  
−
'''Scenario 2) 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.
+
At the first CCDE connectathon, participants predominantly focused on three architectures : Architecture (1) Consumer Access Use Case: using the OAuth pattern and RESTful API’s to transport released data to the app of the consumer’s choosing; Architecture (2) Consumer Initiated Exchange (Proxy) Use Case (“Set it and forget it”): capturing the consumer’s privacy preferences in a computable fashion via a FHIR Consent Resource, whereby in subsequent operations after consent was granted, “Scopes” are used to determine what to share; Architecture (3) extended the Consumer Initiated Exchange paradigm by employs a distribution service – such as an HIE – which, informed by the consumer’s direction given in a Consent Resource, drives the decision of which Provider Organizations known to the HIE data should be distributed.
  
−
- 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.  
+
'''Note that Scopes were integral to all of the transactions performed at the connectathon regardless of the architecture.'''
  
−
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.
+
The Consumer Access via OAuth Use Case (architecture 1) coupled the app and flow used to capture the consumer’s authorizations such that data is only distributed to the consumer controlled. The Consumer Initiated Exchange Use Case (Architectures 2 & 3 – or aka ‘on-behalf-of-the consumer’) de-couples the capture of the consumer’s sharing preferences so to enable sharing with one or many Organization’s end-points (and subsequently 1 or many individuals within that Organization).
−
   
+
 
−
Prior Connectathon track [[201709 Consumer Centered Data Exchange]]
+
'''Regardless of the architecture employed the role of the scopes as defined by the data holder must be well understood by both the Consumer and the Application receiving the data.'''
 +
 
 +
In the OAuth use case consumers are presented with human readable descriptions of what they are authorizing be shared, either with their app or on their behalf by a Provider or an HIE.  Since the Scopes are not directly accessible to the consumer and the match between what the Scope allows to be shared and the consumers perception of what it expects is being shared may be imperfect there is an emerging need to '''examine the gap that may exist between what Scopes are able to support and what consumer’s perceive they are authorizing in the OAuth (or similar) flows.'''
 +
 
 +
We will explore what the Gaps are and what – if anything – the FHIR specification may have to say about addressing them.  We aim to understand at a minimum the various scenarios where there are no Gaps (when a consumer authorizes a data holder to share all of their data with a consumer controlled app of their choice is there any gaps between what the consumer might expect and what the Scopes may actually be able to deliver?) and explore what if anything can be done to alert the consumer to these gaps in the cases when they do exist (if a security labeling mechanism is used to mark sensitive data but it is known to the implementer that in some cases there are risks of Type I and Type II errors how can this be conveyed to the consumer in a standard way?).  Would a standard set of Scopes and standard consumer facing language that speaks to these potential gaps benefit the community and consumers in understanding the potential risks?
 +
 
 +
From the perspective of app Developers that receive data, it would be beneficial if standard Scopes were employed across data sources as well.  As Scopes vary across data sources the burden on app developers increases – separate methods of ingestion must be built for each unique Scope in order to properly handle receipt of the data being shared.  If complex Scopes vary in the mechanisms by which they attempt to satisfy Consumer’s preferences the impact on App Developer burden may increase as well.
 +
 
 +
Finally, when a consumer is directing an entity to share on their behalf they are required to designate which end-points they are authorizing to receive their data.  Unlike in the consumer access use case (Architecture 1) where there is only one end-point that data is shared with (the consumer controlled app) both Architecture 2 and Architecture 3 may require the consumer to indicate which end-points they are permitting data to be shared with.   
  
 +
'''As more implementations that support this kind of multi-end-point sharing on behalf of a consumer are developed a better understanding of how existing standards may need to be enhanced or defined is required.
 +
'''
 
----
 
----
−
 
  
 
===Relevant background===
 
===Relevant background===
  
 +
Prior Connectathon track [[201709 Consumer Centered Data Exchange]]
  
 
* HL7 blog - [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2 HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 1 of 2]
 
* HL7 blog - [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2 HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 1 of 2]
Line 42: Line 56:
 
** You do not need to be an HL7 member to signup for mailing lists
 
** You do not need to be an HL7 member to signup for mailing lists
  
−
==Proposed Track Lead==
+
==Proposed Track Leads==
−
Aaron Seib  
+
Aaron Seib and John Moerhke
  
 
==Expected participants==
 
==Expected participants==
Line 50: Line 64:
 
*http://test.fhir.org/r3
 
*http://test.fhir.org/r3
 
*HSS IDEA Lab Authors of the POET specification Mark Scrimshire & Alan Viars
 
*HSS IDEA Lab Authors of the POET specification Mark Scrimshire & Alan Viars
 +
*David Hay (Orion Health)
  
 
(others: email aaron.seib@nate-trust.org if you are interested in getting involved)
 
(others: email aaron.seib@nate-trust.org if you are interested in getting involved)
  
 
==Architectures==
 
==Architectures==
−
<!-- What will be the actions performed by participants? -->
+
All three Architectures involve the following Actors:
−
 
 
−
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]
 
'''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''' - 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)
+
'''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)
 
'''Resource Service''' - holds data that is controlled by Consumer's Privacy Preferences (Such as an EMR, an HIE or a Payer)
Line 66: Line 79:
 
'''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.  
 
'''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 also has a Consent Service which is a stand alone UI 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)
+
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===
 
===Architecture 1) Consumer Access via OAuth===
 +
 +
- 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. The Data Provider wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
 +
 
:'''Action''':  Consumer Authorizes the sharing of their Health Information with an App of their choice using the SMART OAuth pattern to authenticate
 
:'''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)
 
:'''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)
Line 74: Line 95:
 
:'''Bonus point''': Being able to handle a consumer's rescinding of their authorization to disclose
 
:'''Bonus point''': Being able to handle a consumer's rescinding of their authorization to disclose
  
−
<!-- Provide a description of each task -->
+
Description of Transactions
  
−
[[File:Architecture 1.jpg]]
+
:0 – Ceremony where Patient gives rules they want enforced (OAuth Ceremony where Consumer interacts with OAuth flow to convey their sharing preferences)
 +
 
 +
:0’ – Saving of rules into FHIR Consent resource (may be optional in Architecture a?  Where is audit trail captured?)
 +
 
 +
: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 the token+scope received in 1
 +
 
 +
[[File:Architecture1v2.jpg]]
 +
 
 +
'''Anchor Connectathon Participant''': CMS Blue Button API Team
 +
----
  
 
===Architecture 2) Consumer Initiated Exchange - sharing 'on behalf of' ===
 
===Architecture 2) Consumer Initiated Exchange - sharing 'on behalf of' ===
 +
- A consumer, such as a patient being treated by a Provider that belongs to a Hospital, wishes to authorize the Hospital to share their health information with other providers attributed to them in the Hospital.  Data is shared, on-behalf of the consumer, among the authorized providers at the network without the consumer necessarily receiving a copy of the record themselves.  The Hospital wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
 +
 +
 +
:'''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
 +
 +
[[File:Architecture2.jpg]]
 +
 +
'''Anchor Connectathon Participant''': Kathleen Connors
 +
 +
----
 +
 +
===Architecture 3) Consumer Initiated Exchange with Distribution Service ===
 +
 +
- A consumer, such as a patient being treated by a Provider that belongs to 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 the providers on the network without the consumer necessarily receiving a copy of the record themselves.  The HIE wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
 +
 +
 
:'''Action''': Via a user friendly interface a consumer captures their privacy preferences in a computable way  
 
:'''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.
 
:'''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.
Line 84: Line 147:
 
:'''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.
 
:'''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.
  
−
<!-- Provide a description of each task -->
+
Description of Transactions
 +
 
 +
:0 – Ceremony where Consumer interacts with the ''Consent Service'' to convey their sharing preferences
 +
 
 +
:0’ – Saving of rules FHIR via Questionnaire\Questionnaire Response into Consent Resource and others (*)
 +
 
 +
: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
 +
 
 +
 
 +
(*) The provider/organizations/actors that the consumer is authorizing sharing with captured in the consent resource. The Questionnaire and QuestionnaireResponse resources hold all the other data.
 +
 
 +
Bundle {
 +
        Consent (Defines the Actors, Providers, Orgs, etc for whom the patient is giving consent to)
 +
        Questionnaire (Defines the Questions)
 +
        QuestionnaireResponse (Captures the Question Answers)
 +
      }
 +
 
 +
 
 +
[[File:Architecture_3.jpg]]
 +
 
 +
 
 +
'''Anchor Connectathon Participant''': MiHIN
 +
 
 +
==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.
  
−
[[File:Architecture 2.jpg]]
+
==Testing Scenarios==
  
−
==Security and Privacy Considerations==
+
[[Media:2018026_-_Interaction_with_eConsent_Management_Service.docx]]
−
<!-- Optional (for initial proposal): Address the topic of Privacy and Security.
 
−
* What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations.
 
−
* What Privacy Consent management will be used? When the Consent Resource is used, define how.
 
−
* What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain.
 
−
* How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices.
 
−
* How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions.
 
−
I am happy to help: JohnMoehrke@gmail.com -- security co-chair
 
−
-->
 

Latest revision as of 03:42, 27 January 2018


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)

Track Orientation Presentation Media:20180119 - CCDE Orientation.pptx

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 cases. This will be the second CCDE connectathon. The inaugural connectathon spurred significant interest and participation in San Diego followed by voluminous post-connectathon discussion.

Key topics to continue to examine in relation to the Consent Resource and Scopes include opportunities to:

  • Increase understanding of Scopes currently being deployed across data sources.
  • Increase consumer’s trust by transparently conveying how their choices, driven by Scopes, may differ from what may be perceived in the language of an Authorization interface.
  • Increase understanding of the impact of Scope variances across data sources on the applications that receive data from data sources when authorized to do so by the consumer.
  • Increase understanding of how a Distribution Service utilizes the Consent Resource to evaluate permitted end-points to share data with.

At the first CCDE connectathon, participants predominantly focused on three architectures : Architecture (1) Consumer Access Use Case: using the OAuth pattern and RESTful API’s to transport released data to the app of the consumer’s choosing; Architecture (2) Consumer Initiated Exchange (Proxy) Use Case (“Set it and forget it”): capturing the consumer’s privacy preferences in a computable fashion via a FHIR Consent Resource, whereby in subsequent operations after consent was granted, “Scopes” are used to determine what to share; Architecture (3) extended the Consumer Initiated Exchange paradigm by employs a distribution service – such as an HIE – which, informed by the consumer’s direction given in a Consent Resource, drives the decision of which Provider Organizations known to the HIE data should be distributed.

Note that Scopes were integral to all of the transactions performed at the connectathon regardless of the architecture.

The Consumer Access via OAuth Use Case (architecture 1) coupled the app and flow used to capture the consumer’s authorizations such that data is only distributed to the consumer controlled. The Consumer Initiated Exchange Use Case (Architectures 2 & 3 – or aka ‘on-behalf-of-the consumer’) de-couples the capture of the consumer’s sharing preferences so to enable sharing with one or many Organization’s end-points (and subsequently 1 or many individuals within that Organization).

Regardless of the architecture employed the role of the scopes as defined by the data holder must be well understood by both the Consumer and the Application receiving the data.

In the OAuth use case consumers are presented with human readable descriptions of what they are authorizing be shared, either with their app or on their behalf by a Provider or an HIE. Since the Scopes are not directly accessible to the consumer and the match between what the Scope allows to be shared and the consumers perception of what it expects is being shared may be imperfect there is an emerging need to examine the gap that may exist between what Scopes are able to support and what consumer’s perceive they are authorizing in the OAuth (or similar) flows.

We will explore what the Gaps are and what – if anything – the FHIR specification may have to say about addressing them. We aim to understand at a minimum the various scenarios where there are no Gaps (when a consumer authorizes a data holder to share all of their data with a consumer controlled app of their choice is there any gaps between what the consumer might expect and what the Scopes may actually be able to deliver?) and explore what if anything can be done to alert the consumer to these gaps in the cases when they do exist (if a security labeling mechanism is used to mark sensitive data but it is known to the implementer that in some cases there are risks of Type I and Type II errors how can this be conveyed to the consumer in a standard way?). Would a standard set of Scopes and standard consumer facing language that speaks to these potential gaps benefit the community and consumers in understanding the potential risks?

From the perspective of app Developers that receive data, it would be beneficial if standard Scopes were employed across data sources as well. As Scopes vary across data sources the burden on app developers increases – separate methods of ingestion must be built for each unique Scope in order to properly handle receipt of the data being shared. If complex Scopes vary in the mechanisms by which they attempt to satisfy Consumer’s preferences the impact on App Developer burden may increase as well.

Finally, when a consumer is directing an entity to share on their behalf they are required to designate which end-points they are authorizing to receive their data. Unlike in the consumer access use case (Architecture 1) where there is only one end-point that data is shared with (the consumer controlled app) both Architecture 2 and Architecture 3 may require the consumer to indicate which end-points they are permitting data to be shared with.

As more implementations that support this kind of multi-end-point sharing on behalf of a consumer are developed a better understanding of how existing standards may need to be enhanced or defined is required.

Relevant background

Prior Connectathon track 201709 Consumer Centered Data Exchange

email discussion list

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
  • David Hay (Orion Health)

(others: email aaron.seib@nate-trust.org if you are interested in getting involved)

Architectures

All three 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

- 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. The Data Provider wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.

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 – Ceremony where Patient gives rules they want enforced (OAuth Ceremony where Consumer interacts with OAuth flow to convey their sharing preferences)
0’ – Saving of rules into FHIR Consent resource (may be optional in Architecture a? Where is audit trail captured?)
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 the token+scope received in 1

Architecture1v2.jpg

Anchor Connectathon Participant: CMS Blue Button API Team

Architecture 2) Consumer Initiated Exchange - sharing 'on behalf of'

- A consumer, such as a patient being treated by a Provider that belongs to a Hospital, wishes to authorize the Hospital to share their health information with other providers attributed to them in the Hospital. Data is shared, on-behalf of the consumer, among the authorized providers at the network without the consumer necessarily receiving a copy of the record themselves. The Hospital wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.


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

Architecture2.jpg

Anchor Connectathon Participant: Kathleen Connors

Architecture 3) Consumer Initiated Exchange with Distribution Service

- A consumer, such as a patient being treated by a Provider that belongs to 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 the providers on the network without the consumer necessarily receiving a copy of the record themselves. The HIE wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.


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 FHIR via Questionnaire\Questionnaire Response into Consent Resource and others (*)
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


(*) The provider/organizations/actors that the consumer is authorizing sharing with captured in the consent resource. The Questionnaire and QuestionnaireResponse resources hold all the other data.

Bundle { 

       Consent (Defines the Actors, Providers, Orgs, etc for whom the patient is giving consent to)
       Questionnaire (Defines the Questions)
       QuestionnaireResponse (Captures the Question Answers)
      }


Architecture 3.jpg


Anchor Connectathon Participant: MiHIN

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.

Testing Scenarios

Media:2018026_-_Interaction_with_eConsent_Management_Service.docx

Retrieved from "https://wiki.hl7.org/w/index.php?title=201801_Consumer_Centered_Data_Exchange&oldid=152109"