This wiki has undergone a migration to Confluence found Here

201805 GDPR

From HL7Wiki
Jump to navigation Jump to search


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