| Submitted By: TICIA Louise GERBER
/ Health Level Seven International
|
| Data Element Information |
| Rationale for Separate Consideration |
A Security Label must have 1..1 Confidentiality code, but may have 0..* Sensitivity codes depending on the policy conveyed. The Sensitivity tag is an optional component of a Security Label, understood in the context of relevant tags representing a policy. |
| Use Case Description(s) |
| Use Case Description |
To support development of interoperable, consensus Security Labels for priority policies, governing healthcare information that is mandated to be shared under the ONC Cures Act Final Rule and the CMS Interoperability and Patient Access Final Rule. Adoption would enable computable data segmentation rather than requiring manual segmentation, where feasible, under the Information Blocking provisions.
To enable the collection, management, and enforcement of priority patient consent directives in support of:
• 42 CFR Part 2 consent to share
• Title 38 Section 7332 opt-out of sharing
• HIPAA Consent to restrict disclosure of information related to health care items or services for which the individual pays out of pocket in full to a health plan or payer
• HIPAA Individual Right of Access requests for disclosure of health information to the patient or to a third party
• HIPAA Authorization to Disclose for research, workers’ compensation, disability insurance, SSI, etc.
• State privacy laws related to sharing of minors’, HIV, abuse violence, mental, and behavioral health information
To support CEHRT implementers of the optional document and granular Data Segmentation certification criteria.
To support granular privacy protection of minors’ and seniors’ health information as described in by the American Academy of Pediatrics and promoted by the HIMSS Protecting Privacy to Promote Interoperability Work Group.
To support consumer’s control of shared health information as promoted by several Privacy Frameworks proposed by eHealth Exchange and Center for Democratic Technology; the American Medical Association; Carin Alliance; and others.
|
| Estimate the breadth of applicability of the use case(s) for this data element
|
As noted in the Rule at page 216: “Stakeholders have shared with ONC – through public forums, listening sessions, and correspondence – that document-level security tagging does not provide enough flexibility to address more complex privacy and security use cases. Stakeholders noted that certain provider types, such as pediatrics and behavioral health, often rely on burdensome manual workflows to appropriately segment and share sensitive health information according to State and local laws.” For this reason, ONC “proposed to replace the removed DS4P criteria with two new 2015 Edition DS4P certification criteria in § 170.315(b)(12) and § 170.315(b)(13) that would support security tagging according to the DS4P standard at the document, section, and entry levels of C-CDA 2.1 formatted documents.”
At this time, there are 38 Health IT Modules certified to one or both of the current 2015 Edition DS4P certification criteria for document level segmentation. That’s up from the 34 Health IT Modules cited in the ONC Final Cures Rule page 216. There are no Health IT Modules certified to the new 2015 Edition granular segmentation criteria listed in CPHL website.
However, this may change soon if the final TEFCA includes the Security Labeling requirements described in "A User’s Guide to Understanding the Trusted Exchange Framework and Common Agreement Draft 2" as follows:
ONC is considering the inclusion of a new requirement regarding security labeling that states the following:
• Any EHI containing codes from one of the SAMHSA Consent2Share sensitivity value sets for mental health, HIV, or substance use in Value Set Authority Center (VSAC) shall be labeled.
• Any EHI for patients considered minors shall be electronically labeled.
• The data holder responding to a request for EHI is obligated to appropriately apply security labels to the EHI.
• At a minimum, EHI shall be electronically labeled using the confidentiality code set as referenced in the HL7 Version 3 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (DS4P IG), Part 1: CDA R2 and Privacy Metadata.
• Labeling shall occur at the highest (document or security header) level.
If Security Labeling is included, there will be a vast increase in the number of implementers
|
| Link to use case project page |
https://www.youtube.com/watch?v=67AZbzknsJs https://www.youtube.com/watch?v=yUkQNbRYuqg https://pediatrics.aappublications.org/content/130/5/987 |
| Use Case Description |
To support the 32 CFR Part 2002 requirement to mark Controlled Unclassified Information (CUI) healthcare information using computable and interoperable CUI Security Labels on HL7 content generated by Federal agencies and their contractors, and to facilitate the persistence, enforcement, and re-disclosure of CUI markings by authorized holders and recipients. |
| Estimate the breadth of applicability of the use case(s) for this data element
|
Any participant in health information exchange that generates or receives CUI, which likely includes almost all Covered Entities who serve patients or members affiliated with a Federal Health Agency. It may include other secondary use entities such as research, public health, and Health Oversight Agencies |
| Link to use case project page |
https://confluence.hl7.org/pages/viewpage.action?pageId=40743226 |
| Healthcare Aims |
- Improving patient experience of care (quality and/or satisfaction)
- Improving the health of populations
- Improving provider experience of care
|
| Maturity of Use and Technical Specifications for Data Element |
| Applicable Standard(s) |
HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.
https://build.fhir.org/ig/HL7/UTG/CodeSystem-v3-Confidentiality.html https://build.fhir.org/ig/HL7/UTG/CodeSystem-v3-Confidentiality.html
|
| Additional Specifications |
FHIR Data Segmentation for Privacy 0.2.0 - STU 1 Ballot
http://hl7.org/fhir/uv/security-label-ds4p/2020May/
Security for US Government Regulations 0.1.0 - CI Build
https://build.fhir.org/ig/HL7/us-security-label-regs/branches/master/index.html
|
| Current Use |
In limited use in production environments |
| Supporting Artifacts |
For C-CDA transmission, document level DS4P is required in the C-CDA General Header. Therefore, adoption levels may be higher for document level tagging (vs. section level).
https://www.healthit.gov/isa/data-segmentation-sensitive-information#comment-3191
|
| Extent of exchange
|
5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
| Supporting Artifacts |
For C-CDAs – all must include a Confidentiality code at the Document Class,
NHIN Authorization Framework Specification v 3.0
https://sequoiaproject.org/wp-content/uploads/2014/11/nhin-authorization-framework-production-specification-v3.0.pdf
C-CDA (HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes - US Realm)
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492
|
| Potential Challenges |
| Restrictions on Standardization (e.g. proprietary code) |
N/A |
| Restrictions on Use (e.g. licensing, user fees) |
None |
| Privacy and Security Concerns |
Concerns:
*Improperly labeled information, which might result in unauthorized access or might restrict authorized access;
*Recipient unable to consume, persist, enforce, or downstream labels; and
*CDS without the ability to alert unauthorized clinicians to break the glass for patient safety issues.
|
| Estimate of Overall Burden |
No notable burden. |
Official Website of The Office of the National Coordinator for Health Information Technology (ONC)
Comment