This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201805 GDPR"

From HL7Wiki
Jump to navigation Jump to search
Line 31: Line 31:
==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==
==Testing Scenarios==

Revision as of 18:46, 28 March 2018

Track Name


Submitting WG/Project/Implementer Group

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

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 - -- skype JohnMoehrke
  • Alex Mense - Security WG co-chair
  • Rene Spronk

Expected participants

Testing Scenarios