Data Element
Security Label Confidentiality Tag
Description

A Confidentiality tag is the 1..1 component of a Security Label that conforms to the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) syntax to represent the level of protection prescribed by a policy governing the information to which a label is assigned. The HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) can be found at: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=345 HL7 recommends creating a value set of Confidentiality codes specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development and can be found at: https://build.fhir.org/ig/HL7/us-security-label-regs/branches/master/index.html For v3 HL7 Confidentiality Codes, see the Confidentiality value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v2-0952.html For background on use of Confidentiality codes, see https://confluence.hl7.org/display/SEC/Use+of+Confidentiality+Codes+in+HL7+Security+Labeling . For use of Confidentiality codes in CDA, see HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1. For use of Confidentiality codes in FHIR see http://hl7.org/fhir/uv/security-label-ds4p/2020May/background.html For use of Confidentiality codes in HL7 Version 2, see v2.9 ARV Segment.
Submitted By: TICIA Louise GERBER / Health Level Seven International
Data Element Information
Rationale for Separate Consideration Confidentiality codes are required in all CDA profiles, including C-CDA, at the Document header class, in the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, in the HL7 Version 2.9 BHS, FHS, MSH, and ARV Segments, and in the FHIR Data Segmentation for Privacy IG. These standards require that the appropriate Confidentiality code required by the governing policy be included. E.g., if the content is governed by HIPAA, the Confidentiality code must be “N” for the normal level of protection for healthcare information in the US realm. If the content is governed as additionally protected information, the Confidentiality code must be “R” for a restricted level of access. If the content is released outside of HIPAA or laws that more stringently protect confidentiality, such as when an individual exercises HIPAA Right of Access, then the Confidentiality code must be “M” for moderate protections under laws that are less protective than HIPAA, such as FTC Consumer Protection Laws. The Confidentiality tag is a mandatory component of a Security Label, the meaning of which is understood in the context of the set 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.

Comment

Log in or register to post comments