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

Difference between revisions of "201805 GDPR"

From HL7Wiki
Jump to navigation Jump to search
Line 31: Line 31:
 
*http://test.fhir.org/r3
 
*http://test.fhir.org/r3
  
−
 
−
==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==
 
==Prioritization regarding track focus on Consent Resource v. OAuth Scope==

Revision as of 18:46, 28 March 2018


Track Name

GDPR

Submitting WG/Project/Implementer Group

Security WG

Track Orientation Presentation -- TBD

Justification

The justification for this track is to explore how the FHIR specification and Implementation Guides enable and support compliance with GDPR.

This is a collaborative effort, please sign up to help

Relevant background

Prior Connectathon track 201709 Consumer Centered Data Exchange and 201801 Consumer Centered Data Exchange

Proposed Track Leads

  • John Moehrke -Security WG co-chair - JohnMoehrke@gmail.com -- skype JohnMoehrke
  • Alex Mense - Security WG co-chair
  • Rene Spronk

Expected participants


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=201805_GDPR&oldid=155089"