Skip to end of metadata
Go to start of metadata





1a. Project Name

US Realm Cross Paradigm 32 CFR Part 2002, 42 CFR Part 2, and Title 38 Section 7332 Security Labeling IGs PSS

1b. Project ID

1600

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

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

Security

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

2e. Other Interested Parties (and roles)

Sequoia - Key Stakeholder
Veterans Health Administration
Department of Defense
All recipients of federal agency CUI designated HL7 messages.
All recipients of RCE managed agency security labeled HL7 messages.

2f. Modeling Facilitator

Kathleen Connor, Mohammad Jafari

2g. Publishing Facilitator

Mike Davis, Chris Shawn

2h. Vocabulary Facilitator

Kathleen Connor

2i. Domain Expert Representative

Sequoia - Didi Davis: eHealth Exchange - Jay Nakashima, Eric Heflin

2j. Business Requirements Analyst

Johnathan Coleman, Didi Davis, Jay Nakashima, Eric Heflin

2k. Conformance Facilitator

John Moehrke (FHIR), Sean Muir??(CDA), Kathleen Connor (V2)

2l. Other Facilitators

2m. Implementers

Sequoia
eHealth Exchange
Veterans Health Administration
Department of Defense

3a. Project Scope

To develop computable and interoperable default security labels in three related Implementation Guides, which will profile the security label syntax of three parent specifications: HL7 v2.9, DS4P CDA IG, and the FHIR DS4P IG, which is under development.
See Cross Paradigm CUI, Part 2, and 7332 Structure https://confluence.hl7.org/display/SEC/Cross+Paradigm+CUI%2C+Part+2%2C+and+7332+Structure

The CFR 32 Part 2002 Controlled Unclassified Information (CUI) Security Labeling IG will specify how designating Federal Healthcare Agencies and their contractors are to use HL7 Version 2, CDA, and FHIR security labels to indicate originator and recipient obligations to comply with Controlled Unclassified Information (CUI) policies. CUI policies dictate how:
○ Designating Federal Healthcare Agencies and their contractors (CUI terms such as designating agencies defined at https://www.archives.gov/cui/registry/cui-glossary.html) are to mark and render CUI to end users, and to enforce CUI security controls required of Federal Healthcare Agencies and their contractors
○ Non-federal CUI Recipients must persist, render, and enforce applicable CUI security controls, including NIST SP 800-171
○ A Federal Agency, federal contractor, or a downstream discloser must assign CUI
○ on disclosed information

The 42 CFR Part 2 and Title 38 Section 7332 Security Labeling IGs will specify how designating originators are to use HL7 Version 2, CDA, and FHIR security labels to computably indicate originator and recipient obligations to comply with 42 CFR Part 2 and Title 38 Section 7332. These laws dictate that recipients must comply with specified confidentiality protections for governed sensitive information in accordance with purpose of use limitations, obligations, and prohibitions.

The portions of this guidance for originators and disclosers will be profiles on existing HL7 Version 2.9 security label elements in FHS, BHS, MSH, and the ARV segment; the Data Segmentation for Privacy CDA IG, and FHIR Security Labels. The portions of this guidance for recipients will be platform specific requirements for the "Share with Protections" principles developed by the Security Work Group. Share with Protections principles are to intended to optimize sharing while balancing patient privacy and patient safety by ensuring that recipients persist and comply with the policies conveyed by the security labels assigned to the information they receive.
The V2, CDA, and FHIR CUI and Part2/7332 security labels will be cross mapped to enable transforms. Develop FHIR Trust Contract profile with Labeling Capability Statements for real time verification that sender/receiver are bound under agreements such as eHealth Exchange DURSA or RCE rules.

The resulting pattern for developing policy specific default security labels may be leveraged for other US federal and state privacy and consent directive laws, as well as for international privacy and consent directive laws, such as the General Data Protection Regulation (GDPR).
All resulting IGs will include profiles on the FHIR Data Segmentation for Privacy (DS4P) Implementation Guide PSS.

Attachments

3b. Project Need

To address the goals of the 21st Century Cures Act, participants in US healthcare exchange will be required to share sensitive information in accordance with governing privacy policies. Requirements to meet these laws are addressed in the latest version of the Trusted Exchange Framework and Common Agreement proposal.

This project will focus on two national privacy laws governing sensitive information, 42 CFR Part 2 and Title 38 Section 7332. This IG intends to show how to achieve standards based consensus on default security labels for each policy to ensure interoperability and Share with Protections Trust Contracts .

To address 32 CFR Part 2002, most participants in US healthcare exchange will also be required to share CUI in accordance with CUI policies including:
• Executive Order 13556
• NIST SP 800-171 and NIST SP 800-171A
• CUI Marking Handbook
• CUI Registry - Health Information Category
• CUI Registry: Limited Dissemination Controls
• CUI Policy and Guidance

This IG intends to show how to achieve standards based consensus on default CUI security label for mainstream healthcare information exchange.

Controlled Unclassified Information (CUI) Problem and Solutions https://confluence.hl7.org/display/SEC/Controlled+Unclassified+Information+%28CUI%29+Problem+and+Solutions

3c. Security Risk

No

3d. External Drivers

Federal law: 21st Century Cures Act, 32 CFR Part 2002, 42 CFR Part 2, and Title 38 Section 7332 as well as draft Trusted Exchange Framework and Common Agreement (TEFCA).

3e. Objectives/Deliverables and Target Dates

December 2019 - Get necessary Final WG, SD, FMG, and TSC (deadline 1/5/2020) PSS approvals for May 2020

January 2020 - Draft CUI, Part2, and 7332 Security Labels examples based on FHIR DS4P; V2.9 FHS, BHS, MSH, and ARV; and DS4P CDA IG. Draft use cases, policy background, and explanatory text.

February 2020 - Vet and refine examples and text with domain and business experts for adherence to policy and implementability.

March 2020 - Develop Cross Paradigm IG based on the examples and text in appropriate syntax.

March 1, 2020 - Submit May NIB for V2, CDA, FHIR Security Label IG STU 1 ballot

April 5, 2020 - Final content

May 16, 2020 - Connectathon Track to demonstrate the FHIR Security Label Examples at May Connectathon as part of a FHIR DS4P Track.

June 2020 - Reconcile IG

July 2020 - Revise per reconciliation. Develop transform mappings between security label syntaxes and FHIR Trust Contract with capability statements indicating which security labels are supported.

July 5, 2020 - Submit NIB for V2, CDA, FHIR Security Label IG with FHIR Security Label Trust Contract and Transforms across syntaxes for STU 2 ballot

July 21, 2020 - Submit Sept Connectathon track proposal to demonstrate V2, CDA, FHIR Security Labels with FHIR Security Label Trust Contract and Transforms across syntaxes

July 28, 2020 - Reconciliation deadline

July 28, 2020 - FHIR Ballot Freeze

August 9, 2020 - Final content deadline

Sept 14, 2020 - Begin Reconciliation

Sept 19, 2020 - Connectathon Track to test transforms and Trust Contract profile

October 2020 - Finalize IG content per reconciliation and request publication

3f. Common Names / Keywords / Aliases:

X-Paradigm Security Labeling IG

3g. Lineage

HL7 v2.9 Security Label segments, DS4P CDA IG, and FHIR DS4P IG

3h. Project Dependencies

Concurrent development of FHIR Data Segmentation for Privacy (DS4P) Implementation Guide PSS FHIR Data Segmentation for Privacy (DS4P) Implementation Guide PSS deliverables specifying FHIR security labeling rules in accordance with HL7 Privacy and Security Healthcare Classification System (HCS). This guide will profile FHIR DS4P IG for FHIR CUI, Part 2, and 7332 security labels.

We plan to use existing HL7 security labeling codes and value sets, which are currently bound to security label syntax in V2, DS4P CDA IG, and FHIR. These are extensive and stable.
We regularly add a few for emerging use cases, but nothing extensive.

3i. HL7-Managed Project Document Repository URL:

https://confluence.hl7.org/display/SEC/Cross+Paradigm+US+Security+Labeling+IG

3j. Backwards Compatibility

Yes

3k. Additional Backwards Compatibility Information (if applicable)

V2.9 BHS, FHS, MSH, and ARV fields used for security labeling can be pre-adopted by implementers of earlier versions of HL7 V2. DS4P CDA IG security labeling classes and attributes will be profiled and therefore backwards compatible. FHIR Security Labels will be profiled, again, backwards compatible.

3l. Using Current V3 Data Types?

Yes

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

3m. External Vocabularies

No

3n. List of Vocabularies

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

4a. Products

FHIR Profiles, V2 Messages – Administrative, V2 Messages - Clinical, V2 Messages – Infrastructure, V3 Documents – Clinical (e.g. CDA)

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?

R4

4c. FHIR Profiles Version

4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. White Paper Type

5a. Is the project adopting/endorsing an externally developed IG?

No

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

Expedite for May 2020 ballot to meet US regulatory imperatives.

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

Sequoia
Veterans Health Administration
Department of Defense

6b. Content Already Developed

33% Security Label model (HCS) synax and codes

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

6f. Other Stakeholders

Sequoia, ONC, Federal Agencies, NARA

6g. Vendors

EHR, PHR, Health Care IT, HIS

6g. Other Vendors

6h. Providers

Clinical and Public Health Laboratories, Healthcare Institutions (hospitals, long term care, home care, mental health)

6h. Other Providers

6i. Realm

U.S. Realm Specific

7d. US Realm Approval Date

Dec 17, 2019

7a. Management Group(s) to Review PSS

CDA, FHIR, V2

7b. Sponsoring WG Approval Date

Dec 10, 2019

7c. Co-Sponsor Approval Date

Dec 10, 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

Dec 18, 2019

7f. FMG Approval Date

Dec 11, 2019

7g. V2 MG Approval Date

Dec 13, 2019

7h. Architecture Review Board Approval Date

7i. Steering Division Approval Date

Dec 18, 2019

7j. TSC Approval Date

Jan 03, 2020