FHIR
Release
3
(STU)
CI-Build
Security
and
Privacy
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
Continuous
Integration
Build
of
available
versions,
see
FHIR
(will
be
incorrect/inconsistent
at
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
Work
Group
|
|
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.
(e.g.,
the
resource
type,
resource
contents,
etc.)
to
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 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.
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.
As
a
consequence
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
pre-agreement,
Security
Labels
may
might
still
be
used
by
individual
parties
to
assist
with
security
role
checking,
but
they
may
might
not
all
be
recognized
and
enforced,
which
in
turn
limits
what
information
is
allowed
to
can
flow.
Local
agreements
and
implementation
profiles
for
the
use
security
labels
should
would
describe
how
the
security
labels
connect
to
the
relevant
consent
and
policy
statements,
and
in
particular:
This
specification
defines
a
basic
set
of
labels
for
the
most
common
use
cases
trading
partners,
and
also
a
wider
array
of
security
labels
that
allow
much
finer
grained
management
of
the
information.
A security label is represented as a Coding , with the following important properties:
| system | The coding scheme from which label is taken (see code system URI , and below) |
| code |
a
code
from
the
coding
scheme
that
identifies
the
security
label
and
code
is
|
| display | The display form for the code (mostly for use when a system doesn't recognize the code) |
An
example
XML
Patient
Resource
with
a
"Restricted"
"Restricted"
tag
associated
with
it,
as
represented
in
an
HTTP
response:
<Patient xmlns="http://hl7.org/fhir"><Patient xmlns="http://hl7.org/fhir"> <meta> <security><system value="http://hl7.org/fhir/v3/Confidentiality"/> <code value="R"/> <display value="Restricted"/><system value="http://terminology.hl7.org/CodeSystem/v3-Confidentiality"/> <code value="R"/> <display value="Restricted"/> </security> </meta> ... [snip] ... </Patient>
A
JSON
search
result
example
fragment
that
includes
a
resource
resources
that
the
receiving
application
must
delete
all
copies
of
the
resource
after
using
it:
it
DELAU
:
{ "resourceType" : "Bundle", "type" : "searchset",{ "resourceType" : "Bundle", "meta" : { "security" : [{ "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code" : "DELAU" },{ "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "code" : "R" } ] }, "type" : "searchset", ... other headers etc....."entry" : [ ... other entries .... { "resource": { "id" : "1", "meta" : { "security" : [{ "system" : "http://hl7.org/fhir/v3/ActCode", "code" : "DELAU", "display" : "delete after use" }]"entry" : [ ... other entries .... { "resource": { "resourceType" : "Observation", "id" : "1", "meta" : { "security" : [{ "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code" : "ETHUD" },{ "system" : "http://terminology.hl7.org/CodeSystem/v3-Confidentiality", "code" : "R" } ] }, ... other content etc..... }... other content etc..... } }, ... other entries .... ] }}, ... other entries .... ] }
Note: the actual terms used in these examples are described below.
The
basic
framework
for
security
labels
is
described
by
the
HL7
Healthcare
Classification
System
(HCS;
ref
todo).
.
This
specification
identifies
how
security
labels
are
defined
and
provides
a
relatively
comprehensive
list
of
labels.
All
of
the
HCS
defined
labels
(see
below
for
the
lists)
can
be
used
as
security
labels
on
FHIR
resources
and
bundles
(e.g.
(e.g.,
requests
and
responses).
In addition, other security labels not defined here or in the HCS can be defined by jurisdictions, vendors and/or projects and used as appropriate. However, note that:
Note:
The
use
of
security
labels
and
the
expression
of
common
shared
security
policies
is
a
matter
of
ongoing
discussion
and
development
in
several
communities
at
this
time.
communities.
This
specification
defines
a
set
of
core
security
labels
for
all
FHIR
systems.
All
conformant
FHIR
Applications
SHOULD
use
these
labels
where
appropriate.
For
all
of
these
labels,
how
they
are
operationalised
operationalized
-
their
use
and
interpretation
-
is
subject
to
the
applicable
Mutual
Trust
Framework
agreement
as
described
above.
The Security Label vocabulary has three patterns of use: (1) Bundle: Security/Privacy considerations of a data set, (2) Context: Describe security/privacy context of a request for data, and (3) Meta Data: to indicate security/privacy meta about that data.
Bundle: A bundle is a container for a collection of data. Some uses of bundle are for communicating search results, sending data, or persisting data (See Bundle). The Bundle would carry meta about the data contained in the bundle. Specifically the confidentiality 'high water" mark, the authorized purposeOfUse, the required compartment clearance, Refrain, and Obligations that must be maintained. Where the "high water" mark is an indication of the most high confidentiality. Depending on Policy, the Bundle might include the cross-section of sensitivity or integrity, although this is usually not included. Provided in the Security Label Event Examples valueSet contains of some security-label codes that would be used on Bundle.meta.security.
Context: Requests (e.g., Read, Query, message triggers) - would describe the context of the request using purposeOfUse and compartment/clearance. The request might declare the highest confidentiality desired. It is unlikely to see in a request a declaration of sensitivity or integrity. It is also unlikely to see Obligations within a Request. (See Bundle for Response, where these are appropriate)
Meta Data: All resources have a meta.security element to hold descriptions (meta) about the data relative to privacy and security risk. Thus data might be tagged with confidentiality, sensitivity, and integrity. The data might be tagged with the indication of collection context using compartment or purposeOfUse. Data would not typically be tagged with Refrain, or Obligations. Provided in the Security Label Data Examples valueSet contains of some security-label codes that would be used on data.
More complex use of tagging in the data resource, bundle, context, or in Provenance, is possible.
| Name/ Tag | Description |
| Context of Use | |
|
Purpose
|
These
Purpose
(system
=
Notes
|
| Data Sensitivity | |
| Confidentiality codes |
These
confidentiality
class
(system
=
Notes:
|
| Control of Flow | |
|
Delete
After
Use:
.
DELAU
|
An
application
receiving
a
resource
with
this
label
must
delete
all
copies
after
the
immediate
use
for
which
the
data
was
exchanged,
is
complete.
Notes:
|
|
Do
Not
Re-use:
.
NOREUSE
|
An
application
receiving
a
resource
with
this
label
Notes:
|
|
Test
Data:
Purpose
Of
Use
.
HTEST
|
This
marks
that
a
resource
has
been
created
to
test
an
application,
and
is
not
real
production
data
Notes:
|
Break-the-glass, or break-glass, as it's called within some EHR systems, refers to a procedure that enables a clinician or end user who doesn't have access privileges to gain access to ePHI in emergency circumstances. The name comes from the old-fashioned manual fire alarms that required their users to break a pane of glass before activating the alarm. The idea was that accidental contact wouldn't be forceful enough to break the glass, preventing the alarm from being triggered by mistake. Break-the-glass protocols typically involve alerting and control mechanisms, such as a pop-up screen warning the data about to be accessed is sensitive and restricted. Break-the-glass is a privileged function that is only given to the most trusted clinicians.
There
is
a
special
security
label
to
support
the
commonly
encountered
"break-the-glass"
"break-the-glass"
protocol,
where
a
clinician
(usually
in
an
emergency
context)
requests
emergency
unauthorized
extra-authorized
access
to
the
patient's
record.
This
specification
does
not
make
any
policy
recommendations
or
rules
about
The
clinician
would
need
to
have
authorization
to
declare
break-the-glass,
and
the
operation,
merely
provides
support
for
it.
See
this
paper
for
discussion
act
of
breaking
the
issues
involved
glass
would
result
in
break-the-glass
operations.
audit
logs
that
would
alert
the
Safety
office
and
the
Privacy
office.
|
break
the
glass
| http://terminology.hl7.org/CodeSystem/v3-ActReason#BTG | To perform policy override operations on information for provision of immediately needed health care for an emergent condition affecting potential harm, death or patient safety by end users who are not provisioned for this purpose of use. Includes override of organizational provisioning policies and might include override of subject of care consent directive restricting access. ... |
When
While
the
operation
occurs,
principle
of
break-the-glass
is
understood,
implementing
it
well
has
some
challenges.
Often
break-the-glass
is
represented
as
a
security
label
on
the
request,
rather
than
on
a
resource,
only
implemented
within
an
EHR
system,
and
so
is
represented
differently.
The
break
the
glass
tag
needs
not
exposed
in
an
interoperability
standards
way.
This
section
indicates
some
methods
to
be
used
indicate
break-the-glass
as
part
a
purpose
of
an
agreed
policy
and
protocol.
FHIR
use
,
but
does
not
attempt
to
define
this
any
policy
or
protocol,
it
protocol
around
such
requests.
At
a
minimum,
implementations
must
be
agreed
on
ensure:
The
Glass
http://hl7.org/fhir/security-label#break-the-glass
following
are
some
potential
methods
of
declaring
break-the-glass.
The
requester
is
asking
for
emergency
first
one
uses
OAuth
2
to
request
an
access
for
patient
treatment.
Typically,
this
means
that
token
under
break-the-glass
conditions,
placing
the
patient
authorization
decision
within
the
security
layer.
The
second
one
simply
declares
break-the-glass
in
the
http
request,
relying
on
the
Resource
Server
to
confirm
that
break-the-glass
is
unconscious
legitimate,
authorized,
and
not
able
to
traced.
When
using
the
OAuth
2
client
credentials
grant,
which
has
no
user
interaction,
some
profiles
of
OAuth
2
support
passing
the
requested
purpose
of
use
in
the
access
token
request.
In
this
case
HL7
defines
the
break-the-glass
as
a
purpose
of
use
.
For
example
in
HL7
UDAP
Security
,
the
purpose
of
use
can
be
requested
using
hl7-b2b
OAuth
extension:
"extensions" : {
"hl7-b2b" : {
"subject_name": "Dr. John Smith",
"organization_name": "Central Hospital",
...
"purpose_of_use": [
"http://terminology.hl7.org/CodeSystem/v3-ActReason#BTG",
"http://terminology.hl7.org/CodeSystem/v3-ActReason#TREAT"
]
}}
When
using
the
OAuth
2
authorization
code
grant,
the
authorization
server
might
provide
relevant
information
User
Interface
interactions
to
request
break-the-glass
permission,
confirm
the
urgency,
and
capture
the
rationale.
In
either
case,
the
authorization
server
either
grants
or
consent.
denies
the
request,
logging
the
decision.
If
granted,
the
access
token
indicates
break-the-glass
authorization
with
expanded
permissions,
and
the
resource
server
enforces
this
elevated
permissions.
This
solution
utilizes
an
http
header,
specifically
a
draft
ietf
specification
for
a
web
category
.
The
URL
break-the-glass
is
represented
indicated
in
the
request
as
a
web
category
:
on
what
would
be
an
otherwise
normal
FHIR
http
interaction.
This
indicates
to
the
Resource
Server
that
the
request
is
under
break-the-glass
conditions.
The
Resource
Server
would
need
to
make
sure
that
the
user
is
allowed
to
declare
break-the-glass,
and
then
respond
with
different
results
based
on
this
break-the-glass:
HTTP/1.1 GET fhir/Patient/482735/condition Content-Type: text/xml Access-Control-Allow-Origin: * Last-Modified: Thu, 19 Nov 2013 07:07:32 +1100 ETag: 24Category: http://hl7.org/fhir/security-label#break-the-glass; scheme="http://hl7.org/fhir/tag/security"; label="Break The Glass"Category: http://terminology.hl7.org/CodeSystem/v3-ActReason#BTG; scheme="http://hl7.org/fhir/tag/security"; label="break the glass"
The
security
labels
described
above
are
a
subset
of
the
full
set
of
security
labels
defined
by
the
HL7
Healthcare
Privacy
and
Security
Classification
System
.
The
HCS
defines
5
categories
Note
the
use
of
"security
label"
is
used
broadly
in
FHIR
for
all
security
labels
tags.
There
is
a
more
formal
definition
in
the
security
labeling
community
of
"security
label"
that
may
refers
to
an
overall
assessment,
in
HL7
this
would
be
applied
represented
with
a
value
from
the
ConfidentialityCode
value
set.
For
more
detailed
on
how
to
implement
security
tagging
and
labeling,
HL7
has
published
Data
Segmentation
for
Privacy
Implementation
Guide
for
FHIR
Type
of
security
metadata
observation
made
about
the
classification
of
an
IT
resource
(data,
information
object,
service,
or
system
capability),
which
might
be
used
to
make
access
control
decisions.
Security
classification
is
defined
by
ISO/IEC
2382-8:1998(E/F)/
T-REC-X.812-1995
as:
"the
determination
of
which
specific
degree
of
protection
against
access
the
data
or
information
requires,
together
with
a
resource:
designation
of
that
degree
of
protection."
Security classification metadata is based on an analysis of applicable policies and the risk of financial, reputational, or other harm that could result from unauthorized disclosure.
| Tag Set | Car. | Description | Example Tags |
|---|---|---|---|
|
Confidentiality
|
1..1
|
Security
label
metadata
classifying
an
IT
resource
(clinical
fact,
data,
information
object,
service,
or
system
capability)
according
to
its
level
of
sensitivity,
which
is
based
on
an
analysis
of
applicable
privacy
policies
and
the
risk
of
financial,
reputational,
or
other
harm
to
an
individual
or
entity
that
could
result
if
made
available
or
disclosed
to
unauthorized
individuals,
entities,
or
processes.
|
Unrestricted,
Normal,
Very
|
Type
of
security
metadata
observation
made
about
the
category
of
an
IT
resource
(data,
information
object,
service,
or
system
capability),
which
might
be
used
to
make
access
control
decisions.
Security
category
metadata
is
defined
by
ISO/IEC
2382-8:1998(E/F)/
T-REC-X.812-1995
as:
"a
nonhierarchical
grouping
of
sensitive
information
used
to
control
access
to
data
more
finely
than
with
hierarchical
security
classification
alone."
| Tag Set | Car. | Description | Example Tags |
|---|---|---|---|
|
|
0..1
| Security label metadata that segments an IT resource by conveying a mandate, obligation, requirement, rule, or expectation relating to its privacy. |
|
|
Sensitivity
|
0..*
|
Security
label
metadata
that
|
STD
,
HIV
,
SUD
|
|
Compartment
|
0..*
|
Security
label
metadata
that
| Care Team, Research Project |
|
Integrity
|
0..*
|
Security
label
metadata
that
|
Anonymized,
|
|
|
0..*
|
Security label metadata that segments an IT resource by conveying the provenance of the IT resource's asserted or reported source. | Patient reported, Clinician asserted |
|
|
0..*
|
Security
label
metadata
| Trust Accreditation, Trust Agreement |
Each
of
these
security
labels
identifies
a
ValueSet
that
lists
a
set
of
possible
codes
for
the
security
label.
The
HL7
Healthcare
Classification
System
also
allows
for
Realm-specific
privacy
law
Type
of
security
metadata
observation
made
about
the
control
of
an
IT
resource
(data,
information
object,
service,
or
policy
category
codes
system
capability),
which
might
be
used
to
make
access
control
decisions.
Security
control
metadata
conveys
instructions
for
use
in
security
labels
in
particular
domains.
These
domains
are
included
with
this
specification:
secure
distribution,
transmission,
storage
or
use.
| Tag Set | Car. | Description | Example Tags |
|---|---|---|---|
|
|
0..*
|
Security label metadata that segments an IT resource by conveying the reason for performing one or more operations on information, which might be permitted by source system's security policy in accordance with one or more privacy policies and consent directives. | Treatment, Payment, Operation, Research |
|
|
0..*
|
Security label metadata that segments an IT resource by conveying the reason for performing one or more operations on information of purpose of use at a general level. | Coverage, Patient Requested, Emergency Treatment |
|
**
|
0..*
|
Security label metadata that segments an IT resource by conveying the mandated workflow action that an information custodian, receiver, or user must perform. | Encrypt, mask, comply with policy |
|
**
|
0..*
|
Security
label
metadata
that
| Do not disclose without consent, no reuse |
(**)
Privacy-revealing
Obligation
or
Refrain
tags
such
as
the
assignment
Obligation
Policy
MASK
(mask)
or
the
Refrain
Policy
NODSCLCD
(no
disclosure
without
consent
directive),
would
not
be
included
in
the
high-watermark
labels
of
a
Confidentiality
Classification
complies
in
Bundle
,
DocumentReference
,
or
Message
Resources
.
Other
Value-sets
are
defined
by
the
US.
FHIR
DS4P
IG
.
FHIR
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Tue,
Dec
16,
2025
21:58+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU2
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change