FHIR security labels are tags in meta.security that describe how data should be handled, such as its confidentiality level or a no re-use caveat. They do not block anything by themselves. The spec says labels only connect resources to a wider policy framework, and meaning depends on consent and policy.
What a label is
Each label is a Coding with a system, code and display. Every resource has meta.security, so any resource can carry labels for confidentiality, sensitivity, integrity and purpose of use. A Bundle carries a confidentiality high water mark, meaning the bundle is as confidential as its most confidential resource.
The groups
The R5 security labels page describes:
- Core labels: purpose of use, confidentiality, and control of flow codes such as DELAU (delete after use), NOREUSE (no re-use or re-distribution) and HTEST (test data).
- Break the glass: an emergency access label carried on the request, not the resource, as an HTTP Category header.
- HCS tag sets from the HL7 Healthcare Privacy and Security Classification System, grouped into classification, category and control.
What labels cannot do
The page is direct about limits.
- Labels work best where trading partners share a mutual trust framework. Without that, parties may not recognize or enforce the labels.
- Recipients are expected to honor handling caveats and carry labels forward, but that is an expectation, not a mechanism.
- Local agreements should say which labels are allowed, how to treat unknown labels, and what the operational implications are.
- Custom labels outside the HCS raise portability costs. Use an HCS label where one exists.
- For break the glass, the spec defines how to represent it but not the policy or protocol. You must control when it is used, check authorization and record it in an AuditEvent.
There is also a privacy trap. Obligation or refrain codes that themselves reveal sensitive facts, such as MASK or NODSCLCD, must not appear in the high water mark labels of a Bundle, DocumentReference or Message, since the label would disclose what it protects.
A worked example
Suppose a clinic stores a lab result that is sensitive. You tag the Observation with a restricted confidentiality code in meta.security. A research app asks for the same Observation. Your policy layer reads the label, sees the research purpose of use on the request, finds no matching consent, and denies. A second app that is a treating clinician under the same label gets access and the access is audited.
Nothing in the label did the denying. The label supplied the facts, and your policy supplied the decision.
How to use labels well
- Agree a small label vocabulary with your partners and write down the handling rules.
- Apply labels at creation, and re-check them when data is copied into a Bundle.
- Make the access control layer read labels. A label nobody reads is decoration.
- Decide what happens to unrecognized labels. Failing closed is safer.
- Audit break the glass events.
The FHIR security page points out that labels can support attribute based access decisions, such as limiting disclosure without patient consent. See the Consent resource.
Quick check
Does a confidentiality label stop a user reading the resource?
No. It tells systems how sensitive the data is. A policy enforcement point must read the label and decide.
Sources
Last reviewed: 19 October 2026.
