|
|
| (15 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. |
| | | | |
| − | Cross-Reference is being developed collaboratively on [http://confluence.hl7.org/display/SEC/FHIR+-+GDPR GDPR Page on FHIR Security confluence]
| + | 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 20: |
Line 23: |
| | Prior Connectathon track [[201709 Consumer Centered Data Exchange]] and [[201801 Consumer Centered Data Exchange]] | | Prior Connectathon track [[201709 Consumer Centered Data Exchange]] and [[201801 Consumer Centered Data Exchange]] |
| | | | |
| − | | + | *[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] |
| − | * HL7 blog - [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2 HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 1 of 2] | + | * blog by Rene http://www.ringholm.com/column/GDPR_impact_on%20healthcare_data_interoperability.htm |
| − | * HL7 blog - [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2-0 HL7 FHIR Connectathon 16: Patient Consent Forms: Redundant in the world of OAuth2? Part 2 of 2]
| + | * IHE whitepaper on GDPR - https://www.ihe-europe.net/sites/default/files/GDPR_WEB_00.pdf |
| − | * John Moehrke blog - [https://healthcaresecprivacy.blogspot.com/2017/09/remedial-fhir-consent-enforcement.html Remedial FHIR Consent Enforcement] - note this is a different model than this track is following, but was used for alternative track.
| + | * Useful GDPR regulation text reference https://gdpr-info.eu/ |
| − | * Grahame/Josh blog - [http://www.healthintersections.com.au/?p=2746 Sharing Information with a Patient Case Manager] | |
| − | | |
| − | email discussion list
| |
| − | * mailto privacyconsent@lists.hl7.org
| |
| − | * [http://lists.hl7.org/read/?forum=privacyconsent archive of discussion] | |
| − | * signup at http://www.hl7.org/myhl7/managelistservs.cfm | |
| − | ** You do not need to be an HL7 member to signup for mailing lists
| |
| | | | |
| | ==Proposed Track Leads== | | ==Proposed Track Leads== |
| − | John Moehrke -Security WG co-chair - JohnMoehrke@gmail.com -- skype JohnMoehrke | + | *John Moehrke -Security WG co-chair - JohnMoehrke@gmail.com -- skype JohnMoehrke |
| − | Alex Mense - Security WG co-chair | + | *Alex Mense - Security WG co-chair |
| | + | *Rene Spronk |
| | | | |
| | ==Expected participants== | | ==Expected participants== |
| Line 40: |
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... |
| | | | |
| − | ==Architectures== | + | ==FHIR Capabilities== |
| − | All three Architectures involve the following Actors:
| |
| − | | |
| − | '''Consumer''' - Gives ceremony instantiating authorization rules for an end-point (Consumer Controlled App in the case of the Consumer Access scenario); designated end-points in the Consumer Initiated Use Case) access to the resource service managed data [Patient who provides their privacy preferences - via the OAuth interaction in the Consumer Access scenario; via the Consent Service in the Consumer Initiated scenario]
| |
| − | | |
| − | '''Authorization Service (AuthZ)''' - makes authorization decisions on how an end-point access to specific data at specific Resource Service(s) according to rules (Privacy Preferences indicated by the Consumer)
| |
| − | | |
| − | '''Resource Service''' - holds data that is controlled by Consumer's Privacy Preferences (Such as an EMR, an HIE or a Payer)
| |
| − | | |
| − | '''End-point''' - the "Application" (including a Consumer App; a 3rd Party end-point indicated by the Consumer such as their PCP's EMR or their Payer's care management team; a Research Repository; etc.) that is given rights to access data on a Resource Service at the direction of the Patient.
| |
| − | | |
| − | The Consumer Initiated Scenario involves the ''Consent Service'' actor.
| |
| − | | |
| − | '''Consent Capture (CC)''' - a stand alone Service that captures the privacy preferences of the Consumer (which performs a similar function to the SMART OAuth interaction where the consumer indicates their privacy preferences interactively with the Authorization Service)
| |
| − | | |
| − | | |
| − | ----
| |
| − | | |
| − | ===Architecture 1) Consumer Access via OAuth===
| |
| − | | |
| − | - A consumer, such as a medicare beneficiary, wishes to authorize the sharing of their health information from a Data Provider, such as CMS, with a consumer controlled app of their choice. The Data Provider wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
| |
| − | | |
| − | :'''Action''': Consumer Authorizes the sharing of their Health Information with an App of their choice using the SMART OAuth pattern to authenticate
| |
| − | :'''Precondition''': Consumer App is registered with the disclosing system (any FHIR based system that holds PHI about the consumer such as an EMR or Payer)
| |
| − | :'''Success Criteria''': Without any special effort of the part of the consumer the disclosing system retains all required information to satisfy regulatory and audit requirements
| |
| − | :'''Bonus point''': Being able to handle a consumer's rescinding of their authorization to disclose
| |
| − | | |
| − | Description of Transactions
| |
| − | | |
| − | :0 – Ceremony where Patient gives rules they want enforced (OAuth Ceremony where Consumer interacts with OAuth flow to convey their sharing preferences)
| |
| − | | |
| − | :0’ – Saving of rules into FHIR Consent resource (may be optional in Architecture a? Where is audit trail captured?)
| |
| − | | |
| − | :1 – Request by App for authorization to access specific data (scope) at Resource Service (target) resulting in an authorization (token+scope)
| |
| − | | |
| − | :2 – Request by App for access to data given the token+scope received in 1
| |
| − | | |
| − | [[File:Architecture1v2.jpg]]
| |
| − | | |
| − | '''Anchor Connectathon Participant''': CMS Blue Button API Team
| |
| − | ----
| |
| − | | |
| − | ===Architecture 2) Consumer Initiated Exchange - sharing 'on behalf of' ===
| |
| − | - A consumer, such as a patient being treated by a Provider that belongs to a Hospital, wishes to authorize the Hospital to share their health information with other providers attributed to them in the Hospital. Data is shared, on-behalf of the consumer, among the authorized providers at the network without the consumer necessarily receiving a copy of the record themselves. The Hospital wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
| |
| − | | |
| − | | |
| − | :'''Action''': Via a user friendly interface a consumer captures their privacy preferences in a computable way
| |
| − | :'''Precondition''': Data holders are subscribed to the services that enable the capture of the consumer's privacy preferences and can electronically share with end-points indicated by the consumer.
| |
| − | :'''Success Criteria''': The designated recipient that the data holder is disclosing to on behalf of the consumer receive all data except that which the consumer's privacy preferences indicate should not be shared it.
| |
| − | :'''Bonus point''': Demonstrate how the solution set will allow the recreation of the consumer's privacy preferences at any point in time in the past following one or more changes in preference settings.
| |
| − | | |
| − | Description of Transactions
| |
| − | | |
| − | :0 – Ceremony where Consumer interacts with the ''Consent Service'' to convey their sharing preferences
| |
| − | | |
| − | :0’ – Saving of rules into FHIR Consent resource
| |
| − | | |
| − | :1’ – Authorization service uses rules from FHIR Consent resource
| |
| − | | |
| − | :1 – Request by App for authorization to access specific data (scope) at Resource Service (target) resulting in an authorization (token+scope)
| |
| − | | |
| − | :2 – Request by App for access to data given token+scope
| |
| − | | |
| − | [[File:Architecture2.jpg]]
| |
| − | | |
| − | '''Anchor Connectathon Participant''': Kathleen Connors
| |
| − | | |
| − | ----
| |
| − | | |
| − | ===Architecture 3) Consumer Initiated Exchange with Distribution Service ===
| |
| − | | |
| − | - A consumer, such as a patient being treated by a Provider that belongs to an HIE, wishes to authorize the HIE to share their health information with other providers attributed to them in the HIE. Data is shared, on-behalf of the consumer, between the providers on the network without the consumer necessarily receiving a copy of the record themselves. The HIE wishes to capture audit information to be able to report a complete accounting of disclosure for the consumer.
| |
| − | | |
| − | | |
| − | :'''Action''': Via a user friendly interface a consumer captures their privacy preferences in a computable way
| |
| − | :'''Precondition''': Data holders are subscribed to the services that enable the capture of the consumer's privacy preferences and can electronically share with end-points indicated by the consumer.
| |
| − | :'''Success Criteria''': The designated recipient that the data holder is disclosing to on behalf of the consumer receive all data except that which the consumer's privacy preferences indicate should not be shared it.
| |
| − | :'''Bonus point''': Demonstrate how the solution set will allow the recreation of the consumer's privacy preferences at any point in time in the past following one or more changes in preference settings.
| |
| − | | |
| − | Description of Transactions
| |
| − | | |
| − | :0 – Ceremony where Consumer interacts with the ''Consent Service'' to convey their sharing preferences
| |
| − | | |
| − | :0’ – Saving of rules FHIR via Questionnaire\Questionnaire Response into Consent Resource and others (*)
| |
| − | | |
| − | :1’ – Authorization service uses rules from FHIR Consent resource
| |
| − | | |
| − | :1 – Request by App for authorization to access specific data (scope) at Resource Service (target) resulting in an authorization (token+scope)
| |
| − | | |
| − | :2 – Request by App for access to data given token+scope
| |
| − | | |
| − | | |
| − | (*) The provider/organizations/actors that the consumer is authorizing sharing with captured in the consent resource. The Questionnaire and QuestionnaireResponse resources hold all the other data.
| |
| − | | |
| − | Bundle {
| |
| − | Consent (Defines the Actors, Providers, Orgs, etc for whom the patient is giving consent to)
| |
| − | Questionnaire (Defines the Questions)
| |
| − | QuestionnaireResponse (Captures the Question Answers)
| |
| − | }
| |
| − | | |
| − | | |
| − | [[File:Architecture_3.jpg]]
| |
| − | | |
| − | | |
| − | '''Anchor Connectathon Participant''': MiHIN
| |
| − | | |
| − | ==Considerations regarding Commonality of Scopes regardless of Architecture==
| |
| − | | |
| − | 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 |
