This page is part of the FHIR Data Segmentation for Privacy (v1.0.0: STU 1) based on FHIR R4. This is the current published version. For a full list of available versions, see the Directory of published versions
Official URL: http://hl7.org/fhir/uv/security-label-ds4p/ImplementationGuide/hl7.fhir.uv.security-label-ds4p | Version: 1.0.0 | |||
Draft as of 2023-04-17 | Computable Name: HL7_fhir_security_label_ds4p |
This IG provides guidance for applying security labels in FHIR. Security labels are used in access control systems governing the collection, access, use, and disclosure of the target information to which they are assigned, as required by applicable organizational, jurisdictional, or personal policies related to privacy, security, and trust.
The syntactic and semantic rules of the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) provide a conceptual framework for constructing security labels in order to convey computable and interoperable privacy, security, and trust policies. One of the goals of this IG is to provide guidance on how to map and model HCS concepts in FHIR.
From the outset, FHIR has supported security labels with a dedicated optional element (Resource.meta.security
) that can appear on any resource (regardless of resource type), therefore, enabling recording and processing of security labels in a unified manner.
FHIR defines a security label as a data structure of type Coding
which is composed of (among other details), a code
, the identifier of the system
in which the code is defined, and a human readable display
name. The HCS, however, defines Security Label as a different, more complex structure based on the concept of Named Tag Set. This is further discussed in detail in the section on Security Labeling Conceptual Structure, but it is important to bear in mind that the term “security label” refers to different concepts in HCS and in FHIR. Part of the contribution of this IG is to provide guidance on how to map the abstract structures defined by the HCS to FHIR.
Another terminology caveat is the difference between Tags in HCS and in FHIR. In FHIR, meta.tag
is a data structure for capturing general metadata and observations about a resource and is a collection of objects of type Coding
. Tags in HCS, however, are opaque values (equivalent to the code
in a Coding
data structure).
The FHIR Security Labels Module defines the core mechanism for assigning security labels to a FHIR resource and specifies some Core Security Labels, such as purpose of use and confidentiality tag sets. This IG expands on the baseline provided by FHIR Security Labels Module, particularly in the following areas:
Differentiating which set of Resource.meta.security
elements belongs to which policy in the (not uncommon) case where more than one policy applies to a resource,
Designating the entity responsible for classifying the content with the assigned security label,
Referencing related artifacts that are the basis for the policy being conveyed by the label, such as a patient privacy consent directive, the trust contract (which specifies agreed-upon system capabilities between the sender and the receiver), or the source of one or more provenance labels (e.g., FHIR Provenance resources),
Requiring that a privacy mark be displayed to end users, and
Granular data segmentation at the sub-resource level, known as inline labeling.
The FHIR Security Label Module points out that security labels are intended to convey a policy to which participants in an exchange ecosystem are bound by a trust contract:
“Security labels are only a device to connect specific resources, bundles, or operations to a wider security framework; a full set of policy and consent statements and their consequent obligations is needed to give the labels meaning. Because of this, security labels are most effective in fully trusted environments - that is, where all trading partners have agreed to abide by them in a Mutual Trust Framework. Note also that security labels support policy, and specific tagging of individual resources is not always required to implement policy correctly.”
The FHIR Security Label Module also notes that the recipient must implement and abide by the policies conveyed or implied by security labels:
“The intent of a security label is that the recipient of resources or bundles with security tags is obligated to enforce the handling caveats of the tags and carry the security labels forward as appropriate.”
These policies represented by security labels may be stipulated by laws and/or agreed to in contracts (e.g., Data Use Reciprocal Service Agreements (DURSA)). While such agreements are typically documented in the form of legal documents, they may also be established computably through trust contracts with system capability statements that are binding for the sender and receiver and describe:
The manner in which computable trust agreements may be negotiated, established, discovered, and shared in a federated ecosystem is described in the HL7 Privacy and Security Architecture Framework, Volumes 1 & 2, Trust Framework for Federated Authorization Conceptual and Behavioral Models, which could be leveraged for trust agreements between senders and receivers of labeled HL7 content such as FHIR resources. This IG sets the groundwork for doing so in future iterations of this guide –as discussed in the Roadmap section below.
HL7 has already developed HL7 Version 2 (V2) and Clinical Document Architecture (CDA) platform specific syntactical standards for segmenting information using security labels in accordance with the normative, platform independent HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) conceptual model.
The HL7 V2 security label guidance is incorporated in HL7 Version 2.9, Chapter 3, Patient Administration Access Control Restriction Value Segment (ARV), and the Chapter 2 Control description of the Batch Header Segment (BHS), the File Header Segment (FHS), and the Message Header Segment (MSH).
The HL7 Implementation Guide: Data Segmentation for Privacy (DS4P) [for CDA], Release 1 specifies the use of security labeling at the CDA Header, Section and Entry levels.
In V2 and CDA, the HCS security label semantics are conveyed by assigning codes from normative HL7 security label value sets to the respective security label elements. This IG uses the same value sets as detailed in the Value Set Summary.
Note that the DS4P CDA IG is constrained to the “Basic Confidentiality” value set, a subset of the full Confidentiality code system, although this constraint does not apply to this IG. Therefore, the DS4P CDA IG will not be able to support security labels with Confidentiality codes U
(unrestricted), L
(low), and M
(moderate).
In the US:
implementation of the CDA DS4P IG at the Header Level was included as an optional Certified EHR Certification criteria in the original 2015 Edition Health Information Technology (Health IT) Certification Criteria,
45 CFR § 170.315 - 2015 Edition Health IT Certification Criteria and ONC Health IT Certification Program Modifications (Final Rule – October 16, 2015).
In 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program, the ONC revised the security tag certification criteria in 45 CFR § 170.315 - 2015 Edition health IT certification criteria at (b)(7) and (b)(8) by requiring certification at the more granular Section and Entry levels after December 31, 2022.
According to the ONC Certified HIT Product List (CHLP), 64 EHR Products are certified to meet segmentation at the Header level, which requires appropriately valuing the Clinical Document confidentiality element with a confidentiality code from the CDA Basic Confidentiality value set. Two EHR Products have been certified to granular DS4P criteria updated in the 2020 CURES Rule.
The HL7 CDA® R2 Implementation Guide: Data Provenance, Release 1 - US Realm provides more detailed description about all tags available for use in security labels, and how provenance capabilities in CDA can be used to persist a chain of security labels so as to, for example, record when a label was reclassified by a previous CDA author or custodian.
Using security labels is an essential part of the Share with Protections paradigm by enabling information to be shared after assigning the security labels specifying how the information can be used and the restrictions to which it may be subject.
This IG is policy agnostic. It provides a foundation for a variety of security labeling capabilities that systems may find useful for communicating policies governing information conveyed by FHIR Resources.
Generally, this guide is intended to be implemented as a tool to enable development of use-case-specific security labels. More specific implementation guides to address the requirements of specific use cases can be derived from this IG. It is necessary for solutions to be designed with a policy use case in mind to ensure that there’s affirmation of technical support between systems, and a shared understanding of business obligations and policies represented by security labeled resources.
FHIR DS4P IG is an evolving specification that will encompass more capabilities in future ballots. Anticipated enhancements on the roadmap for the upcoming ballot cycles include:
The main sections of this IG are:
The following sections are informative: