| Submitted By: TICIA Louise GERBER / Health Level Seven International | |
|---|---|
| Data Element Information | |
| Rationale for Separate Consideration | If a Security Label represents a policy, the Policy tag is essential to explain why the same information sensitivity is additionally protected if it is generated or disclosed where the policy mandates a higher level of confidentiality protection. |
| 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. |
| Estimated number of stakeholders capturing, accessing using or exchanging | 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. |
| Estimated number of stakeholders capturing, accessing using or exchanging | 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 |
|
| 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 |
| Number of organizations/individuals with which this data element has been electronically exchanged | 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. |
Data Element |
Information from the submission form |
|---|---|
| Security Label Policy Tag |
Description
A Policy tag is the 0..1 component of a Security Label that conforms to follows the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to represent the policy governing of the information assigned a Security Label. The policy represented by this code is the authoritative source of the type of information deemed sensitive and the level of confidentiality protection to be provided. Policies may pertain to privacy, security, research, trust, etc., and may be issued by a jurisdiction, an organization, or an individual, e.g., by a consent directive. In addition, the policy may limit the permissible purposes of use, and the obligations and prohibited actions which may be taken by senders and receivers, which are conveyed using other types of tags in the Security Label representing a specific policy. HL7 recommends creating a value set of Policy codes to value the Policy tag, which are specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development. For example, the US Controlled Unclassified Information (CUI) policy 32 CFR Part 2002, established the executive branch’s CUI Program, policy for designating, handling, and decontrolling information that qualifies as CUI, and the security mechanisms by which the confidentiality of CUI is enforced. This rule affects Federal executive branch agencies that handle CUI and all organizations (sources) that handle, possess, use, share, or receive CUI—or which operate, use, or have access to Federal information and information systems on behalf of an agency. https://www.archives.gov/cui/about As a result, most entities exchanging health information in the US will likely either mark CUI or receive CUI, and will be required to comply with this regulation. CUI exchanged using HL7 standards will need to indicate that the recipient must comply with this regulation using a security label with a Policy tag for 32 CFR Part 2002. HL7 Cross Paradigm US Security Labeling IG is under development to standardize CUI labeling for use with HL7 Version 2, CDA, and FHIR specifications. For Policy codes used to populate Security Label Policy tags, see HL7 PolicyType value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-ActPolicyType.html
|
Comment