Security
and
Privacy
This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions 
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
|
|
|
|
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
level
of
the
resource
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
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
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
still
be
used
by
individual
parties
to
assist
with
security
role
checking,
but
they
may
not
all
be
recognized
and
enforced,
which
in
turn
limits
what
information
is
allowed
to
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
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
also
a
wider
array
of
security
labels
that
allow
much
finer
grained
management
of
the
information.
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
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 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 still be used by individual parties to assist with security role checking, but they may not all be recognized and enforced, which in turn limits what information is allowed to 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:
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
, 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 an value from the code system |
|
display
| The display form for the code (mostly for use when a system doesn't recognize the code) |
An XML patient resource with a "celebrity" tag associated with it, as represented in an HTTP response:
<Patient xmlns="http://hl7.org/fhir">
<meta>
<security>
<system value="http://hl7.org/fhir/v3/ActCode"/>
<code value="CEL"/>
<display value="Celebrity"/>
</security>
</meta>
... [snip] ...
</Patient>
A
JSON
search
result
that
includes
a
resource
that
the
receiving
application
must
delete
all
copies
of
the
resource
after
using
it:
A JSON search result that includes a resource that the receiving application must delete all copies of the resource after using it:
{
"resourceType" : "Bundle",
"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"
}]
}
... other content etc.....
}
},
... 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.
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:
Defining
additional
security
labels
will
increase
costs
associated
with
information
and
system
portability
Implementation
guides
and
applications
SHOULD
always
use
the
applicable
label
defined
by
the
HCS
if
one
exists
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.
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. 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.
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 - their use and interpretation - is subject to the applicable Mutual Trust Framework agreement as described above. These codes all come from one of two code systems: http://hl7.org/fhir/v3/Confidentiality, and http://hl7.org/fhir/v3/ActCode,
|
| Description |
|
| |
| Confidentiality codes | These
confidentiality class
(system = http://hl7.org/fhir/v3/Confidentiality) can be applied to any resource or bundle. They are generally assigned by the author of the resource, but can be modified subsequently as a matter of operational management. The Confidentiality classifications describe the sensitivity of the information in a resource with regard to whether it should made available or disclosed to unauthorized individuals, entities, or processes. Notes:
|
|
Celebrity / VIP: ActCode.
CEL
| Use on any resource to indicate that the subject/patient is a celebrity or well known to the staff in the institution. Notes: Patient |
|
Staff: ActCode.
EMP
| Use on a
Patient
Notes: Patient |
|
Keep information from patient: ActCode.
TBOO
| Used on
any
Notes: Flag |
|
Contact/Employment Details Confidential: ActCode.
DEMO
| Used on a
Patient
|
|
Diagnosis-related confidentiality: ActCode.
DIA
| Used on
any
Notes:
|
|
Author Consent needed: ActCode.
ORCON
| The author's consent is needed for disclosure. Typically, this is used by a treating practitioner to label portions of their own record confidential. Any such resource is only shared with the author or with other parties as arranged. |
|
| |
|
Delete After Use: ActCode.
DELAU
| An application receiving a resource with this label must delete all copies after the immediate use for which the resource/feed was exchanged is complete. Notes:
|
|
Do Not Re-use: ActCode.
NOREUSE
| An application receiving a resource with this label may only use it for the immediate purpose of use. In particular, the application is not authorized to re-distribute (i.e. exchange this resource with any other application). Notes:
|
There is a special security label to support the commonly encountered "break-the-glass" protocol, where a clinician (usually in an emergency context) requests emergency unauthorized access to the patient's record. This specification does not make any policy recommendations or rules about the operation, merely provides support for it. See
this paper
for
discussion
of
the
issues
involved
in
break-the-glass
operations.
When
the
operation
occurs,
it
is
represented
as
a
security
label
on
the
request,
rather
than
on
a
resource,
and
so
is
represented
differently.
The
break
the
glass
tag
needs
to
be
used
as
part
of
an
agreed
policy
and
protocol.
FHIR
does
not
attempt
to
define
this
policy
or
protocol,
it
must
be
agreed
on
an
implementation
by
implementation
basis.
For
example
as
a
URL:
Break
The
Glass
for discussion of the issues involved in break-the-glass operations.
When the operation occurs, it is represented as a security label on the request, rather than on a resource, and so is represented differently. The break the glass tag needs to be used as part of an agreed policy and protocol. FHIR does not attempt to define this policy or protocol, it must be agreed on an implementation by implementation basis. For example as a URL:
| Break The Glass |
http://hl7.org/fhir/security-label#break-the-glass
| The requester is asking for emergency access for patient treatment. Typically, this means that the patient is unconscious and not able to provide relevant information or consent. |
The URL is represented in the request as a
web category
:
:
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: 24 Category: http://hl7.org/fhir/security-label#break-the-glass; 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 (HCS; ref todo). The HCS defines 5 categories of security labels that may be applied to a resource:
|
| Card. | Values |
Description
|
| Confidentiality Classification | 0..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. Example Uses: Unrestricted, Normal, Very restricted |
| Sensitivity Category | 0..* |
InformationSensitivityPolicy
|
Security label metadata that "segments" an IT resource by categorizing the value, importance, and vulnerability of an IT resource perceived as undesirable to share. Example Uses: STDs, Psychiatric care, Celebrity status |
| Compartment Category | 0..* |
Compartment
|
Security label metadata that "segments" an IT resource by indicating that access and use is restricted to members of a defined community or project Note: this is a different use of "Compartment" to the Patient Compartment use. Example Uses: Research, HR records |
| Integrity Category | 0..* |
SecurityIntegrityObservationValue
|
Security label metadata that "segments" an IT resource by conveying the completeness, veracity, reliability, trustworthiness, and provenance of an IT resource Example Uses: Anonymized, signed, patient reported |
| Handling Caveat | 0..* |
SecurityControlObservationValue
|
Security label metadata conveying dissemination controls and information handling instructions such as obligations and retention policies to which an IT resource custodian or receiver must comply.
This type of handling caveat SHALL be assigned to a clinical fact if required by jurisdictional or organizational policy, which may be triggered by a patient consent directive Example Uses: do not disclose, various restrictions on use, and policy marks |
Each of these security labels identifies a
ValueSet
that
lists
a
set
of
possible
codes
for
the
security
label.
that lists a set of possible codes for the security label.
The HL7 Healthcare Classification System also allows for Realm-specific privacy law or policy category codes for use in security labels in particular domains. These domains are included with this specification:
|
| Card. | Values |
Description
|
| US Privacy Law | 0..* |
ActUSPrivacyLaw
| Security label metadata that "segments" an IT resource by indicating the legal provisions to which the assignment of a Confidentiality Classification complies in the US. |
© HL7.org 2011+. FHIR STU3 Ballot (v1.6.0-9663) generated on Thu, Aug 11, 2016 17:07+1000.
QA Page
Links:
Search
|
|
Version History
|
Table of Contents
|
Compare to DSTU2
|
|
Propose
a
change
|
Propose a change