FHIR Data Segmentation for Privacy (DS4P) Implementation Guide
1b. Project ID
1549
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
No
1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?
No
1e. Today's Date
May 21, 2019
1f. Name of standard being reaffirmed
1g. Project Artifact Information
1h. ISO/IEC Standard to Adopt
1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?
1j. Unit of Measure
2a. Primary/Sponsor WG
Public Health
2b. Co-Sponsor WG
Community Based Care and Privacy
2c. Co-Sponsor Level of Involvement
Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)
2c. Co-Sponsor Update Periods
Monthly
2d. Project Facilitator
Mike Davis, Chris Shawn, Johnathan Coleman
2e. Other Interested Parties (and roles)
Current and Prospective Implementers, and possible Connectathon DS4P participants:
*Perspecta: Dr. McNamee CMIO, Bo Dagnall, Joyce Dunlop
*Debi Willis, PatientLink; President and Founder
*MiHIN
*VA Mike Davis, VHA Security Architect, Chris Shawn, Security Cochair/VA, Mohammad Jafari & Kathleen Connor BZ/VA
Craig Newman and Matt Lord for Cross-Paradigm Security Label mapping
2m. Implementers
VA
MiHIN
LPHI
PatientLink
Perspecta
Almerys
3a. Project Scope
Provide FHIR guidance for applying security labels with coded tags for use in access control systems governing the collection, access, use, and disclosure of the target FHIR Resource(s) as required by applicable organizational, jurisdictional, or personal "sharing with protection" policies.
The IG will include guidance on:
*Marking healthcare and personal information disseminated by US Federal agencies per Executive Order 13556 Controlled Unclassified Information (CUI), and US Code of Federal Regulations32 C.F.R. § 2002 in the Federal Register and the General Services Administration (GSA) policy and framework for Controlled Unclassified Information (CUI), 2103.1 CIO Controlled Unclassified Information (CUI) Policy.
*How to select a security label based on the HL7 Privacy and Security Healthcare Classification System (HCS) label adjudication algorithms, the value in establishing consensus on a default security label for representing policies or consent directives within an exchange ecosystem, and the value of establishing default security labels for information exchanged within the Trust Framework of a policy domain.
*How an Access Control System, such as an OAuth Authorization Server can use the security labels to filter responses to person/population based queries and pushed disclosures that meets:
- Authorization Requirements specifying control over whether or not a client’s request for import or export of person/population Resources will be permitted
- Filtering Requirements specifying, at a more fine-grained level, what resources will appear in the results of a person/population export or accepted in an import operation
- Transformation Requirements specifying the requirements for applying functions on imported or exported person/population Resources, which modify and transform the content of any Resource per applicable privacy/security policies and/or data subject's(s') consent directive
- Provenance Requirements specifying the recording and consumption of provenance information in a person/population Resource(s) export or import operation.
*Further development of HL7 security labeling vocabulary to enhance provenance and trust labeling to meet HL7 Provenance efforts including the PSAF Provenance DAM, Basic Provenance project, and updates to the CDA DPROV IG.
Addition of security label vocabulary to meet international affiliate needs, including GDPR security labeling vocabulary requirements determined by the Security WG GDPR WG.
Address the need to restructure FHIR Security label structure to enable demarcation of multiple applicable security labels into privacy tag sets representing each policy.
Develop a profile on Narrative to enable specification of the manner in which security label "privacy marks" are rendered, e.g., per CUI requirements.
Attachments
3b. Project Need
To replicate and enhance the implementation guidance provided by the CDA Data Segmentation for Privacy IG and HL7 V2.9 security labeling segments in response to growing need in the US and internationally to share healthcare information with protections.
3c. Security Risk
No
3d. External Drivers
General Data Protection Regulation (GDPR), Trusted Exchange Framework for Common Agreement (TEFCA), CMS Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally Facilitated Exchanges and Health Care Providers CMS-9115-P, and ONC 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification
3e. Objectives/Deliverables and Target Dates
*Initiate project calls and modeling during January 2020 WGM to determine resource appropriate project milestones with focus on "low hanging fruit" approach to incrementally developing & balloting the IG.
*Continue IG development and guidance during the interim on FHIR Security calls
*Ballot as FHIR IG May 2020
*Connectathon test project artefacts being balloted in May
*Reconcile and revise IG @ May WGM and during interim May-August 2020.
*Ballot as FHIR IG September 2020
*Connectathon test project artefacts being balloted in September 2020
*Reconcile and revise IG @ September WGM and during interim September - December 2020
*Ballot as FHIR IG January 2021.
*Connectathon test project artefacts being balloted January 2021
*Reconcile and revise IG @ January 2021 WGM and during interim January - May 2021
*Rinse and Repeat IG Balloting, Testing, Reconcilation and Revsions as needed until approved standard.
3f. Common Names / Keywords / Aliases:
FHIR DS4P IG
3g. Lineage
CDA DS4P IG, HL7 V2.9 security labeling segments
3h. Project Dependencies
Approval/implementation of HL7 security labeling vocabulary within scope.
Approval of changes to FHIR Security Labeling structures and Narrative profile that supports rules for rendering privacy marks.
Input from a normative PSAF Provenance DAM, Basic Provenance project, and updates to the CDA DPROV IG.
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
R4 and v-next if established within IG development period.
4c. FHIR Profiles Version
R4 and v-next if established within IG development period.
4d. Please define your New Product Definition
4d. Please define your New Product Family
5a. Project Intent
Create new standard
5a. White Paper Type
5a. Is the project adopting/endorsing an externally developed IG?
5a. Externally developed IG is to be (select one)
5a. Specify external organization
5a. Revising Current Standard Info
5b. Project Ballot Type
STU to Normative
5c. Additional Ballot Info
Plan to ballot FHIR DS4P IG components incrementally, e.g., starting with "low hanging fruit" change requests for a FHIR "security labeling lite" subset of the entire HCS security labeling vocabulary. We plan to develop a detailed project plan during the January 2020 WGM (deferred to May 2020 meeting) to align with funding/volunteer resources known @ that time, and to update as this alignment changes.
5d. Joint Copyright
No
5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.
6d. List Developers of Externally Developed Content
6e. Is this a hosted (externally funded) project?
No
6f. Stakeholders
Regulatory Agency, Standards Development Organizations (SDOs), Payors, Other
6f. Other Stakeholders
HIT Vendors, Providers, Healthcare Consumers, HIEs
6g. Vendors
EHR, PHR, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6g. Other Vendors
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health), Other
6h. Other Providers
Community based and long term services and support providers
6i. Realm
Universal
7d. US Realm Approval Date
7a. Management Group(s) to Review PSS
FHIR
7b. Sponsoring WG Approval Date
Jun 18, 2019
7c. Co-Sponsor Approval Date
Jun 04, 2019
7c. Co-Sponsor 2 Approval Date
7c. Co-Sponsor 3 Approval Date
7c. Co-Sponsor 4 Approval Date
7c. Co-Sponsor 5 Approval Date
7c. Co-Sponsor 6 Approval Date
7c. Co-Sponsor 7 Approval Date
7c. Co-Sponsor 8 Approval Date
7c. Co-Sponsor 9 Approval Date
7c. Co-Sponsor 10 Approval Date
7e. CDA MG Approval Date
7f. FMG Approval Date
Jul 24, 2019
7g. V2 MG Approval Date
7h. Architecture Review Board Approval Date
7i. Steering Division Approval Date
Jul 23, 2019
7j. TSC Approval Date
Aug 05, 2019
Version
1
Modifier
Anne Wizauer
Modify Date
Sep 11, 2019 17:00
1a. Project Name
FHIR Data Segmentation for Privacy (DS4P) Implementation Guide
1b. Project ID
1549
1c. Is Your Project an Investigative Project (aka PSS-Lite)?
No
1d. Is your Project Artifact now proceeding to Normative directly or after being either Informative or STU?
No
1e. Today's Date
May 21, 2019
2a. Primary/Sponsor WG
Publishing
2b. Co-Sponsor WG
Community Based Care and Privacy
2c. Co-Sponsor Level of Involvement
Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)
2c. Co-Sponsor Update Periods
Monthly
2d. Project Facilitator
Mike Davis, Chris Shawn, Johnathan Coleman
2e. Other Interested Parties (and roles)
Current and Prospective Implementers, and possible Connectathon DS4P participants:
*Perspecta: Dr. McNamee CMIO, Bo Dagnall, Joyce Dunlop
*Debi Willis, PatientLink; President and Founder
*MiHIN
*VA Mike Davis, VHA Security Architect, Chris Shawn, Security Cochair/VA, Mohammad Jafari & Kathleen Connor BZ/VA
Craig Newman and Matt Lord for Cross-Paradigm Security Label mapping
2m. Implementers
VA
MiHIN
LPHI
PatientLink
Perspecta
Almerys
3a. Project Scope
Provide FHIR guidance for applying security labels with coded tags for use in access control systems governing the collection, access, use, and disclosure of the target FHIR Resource(s) as required by applicable organizational, jurisdictional, or personal "sharing with protection" policies.
The IG will include guidance on:
*Marking healthcare and personal information disseminated by US Federal agencies per Executive Order 13556 Controlled Unclassified Information (CUI), and US Code of Federal Regulations32 C.F.R. § 2002 in the Federal Register and the General Services Administration (GSA) policy and framework for Controlled Unclassified Information (CUI), 2103.1 CIO Controlled Unclassified Information (CUI) Policy.
*How to select a security label based on the HL7 Privacy and Security Healthcare Classification System (HCS) label adjudication algorithms, the value in establishing consensus on a default security label for representing policies or consent directives within an exchange ecosystem, and the value of establishing default security labels for information exchanged within the Trust Framework of a policy domain.
*How an Access Control System, such as an OAuth Authorization Server can use the security labels to filter responses to person/population based queries and pushed disclosures that meets:
- Authorization Requirements specifying control over whether or not a client’s request for import or export of person/population Resources will be permitted
- Filtering Requirements specifying, at a more fine-grained level, what resources will appear in the results of a person/population export or accepted in an import operation
- Transformation Requirements specifying the requirements for applying functions on imported or exported person/population Resources, which modify and transform the content of any Resource per applicable privacy/security policies and/or data subject's(s') consent directive
- Provenance Requirements specifying the recording and consumption of provenance information in a person/population Resource(s) export or import operation.
*Further development of HL7 security labeling vocabulary to enhance provenance and trust labeling to meet HL7 Provenance efforts including the PSAF Provenance DAM, Basic Provenance project, and updates to the CDA DPROV IG.
Addition of security label vocabulary to meet international affiliate needs, including GDPR security labeling vocabulary requirements determined by the Security WG GDPR WG.
Address the need to restructure FHIR Security label structure to enable demarcation of multiple applicable security labels into privacy tag sets representing each policy.
Develop a profile on Narrative to enable specification of the manner in which security label "privacy marks" are rendered, e.g., per CUI requirements.
3b. Project Need
To replicate and enhance the implementation guidance provided by the CDA Data Segmentation for Privacy IG and HL7 V2.9 security labeling segments in response to growing need in the US and internationally to share healthcare information with protections.
3c. Security Risk
No
3d. External Drivers
General Data Protection Regulation (GDPR), Trusted Exchange Framework for Common Agreement (TEFCA), CMS Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally Facilitated Exchanges and Health Care Providers CMS-9115-P, and ONC 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification
3e. Objectives/Deliverables and Target Dates
*Initiate project calls and modeling during January 2020 WGM to determine resource appropriate project milestones with focus on "low hanging fruit" approach to incrementally developing & balloting the IG.
*Continue IG development and guidance during the interim on FHIR Security calls
*Ballot as FHIR IG May 2020
*Connectathon test project artefacts being balloted in May
*Reconcile and revise IG @ May WGM and during interim May-August 2020.
*Ballot as FHIR IG September 2020
*Connectathon test project artefacts being balloted in September 2020
*Reconcile and revise IG @ September WGM and during interim September - December 2020
*Ballot as FHIR IG January 2021.
*Connectathon test project artefacts being balloted January 2021
*Reconcile and revise IG @ January 2021 WGM and during interim January - May 2021
*Rinse and Repeat IG Balloting, Testing, Reconcilation and Revsions as needed until approved standard.
3f. Common Names / Keywords / Aliases:
FHIR DS4P IG
3g. Lineage
CDA DS4P IG, HL7 V2.9 security labeling segments
3h. Project Dependencies
Approval/implementation of HL7 security labeling vocabulary within scope.
Approval of changes to FHIR Security Labeling structures and Narrative profile that supports rules for rendering privacy marks.
Input from a normative PSAF Provenance DAM, Basic Provenance project, and updates to the CDA DPROV IG.
4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?
R4 and v-next if established within IG development period.
4c. FHIR Profiles Version
R4 and v-next if established within IG development period.
5a. Project Intent
Create new standard
5b. Project Ballot Type
STU to Normative
5c. Additional Ballot Info
Plan to ballot FHIR DS4P IG components incrementally, e.g., starting with "low hanging fruit" change requests for a FHIR "security labeling lite" subset of the entire HCS security labeling vocabulary. We plan to develop a detailed project plan during the January 2020 WGM to align with funding/volunteer resources known @ that time, and to update as this alignment changes.
Regulatory Agency, Standards Development Organizations (SDOs), Payors, Other
6f. Other Stakeholders
HIT Vendors, Providers, Healthcare Consumers, HIEs
6g. Vendors
EHR, PHR, Health Care IT, Clinical Decision Support Systems, Lab, HIS
6h. Providers
Clinical and Public Health Laboratories, Emergency Services, Local and State Departments of Health, Medical Imaging Service, Healthcare Institutions (hospitals, long term care, home care, mental health), Other
6h. Other Providers
Community based and long term services and support providers
As discussed in FMG, we would like to ask there be clarification on how this project plans to address, or rely on other projects, to provide guidance on how policies translate to labeling at what level of granularity to enable systems to lighten the documentation burden of clinicians, and clarity of consumers managing their consent, to make this actually work. I.e., the ability to technically label resources does not solve the practical implementation and deployment challenges without such guidance as currently noticed with DS4P for C-CDA. This is not necessarily meant to suggest this project must solve that. It can acknowledge and point to another project, but cannot ignore it.
Thanks for these questions, Hans. As stated in the Project Scope section, the intent is to address practical implementation and deployment challenges by describing approaches communities can use to develop default security labels to represent applicable jurisdictional, organizational, and personal privacy policies and consent directives. Default security labels can ease adoption by establishing an agreed-to interoperable representation of applicable policies. Users will know in advance the policies with which they must comply. Developers will be able to minimize impacts on their systems. Guidance on how to structure policies as labels will be given. Examples of actual efforts to do so will be given. Residual issues related to achieving community consensus, promoting adoption, onboarding and user training, and maintenance of the adopted security labels in response to changes in the base standards will be raised but not solved.
3.c security risks should be marked "no". My mistake. There would not be any code that poses security risk involved. Not sure whether changing this is considered substantive enough to cause the PSS to have to be revoted or is it enough to get approval from Security WG, and if approved, notify InfraSD voters?
5 Comments
Kathleen Connor
InfraSD Vote page https://confluence.hl7.org/display/ISD/FHIR+DS4P+IG+PSS+Approval
Hans Buitendijk
As discussed in FMG, we would like to ask there be clarification on how this project plans to address, or rely on other projects, to provide guidance on how policies translate to labeling at what level of granularity to enable systems to lighten the documentation burden of clinicians, and clarity of consumers managing their consent, to make this actually work. I.e., the ability to technically label resources does not solve the practical implementation and deployment challenges without such guidance as currently noticed with DS4P for C-CDA. This is not necessarily meant to suggest this project must solve that. It can acknowledge and point to another project, but cannot ignore it.
Kathleen Connor
Thanks for these questions, Hans. As stated in the Project Scope section, the intent is to address practical implementation and deployment challenges by describing approaches communities can use to develop default security labels to represent applicable jurisdictional, organizational, and personal privacy policies and consent directives. Default security labels can ease adoption by establishing an agreed-to interoperable representation of applicable policies. Users will know in advance the policies with which they must comply. Developers will be able to minimize impacts on their systems. Guidance on how to structure policies as labels will be given. Examples of actual efforts to do so will be given. Residual issues related to achieving community consensus, promoting adoption, onboarding and user training, and maintenance of the adopted security labels in response to changes in the base standards will be raised but not solved.
Anne Wizauer
Kathleen Connor Question from FMG: Why is the response in 3.c., security risk, "yes?"
Kathleen Connor
3.c security risks should be marked "no". My mistake. There would not be any code that poses security risk involved. Not sure whether changing this is considered substantive enough to cause the PSS to have to be revoted or is it enough to get approval from Security WG, and if approved, notify InfraSD voters?