201805 GDPR
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
- John Moehrke (HL7 Security co-chair) SME on FHIR Consent
- http://test.fhir.org/r3
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
