Revision as of 18:46, 28 March 2018

Track Name

GDPR

Security WG

Track Orientation Presentation -- TBD

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

@@ Line 31: / Line 31: @@
 *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]]