FHIR Data Segmentation for Privacy
1.0.0 - trial-use International flag

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 in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Home

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.

Terminology Caveats

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 Need for a FHIR DS4P Implementation Guide

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.

Trust and Enforcement

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:

  • how policy-specific security labels will be assigned, consumed, and persisted,
  • reclassification rules, and
  • any information-handling restrictions and obligations.

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:

Intended Applications

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.

Roadmap

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:

  • More examples and use cases from jurisdictions other than the US.
  • More comprehensive discussion and guidelines on High Water Mark (HWM) labels, including use cases and possible algorithms for calculating a HWM and approaches for communicating how a HWM is intended to be understood and handled by receivers.
  • How security labels are used in Attribute-Based Access Control (ABAC)
  • Use cases for security labels representing trust contracts and inclusion of trust tags in security labels generally to convey expectations of senders and receivers such as persisting labels and whether labels can be reclassified or removed
  • Using Structured Definitions and Capability Statements as Security Policy Information Files (SPIF) to establish rules for constructing and interpreting shared security labels, which can be negotiated, executed, and registered in a discoverable manner
  • Use of Clinical Quality Language (CQL) to specify security labeling rules.
  • Use of Business Process Modeling Notation (BPMN) to describe shared workflows in which labeled content is collected, accessed, used or disclosed. Purpose of use labels are not sufficient to convey the activities that a policy may permit or deny a recipient to conduct. A security label conveying a FHIR Consent for example, where a patient only permits access and use, but not collection or disclosure of protected health information for treatment purposes in an emergency and inpatient setting needs more than a policy tag with a reference to the specific FHIR consent and a purpose of use tag for treatment.

Walk-Through

The main sections of this IG are:

Informative Sections

The following sections are informative: