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
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  
 
[[Category:201805_FHIR_Connectathon_Track_Proposals|May 2018 Proposals]]
 
[[Category:201805_FHIR_Connectathon_Track_Proposals|May 2018 Proposals]]
 +
*[http://wiki.hl7.org/index.php?title=GDPR_(General_Data_Protection_Regulation) HL7 Security WG GDPR wiki]
 
__NOTOC__
 
__NOTOC__
 
=Track Name=
 
=Track Name=
−
GDPR
+
GDPR - General Data Protection Regulation
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
Line 12: Line 13:
 
==Justification==
 
==Justification==
  
−
The justification for this track is to explore how the FHIR specification and Implementation Guides enable and support compliance with GDPR.  
+
The justification for this track is to explore how the FHIR specification and Implementation Guides enable and support compliance with GDPR. This is not an overall examination of GDPR.  
  
 
This is a collaborative effort, please sign up to help  
 
This is a collaborative effort, please sign up to help  
 +
 +
[https://chat.fhir.org/#narrow/stream/Security.20and.20Privacy/topic/GPDR Zulip chat thread on GDPR] for ongoing dialog
  
 
===Relevant background===
 
===Relevant background===
Line 21: Line 24:
  
 
*[https://gforge.hl7.org/gf/project/security/docman/Security%20White%20Papers/Is%20Privacy%20Obsolete%20Study%20Group%20Library/HIMSS%20GDPR%20Webinar%20-%20final%203-20-2018.pdf HIMSS presentation on GDPR]
 
*[https://gforge.hl7.org/gf/project/security/docman/Security%20White%20Papers/Is%20Privacy%20Obsolete%20Study%20Group%20Library/HIMSS%20GDPR%20Webinar%20-%20final%203-20-2018.pdf HIMSS presentation on GDPR]
 +
* blog by Rene http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm
 +
* IHE whitepaper on GDPR - https://www.ihe-europe.net/sites/default/files/GDPR_WEB_00.pdf
 +
* Useful GDPR regulation text reference https://gdpr-info.eu/
  
 
==Proposed Track Leads==
 
==Proposed Track Leads==
Line 31: Line 37:
 
*http://test.fhir.org/r3
 
*http://test.fhir.org/r3
  
 +
==Actors==
 +
* Agent-Systems -- any system participating in the creation, use, or disclosure of identifiable data
 +
* etc...
  
−
==Considerations regarding Commonality of Scopes regardless of Architecture==
+
==FHIR Capabilities==
−
 
 
−
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==
 
−
 
 
−
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.
+
Expect to produce a cross-reference between the existing FHIR Security & Privacy capabilities and how they aid with GDPR compliance.
 +
* Provenance resource
 +
* AuditEvent resource
 +
* Consent resource
 +
* Identity
 +
** Patient resource
 +
** RelatedPerson
 +
** Practitioner, PractitionerRole
 +
** Group
 +
** Organization
 +
** Location
 +
** etc.
 +
* Security-label mechanism in all FHIR Resource definitions (.meta.security)
 +
** Confidentiality classification
 +
** Sensitivity classification
 +
** Compartment classification
 +
** Integrity classification
 +
** Handling caveat
 +
* Security-label vocabulary (aka HCS)
 +
* Signature datatype
 +
* De-Identification
 +
* Authorization mechanisms
 +
** SMART-on-FHIR
 +
** Sync for Science
 +
** IHE-IUA
 +
** HEART
 +
** etc...
 +
* User/system Authentication
 +
** Open-ID-Connect profile of OAuth
 +
*** by way of SMART-on-FHIR
 +
* Communications security
 +
** HTTPS
  
 
==Testing Scenarios==
 
==Testing Scenarios==
  
−
[[Media:2018026_-_Interaction_with_eConsent_Management_Service.docx]]
+
* Privacy Consents -- follow [[201801 Consumer Centered Data Exchange]]
 +
** or enhancements as needed
 +
* TBD

Latest revision as of 20:59, 17 May 2018

Track Name

GDPR - General Data Protection Regulation

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 not an overall examination of GDPR.

This is a collaborative effort, please sign up to help

Zulip chat thread on GDPR for ongoing dialog

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

Actors

  • Agent-Systems -- any system participating in the creation, use, or disclosure of identifiable data
  • etc...

FHIR Capabilities

Expect to produce a cross-reference between the existing FHIR Security & Privacy capabilities and how they aid with GDPR compliance.

  • Provenance resource
  • AuditEvent resource
  • Consent resource
  • Identity
    • Patient resource
    • RelatedPerson
    • Practitioner, PractitionerRole
    • Group
    • Organization
    • Location
    • etc.
  • Security-label mechanism in all FHIR Resource definitions (.meta.security)
    • Confidentiality classification
    • Sensitivity classification
    • Compartment classification
    • Integrity classification
    • Handling caveat
  • Security-label vocabulary (aka HCS)
  • Signature datatype
  • De-Identification
  • Authorization mechanisms
    • SMART-on-FHIR
    • Sync for Science
    • IHE-IUA
    • HEART
    • etc...
  • User/system Authentication
    • Open-ID-Connect profile of OAuth
      • by way of SMART-on-FHIR
  • Communications security
    • HTTPS

Testing Scenarios

Retrieved from "https://wiki.hl7.org/w/index.php?title=201805_GDPR&oldid=157351"