Skip to end of metadata
Go to start of metadata

Reference Material about Security Labels

HL7 Security Labeling - Based on the HL7 Healthcare Privacy and Security Classification System (HCS) - A Multi-level Security Model

HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 


International standard document describing the use of a Healthcare Privacy and Security Classification System (HCS) suitable for automated labeling and segmentation of protected health care information by access control systems to enforce privacy and security policies. Download

Security Label Guidance across HL7 Product Families

HL7 Version 2 Security Labels

HL7 Version 2.9 supports security labels, include labels for marking US Federal agency managed and disseminated controlled unclassified information (CUI).  Some of this capability is discussed in Chapter 1 Introduction at page 18:

1.8.2 Protection of Healthcare Information: HL7 provides a standardized way of exchanging requirements for restrictions as well as identifying the data affected by privacy law and confidentiality rules. HL7 has developed the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (see:   In v2.9 this vocabulary can be used in the following segments: • Message Header segment (MSH) in chapter 2.14.9 • User Access Control segment (UAC) in chapter 2.4.15 • Access Restriction segment (ARV) in chapter 3.3.14 • Consent segment (CON) in chapter 9.7.1 Implementers are encouraged to make use of these fields in their respective implementation guides.

Note that implementers of earlier HL7 V2 specification may pre-adopt the use of security labels from HL7 V2.9 to support Data Segmentation for Privacy and CUI Marking.

HL7 Version 3 and CDA Security Labels

DS4P CDA and DPROV CDA IG Security discussion ….

FHIR Security Labels

FHIR has built the privacy and security capabilities that labeling supports "in by design" from the beginning. See FHIR Security Label Module for full guidance. 

Module Overview:  A security label is a concept attached to a resource or bundle that provides specific security metadata about the information it is fixed to. The Access Control decision engine uses the security label together with any provenance resources associated with the resource and other metadata (e.g. the resource type, resource contents, etc.) to

  • approve read, change, and other operations
  • determine what resources can be returned
  • determine what handling caveats must be conveyed with the data

Security Labels enable more data to flow as they enable policy fragments to accompany the resource data.

The intent of a security label is that the receiver 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.

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.

In the absence of this kind of preagreement, Security Labels may still be used by individual parties to assist with security role checking, but they might not all be recognized and enforced, which in turn limits what information can flow.

Local agreements and implementation profiles for the use security labels should describe how the security labels connect to the relevant consent and policy statements, and in particular:

  • Which Security Labels are able to be used
  • What to do if a resource has an unrecognized security label on it
  • Authoring obligations around security labels
  • Operational implications of security labels

This specification defines a basic set of labels for the most common use cases trading partners, and a wider array of security labels that allow much finer grained management of the information.

New FHIR Security Label project for Data Segmentation for Privacy FHIR DS4P IG PSS 

Project Scope: Provide FHIR guidance for applying security labels with coded tags for use in access control systems governing the collection, access, use, and disclosure of the target FHIR Resource(s) as required by applicable organizational, jurisdictional, or personal "sharing with protection" policies.
The IG will include guidance on:
*Marking healthcare and personal information disseminated by Federal Agencies per Executive Order 13556 Controlled Unclassified Information (CUI), and 32 C.F.R. § 2002 in the Federal Register and the General Services Administration (GSA) policy and framework for Controlled Unclassified Information (CUI), 2103.1 CIO Controlled Unclassified Information (CUI) Policy.
*How to select a security label based on the HL7 Privacy and Security Healthcare Classification System (HCS) label adjudication algorithms, the value in establishing consensus on a default security label for representing policies or consent directives within an exchange ecosystem, and the value of establishing default security labels for information exchanged within the Trust Framework of a policy domain.
*How an Access Control System, such as an OAuth Authorization Server can use the security labels to filter responses to person/population based queries and pushed disclosures that meets:
- Authorization Requirements specifying control over whether or not a client’s request for import or export of person/population Resources will be permitted
- Filtering Requirements specifying, at a more fine-grained level, what resources will appear in the results of a person/population export or accepted in an import operation
- Transformation Requirements specifying the requirements for applying functions on imported or exported person/population Resources, which modify and transform the content of any Resource per applicable privacy/security policies and/or data subject's(s') consent directive.
- Provenance Requirements specifying the recording and consumption of provenance information in a person/population Resource(s) export or import operation.
*Further development of HL7 security labeling vocabulary to enhance provenance and trust labeling to meet HL7 Provenance efforts including the PSAF Provenance DAM, Basic Provenance project, and updates to the CDA DPROV IG.
Addition of security label vocabulary to meet international affiliate needs, including GDPR security labeling vocabulary requirements determined by the Security WG GDPR WG.
Address the need to restructure FHIR Security label structure to enable demarcation of multiple applicable security labels into privacy tag sets representing each policy.
Develop a profile on Narrative to enable specification of the manner in which security label "privacy marks" are rendered, e.g., per CUI requirements.

V2 to FHIR Security Label Mapping

… page

Custodian Security Label Responsibilities

Custodians must determine the policies that apply to information when it is created or collected, accessed, used and disclosed.  They must ensure that their access control systems can recognize which policies apply when information is electronically created, collected, accessed, used, or disclosed by comparing the security labels associated by policy with the information and the clearance of the subject attempting to access or use the information within an enterprise system, or to which the information is being disclosed outside of the enterprise.

The access control system may filter the information to restrict the access, use, and disclosure to the information for which the subject has clearance.

If the subject is authorized to access and use the information within the enterprise, or is authorized to receive it outside the enterprise, then the custodian’s security labeling system must label the information with one or more security labels representing one or more applicable policies.

A Custodian’s security label includes

1...1 Security Classification tag, which is the applicable Confidentiality code tag

0..* Security Category tags of the following tag types:

  • Sensitivity tags, which indicates the potential risk of harm or stigmatization

Applicable security, privacy, or consent directive policy tags if necessary for interoperability.  Each security label may only have 1 policy tag.

  • Any compartment tags, which limit where information may be accesses and used, such as within a care team
  • Integrity tags, which indicate the confidence level based on factors such as manipulation of the information, e.g., by a syntactical transform or semantic mapping
  • Provenance tags, which indicate the trustworthiness of the information based on its lineage

0...* Security Control tags, which are any required security label “handling instructions” or security control tags to which a receiver must comply in accordance with applicable law, such as:

  • Purpose of Use Tags: Permissible purpose(s) of use such as treatment only, e.g., as when a patient exercises their HIPAA right to restrict disclosure to payers when the patient pays for services in full
  • Obligation Policy Tags: Obligations, such as limiting access to the minimum necessary, which is a requirement under HIPAA and persisting the security label applied by the sender
  • Refrain Policy Tags: Prohibitions as “no reuse for purposes other than disclosed” such as Title 38 Section 7332
  • Privacy Mark Tags: Privacy marks are information metadata, which must be rendered to end users, such as the 42 CFR Part 2 Prohibition on Redisclosure[3] and CUI marks on controlled unclassified information disclosed by Federal agencies or on behalf of a Federal agency
  • Trust Tags: For example, Trust Agreements that stipulate sender and receiver responsibilities, and Trust Accreditation requirements with which the sender, receiver, and downstream recipients must comply.

Receiver Security Label Responsibilities

  • Consume sender’s security label(s)
  • Persist sender’s security label(s)
  • Enforce sender’s security label(s) unless permitted by applicable law to do otherwise
  • Disclose with sender’s security label(s) with additional labels if any are required unless applicable law. If a sender adds a security label, it must not conflict with the labels assigned by the sender.  Policy may permit a receiver to override the sender's security label, in which case, the sender's security label or any conflicting tags would be removed.  For example, it the sender's security label purpose of use tags includes treatment and research but the receiver's policy does not permit the information to be used for research, then the receiver's security label purpose of use tag would only permit treatment.  On the other hand, if the receiver and the sender share a policy domain where the receiver's security label may be constrained but not augmented, then the receiver may not add e.g., payment/operations to the purpose of use tags.

[1] From <>

[2] Mixing It Up: HIPAA Hybrid Entities By Matt Fisher, Esq Dec 19, 2016

[3] §2.32   Prohibition on redisclosure.

Notice to accompany disclosure. Each disclosure made with the patient's written consent must be accompanied by the following written statement:

This information has been disclosed to you from records protected by Federal confidentiality rules (42 CFR part 2). The Federal rules prohibit you from making any further disclosure of this information unless further disclosure is expressly permitted by the written consent of the person to whom it pertains or as otherwise permitted by 42 CFR part 2. A general authorization for the release of medical or other information is NOT sufficient for this purpose. The Federal rules restrict any use of the information to criminally investigate or prosecute any alcohol or drug abuse patient. [52 FR 21809, June 9, 1987; 52 FR 41997, Nov. 2, 1987]

  • No labels