Skip to end of metadata
Go to start of metadata




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 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

2f. Modeling Facilitator

Kathleen Connor, Greg White

2g. Publishing Facilitator

John Moehrke, Dave Pyke

2h. Vocabulary Facilitator

Kathleen Connor, Peter van Liesdonk

2i. Domain Expert Representative

Suzanne Gonzales Webb, Mohammad Jafari, Benoit Schoeffler, Claudia Negri, Aurelie Bayle

2j. Business Requirements Analyst

Shreya Patel (MiHIN), Kyle Bradford (LPHI), Dr. Shane McNamee (Perspecta), Debi Willis (PatientLink), Amber Patel (SRS), Theresa Aardal Connor (HL7 Norway)

2k. Conformance Facilitator

John Moehrke, Dave Pyke

2l. Other Facilitators

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.

3i. HL7-Managed Project Document Repository URL:

FHIR DS4P Project https://confluence.hl7.org/display/SEC/FHIR+DS4P+Project

3j. Backwards Compatibility

No

3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?

N/A

3l. Reason for not using current V3 data types?

Not using because not V3, it's FHIR so using FHIR datatypes.

3m. External Vocabularies

No

3n. List of Vocabularies

3o. Earliest prior release and/or version to which the compatibility applies

4a. Products

FHIR Implementation Guide, FHIR Profiles, FHIR Resources, Guidance (e.g. Companion Guide, Cookbook, etc)

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 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.

no

6a. External Project Collaboration

6b. Content Already Developed

HL7 HCS, FHIR Security Labels and Security Module, FHIR Consent & Contract

6c. Content externally developed?

No

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


























5 Comments

  1. 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.

    1. 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.

  2. Kathleen Connor Question from FMG: Why is the response in 3.c., security risk, "yes?"

    1. 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?