Security
and
Privacy
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v5.0.0:
R5
-
STU
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
Responsible
Owner:
Security
Work
Group
|
Standards
Status
:
|
Fast Healthcare Interoperability Resources (FHIR) is not a security protocol, nor does it define any security related functionality. However, FHIR does define exchange protocols and content models that need to be used with various security protocols defined elsewhere. This section gathers all information about security in one section. A summary:
Implementation
Guide
where
appropriate.
Time
critical
concerns
regarding
security
flaws
in
the
FHIR
specification
should
SHOULD
be
addressed
to
the
FHIR
email
list
for
prompt
consideration.
A production FHIR system will need some kind of security sub-system that administers users, user authentication, and user authorization. Where this subsystem fits into the deployment architecture is a matter for system design:
|
|
In
this
diagram,
the
red
lines
represent
FHIR
interfaces.
From
the
perspective
of
the
FHIR
API,
the
client
(consumer
of
FHIR
services)
may
MAY
either
interact
with
a
security
system
that
manifests
as
a
FHIR
server,
and
which
depends
on
a
subsequent
FHIR
interface
to
provide
the
actual
storage,
or
either
the
client
or
server
interacts
with
the
security
system
independently.
In
each
of
these
3
scenarios,
the
different
components
may
MAY
be
assembled
into
applications
or
network
components
differently,
but
the
same
logical
layout
applies.
The
FHIR
specification
assumes
that
a
security
system
exists,
and
that
it
may
MAY
be
deployed
in
front
of
or
behind
the
FHIR
API.
The security system includes the following subsystems:
Because
there
are
a
plethora
of
standards
relating
to
the
administration
and
functionality
of
the
security
system,
FHIR
does
not
provide
user,
profile,
or
other
such
administration
resources.
Instead,
the
FHIR
resources
are
the
targets
of
the
policies
expressed
in
these
other
approaches.
What
FHIR
does
specify
is
a
way
to
apply
security
labels
to
resources
so
that
a
security
system
may
MAY
use
these
(along
with
the
contents
of
the
resources
if
appropriate)
to
determine
whether
a
user
is
authorized
to
perform
a
particular
FHIR
operation
or
not.
The appropriate protections for Privacy and Security are specific to the risks to Privacy and the risks to Security of that data being protected. This concept of appropriate protections is a very specific thing to the actual data. Any declaration of 'required' or 'optional' requirements that could be mentioned here are only recommendations for that kind of Resource in general for the most dominant use of that Resource. Where one uses the Resource in a way that is different than this most dominant use, one will have different risks and thus need different protections. Each Resource is indicated with the dominant "Security Category", and all of the Resources Security Category is shown on the Resource Types page with the Security Category tab.
Most Resources will need some form of Access Control to Create, Update, or Delete. The following general guidance is given only as general guidance for READ and QUERY access:
These resources tend to not contain any individual data, or business sensitive data. Most often these Resources will be available for anonymous access, meaning there is no access control based on the user or system requesting. However, these Resources do tend to contain important information that must be authenticated back to the source publishing them, and protected from integrity failures in communication. For this reason, server authenticated https (TLS) is recommended to provide authentication of the server and integrity protection in transit. This is normal web-server use of https .
These
Resources
tend
to
not
contain
any
individual
data,
but
do
have
data
that
describe
business
or
service
sensitive
data.
The
use
of
the
term
Business
is
not
intended
to
only
mean
an
incorporated
business,
but
rather
the
broader
concept
of
an
organization,
location,
or
other
group
that
is
not
identifiable
as
individuals.
Often
these
resources
will
require
some
sort
of
client
authentication
to
assure
that
only
authorized
access
is
given.
The
client
access
control
may
MAY
be
to
individuals,
or
may
MAY
be
to
system
identity.
For
this
purpose,
possible
client
authentication
methods
such
as:
mutual-authenticated-TLS,
APIKey,
App
signed
JWT,
or
App
OAuth
client-id
JWT
For
example:
an
App
that
uses
a
Business
protected
Provider
Directory
to
determine
other
business
endpoint
details.
These Resources do NOT contain Patient data, but do contain individual information about other participants. These other individuals are Practitioners and PractitionerRole. These identities are needed to enable the practice of healthcare. These identities are identities under general privacy regulations, and thus must consider Privacy risk. Often access to these other identities are covered by business relationships. For this purpose, access to these Resources will tend to be Role specific using methods such as RBAC or ABAC.
These Resources make up the bulk of FHIR and therefore are the most commonly understood. These Resources contain highly sensitive health information, or are closely linked to highly sensitive health information. These Resources will often use the security labels to differentiate various confidentiality levels within this broad group of Patient Sensitive data. Access to these Resources often requires a declared Purpose Of Use. Access to these Resources is often controlled by a Privacy Consent . See the section below on Authorization and Access Control .
Some Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive. These Resources do not fall into any of the above classifications, as their sensitivity is highly variable. These Resources will need special handling. These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions.
For
the
RESTful
API
,
normal
HTTP
security
rules
apply.
Please
follow
the
HTTP
specification
Security
Considerations
section
9
.
The
Service
Base
URL
will
specify
whether
TLS
is
required.
Client
authentication
may
MAY
be
required
by
the
server,
possibly
including
the
requirement
for
client
certificates.
When
returning
responses
to
non-authorized
clients,
ensure
that
Hypertext
Transfer
Protocol
(HTTP)
headers
of
a
web
server
and
API
error
messages
or
faults
do
not
disclose
detailed
information
about
the
underlying
web
server
that
could
be
the
source
of
potential
exploitation.
Please
follow
IETF
Best
Current
Practice
(
BCP
195
)
-
"Recommendations
for
Secure
Use
of
Transport
Layer
Security
(TLS)
and
Datagram
Layer
Security
(DTLS)"
.
Consider using additional methods of security for an API to help authenticate where Domain Name System (DNS) responses are coming from and ensure that they are valid. For example, the use of Domain Name System Security Extensions (DNSSEC), a suite of extensions that add security to the DNS protocol, can ensure that domains associated with API endpoints that transmit health information or information required for API access are secure. DNSSEC provides origin authority, data integrity, and authenticated denial of existence. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks, particularly DNS spoofing attacks.
The
TLS
communications
are
established
prior
to
any
HTTP
command/response,
so
the
whole
FHIR
interaction
is
protected
by
the
TLS
communications.
The
security
of
the
endpoints
of
the
TLS
communications
must
be
risk-managed,
so
as
to
prevent
inappropriate
risks
(e.g.
(e.g.,
audit
logging
of
the
GET
parameters
into
an
unprotected
audit
log).
When
it
is
desirable
to
support
browser-based
javascript
client
applications,
servers
SHOULD
consider
enabling
cross-origin
resource
sharing
(CORS)
for
the
REST
operations
.
Consider
advice
from
sources
including
Enable-CORS
and
Moesif
blog
on
Guide
to
CORS
Pitfalls
.
Experience
shows
that
this
is
an
area
where
ongoing
issues
may
MAY
be
expected
as
security
holes
are
found
and
closed
on
an
ongoing
basis.
Except
when
no
patient
data
are
involved
such
as
Provider
Directories
and
test
sandbox
systems,
FHIR
servers
need
to
authenticate
the
client
system
and
trust
it,
or
authenticate
the
individual
user
by
a
variety
of
techniques.
For
web-centric
environments
it
is
recommended
to
use
OpenID
Connect
(or
other
suitable
authentication
protocol)
to
confirm
the
identity
of
the
authenticated
end
user,
where
it
is
necessary
that
end-users
be
identified
to
the
application.
For
scalable
security,
either
UDAP
Consumer-Facing
or
UDAP
Business-to-Business
should
SHOULD
be
implemented,
as
appropriate.
The
Registration
and
Discovery
sections
of
UDAP
Security
should
SHOULD
also
be
implemented
to
securely
scale
the
addition
of
new
client
and
server
endpoints.
Tiered
OAuth
for
User
Authentication
should
SHOULD
be
implemented
to
securely
scale
trust
with
new
OIDC
credential
issuers.
All
systems
shall
SHALL
protect
authenticator
mechanisms,
and
select
the
type
of
credential/strength
of
authenticator
based
on
use-case
and
risk
management.
Correctly identifying people, devices, locations and organizations is one of the foundations that any security system is built on. Most applications of security protocols, whether authentication, access control, digital signatures, etc. rely on the correct mapping between the relevant resources and the underlying systems. Note that this isn't necessary. There is nothing in FHIR that requires or relies on any security being in place, or any particular security implementation. However, real-world usage will generally require this.
A
holder
of
data
should
not
SHOULD
NOT
allow
the
data
to
be
communicated
unless
there
are
enough
assurances
that
the
other
party
is
authorized
to
receive
it.
This
is
true
for
a
client
creating
a
resource
through
a
PUT/POST,
as
much
as
it
is
true
for
a
server
returning
resources
on
a
GET.
The
presumption
is
that
without
proper
authorization,
to
the
satisfaction
of
the
data
holder,
the
data
does
not
get
communicated.
Two of the classic Access Control models are: Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC).
In Role-Based Access Control (RBAC), permissions are operations on an object that a user wishes to access. Permissions are grouped into roles. A role characterizes the functions a user can perform. Roles are assigned to users. If the user's role has the appropriate permissions to access an object, then that user is granted access to the object. FHIR readily enables RBAC, as FHIR Resources are object types and the CRUDE (Create, Read, Update, Delete, Execute) events (the FHIR equivalent to permissions in the RBAC scheme) are operations on those objects.
In
Attribute-Based
Access
Control
(ABAC),
a
user
requests
to
perform
operations
on
objects.
That
user's
access
request
is
granted
or
denied
based
on
a
set
of
access
control
policies
that
are
specified
in
terms
of
attributes
and
conditions.
FHIR
readily
enables
ABAC,
as
instances
of
a
Resource
in
FHIR
(again,
Resources
are
object
types)
can
have
attributes
associated
with
them.
These
attributes
include
security
tags,
environment
conditions,
and
a
host
of
user
and
object
characteristics,
which
are
the
same
attributes
as
those
used
in
ABAC.
Attributes
help
define
the
access
control
policies
that
determine
the
operations
a
user
may
MAY
perform
on
a
Resource
(in
FHIR)
or
object
(in
ABAC).
For
example,
a
tag
(or
attribute)
may
MAY
specify
that
the
identified
Resource
(object)
is
not
to
be
further
disclosed
without
explicit
consent
from
the
patient.
The rules behind the access control decision are often very complex, and potentially depend on information sourced from:
For
one
source
of
further
information,
see
the
IHE
Access
Control
white
paper
Access
control
constraints
may
MAY
result
in
data
returned
in
a
read
or
search
being
redacted
or
otherwise
restricted.
See
Variations
between
Submitted
data
and
Retrieved
data
.
It
is
recommended
that
OAuth
be
used
to
authenticate
and/or
authorize
the
client
and
user.
The
HL7
SMART
App
Launch
Implementation
Guide
is
a
recommended
method
for
using
OAuth
for
authorizing
interactions
with
a
protected
FHIR
Server.
The
method
today
for
managing
and
enforcing
patient
consents
in
Patient-Directed
and
Patient-Mediated
workflows
relies
on
an
OAuth
2.0
server
which
uses
the
patient
consents
as
the
applicable
authorization
policies
at
the
time
of
issuing
a
token.
In
this
model,
the
authorization
server
(OAuth
2.0
or
its
User-Managed
Access
profile
)
examines
the
patient
consent
to
determine
whether
or
not
to
issue
a
token
to
a
requesting
client
and
what
scopes
to
grant.
The
HEART
Working
Group
has
developed
a
set
of
privacy
and
security
specifications
that
enable
an
individual
to
control
the
authorization
of
access
to
RESTful
health-related
data
sharing
APIs,
and
to
facilitate
the
development
of
interoperable
implementations
of
these
specifications
by
others.
The
main
motivation
behind
this
model
is
to
have
a
separate
consent
management
system
in
charge
of
collecting,
storing,
and
maintaining
patient
consents,
as
well
as
responding
to
authorization
requests
based
on
these
consents.
This
would
allow
organizations
to
outsource
their
consent
management
functions
to
a
consent
management
service.
Further
details
about
this
model
are
discussed
in
this
report
.
IHE
IUA
Profile
constrains
OAuth
token
attributes
to
support
Healthcare
Information
Exchange
environments
such
as
IHE
Document
Sharing
.
IHE
includes
guidance
on
access
control
within
this
whitepaper
and
has
implementation
guides.
An
extension
to
a
single
level
model,
Cascaded
Authorization,
enables
an
OAuth/UMA
authorization
server
to
require
and
rely
on
the
approval
of
another
OAuth/UMA
server
before
issuing
a
token
and
granting
scopes.
Using
this
model,
the
enterprise
OAuth/UMA
server
at
a
provider
organization
can
rely
on
the
decisions
by
a
Consent
OAuth/UMA
Server
by
requiring
and
accepting
access
tokens
issued
by
that
server
as
part
of
the
client
authorization
process.
This
architecture
preserves
the
independence
of
a
consent
management
system,
which
can
potentially
be
outsourced
to
third-parties,
while
ensuring
that
all
authorization
interfaces
and
interactions
follow
the
OAuth/UMA
protocols.
A
summary
of
the
concepts
and
flows
for
Cascaded
Authorization
are
discussed
in
this
report
.
Further
extensions
to
this
model
to
leverage
UMA’s
capabilities
to
simplify
some
of
the
flows
are
discussed
in
this
report
.
A
reference
implementation
of
Cascaded
Authorization
and
more
technical
details
can
be
found
here
.
For
business
to
business
workflows,
the
UDAP
B2B
Authorization
Extension
Object
can
be
used
to
assert
consent
information
in
communities
supporting
cross-organization
FHIR
based
exchanges.
A
web-server,
especially
hosting
FHIR,
must
choose
the
response
carefully
when
an
Access
Denied
condition
exists.
Returning
too
much
information
may
MAY
expose
details
that
should
not
SHOULD
NOT
be
communicated.
The
Access
Denied
condition
might
be
because
of
missing
but
required
Authentication,
the
user
is
not
authorized
to
access
the
endpoint,
the
user
is
not
authorized
to
access
specific
data,
or
other
policy
reasons.
To balance usability of the returned result vs appropriate protection, the actual result method used needs to be controlled by policy and context. Typical methods of handling Access Denied used are:
Return a Success with Bundle containing zero results - This result is indistinguishable from the case where no data is known. When consistently returned on Access Denied, this will not expose which patients exist, or what data might be blinded. This method is also consistent with cases where some results are authorized while other results are blinded. This can only be used when returning a Bundle is a valid result.
Return a 404 "Not Found" - This also protects from data leakage as it is indistinguishable from a query against a resource that doesn't exist. It does however leak that the user authentication is validated.
Return
a
403
"Forbidden"
-
This
communicates
that
the
reason
for
the
failure
is
an
Authorization
failure.
It
should
SHOULD
only
be
used
when
the
client
and/or
user
is
well
enough
known
to
be
given
this
information.
Thus
this
method
is
most
used
when
the
user
can
know
that
they
are
forbidden
access.
It
doesn't
explain
how
the
user
might
change
things
to
become
authorized.
Return a 401 "Unauthorized" - This communicates that user authentication was attempted and failed to be authenticated.
Note that if a server allows PUT to a new location , it is not feasible to return 404 Not Found. This means that clients can use this to test whether content exists that they are not able to access, which is a minor, but potentially significant, leak of information.
FHIR
provides
an
AuditEvent
resource
suitable
for
use
by
FHIR
clients
and
servers
to
record
when
a
security
or
privacy
relevant
event
has
occurred.
This
form
of
audit
logging
records
as
much
detail
as
reasonable
at
the
time
the
event
happened.
IHE
Basic
Audit
Log
Patterns
Implementation
Guide
has
profiling
of
the
AuditEvent
resource
for
security
and
privacy
purposes
including
patterns
for
RESTful
events,
RESTful
patient
affecting
events,
Authorization
Decisions,
and
Accounting
of
Disclousures.
When
used
to
record
security
and
privacy
relevant
events,
the
AuditEvent
can
then
be
used
by
properly
authorized
applications
to
support
audit
reporting,
alerting,
filtering,
and
forwarding.
This
model
has
been
developed
and
used
in
healthcare
for
a
decade
as
IHE-ATNA
profile
.
ATNA
log
events
can
be
automatically
converted
to
AuditEvent
resources,
and
from
there,
client
applications
are
able
to
search
the
audit
events,
or
subscribe
to
them.
For
HTTP
logs,
implementers
need
to
consider
the
implications
of
distributing
access
to
the
logs.
HTTP
logs,
including
those
that
only
contain
the
URL
itself,
should
SHOULD
be
regarded
as
being
as
sensitive
as
the
resources
themselves.
Even
if
direct
PHI
(Personal
health
information)
is
kept
out
of
the
logs
by
careful
avoidance
of
search
parameters
(e.g.
(e.g.,
by
using
POST),
the
logs
will
still
contain
a
rich
set
of
information
about
the
clinical
records.
Several
FHIR
resources
include
attachments.
Attachments
can
either
be
references
to
content
found
elsewhere
or
included
inline
encoded
in
base64.
Attachments
represent
security
risks
in
a
way
that
FHIR
resources
do
not,
since
some
attachments
contain
executable
code.
Implementers
should
SHOULD
always
use
caution
when
handling
resources.
See Security Labels .
FHIR
resources
include
an
XHTML
narrative,
so
that
applications
can
display
the
contents
of
the
resource
to
users
without
having
to
fully
and
correctly
process
the
data
in
the
resource.
However,
displaying
HTML
is
associated
with
several
known
security
issues
that
have
been
observed
in
production
systems
in
other
contexts
(e.g.
(e.g.,
with
CDA
).
For
this
reason,
the
FHIR
narrative
can't
contain
active
content
.
However,
care
is
still
needed
when
displaying
the
narrative:
Also
note
that
the
inclusion
of
an
external
reference
to
an
image
can
allow
the
server
that
hosts
the
image
to
track
when
the
resource
is
displayed.
This
may
MAY
be
a
feature
or
a
problem
depending
on
the
context.
In
addition
to
narrative,
Documents
may
MAY
also
contain
stylesheets.
Unlike
with
CDA,
the
stylesheets
are
simple
CSS
stylesheets,
not
executable
XSLT,
so
the
same
security
risks
do
not
apply.
However,
CSS
stylesheets
may
MAY
still
reference
external
content
(e.g.
(e.g.,
background
images),
and
applications
displaying
documents
should
SHOULD
ensure
that
CSS
links
are
not
automatically
followed
without
checking
their
safety
first,
and
that
session/identifying
information
does
not
leak
with
any
use
of
external
links.
FHIR
®©
HL7.org
2011+.
FHIR
R5
hl7.fhir.core#5.0.0
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Mon,
Nov
17,
2025
19:30+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R4B
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change
