This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
(v5.0.0:
R5
-
Mixed
Normative
and
STU
)
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
The
current
version
which
supercedes
this
version
is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
The
Conformance
Module
represents
metadata
about
the
datatypes,
resources
and
API
features
of
the
FHIR
specification
and
can
be
used
to
create
derived
specifications.
The
core
FHIR
specification
describes
a
set
of
resources,
frameworks
and
APIs
that
are
used
in
many
different
contexts
in
healthcare.
However,
there
is
wide
variability
between
jurisdictions
and
across
the
healthcare
ecosystem
around
practices,
requirements,
regulations,
education
and
what
actions
are
feasible
and/or
beneficial.
For
this
reason,
the
FHIR
specification
is
a
"platform
specification"
-
it
creates
a
common
platform
or
foundation
on
which
a
variety
of
different
solutions
are
implemented.
As
a
consequence,
this
specification
usually
requires
further
adaptation
to
particular
contexts
of
use.
Typically,
these
adaptations
specify:
Rules
about
which
resource
elements
are
or
are
not
used,
and
what
additional
elements
are
added
that
are
not
part
of
the
base
specification
Rules
about
which
of
FHIR's
RESTful
API,
messaging
and
document
features
are
used,
and
how
Rules
about
which
terminologies
are
used
in
particular
elements
Descriptions
of
how
the
Resource
elements
and
API
features
map
to
local
requirements
and/or
implementations
Note
that
because
of
the
nature
of
the
healthcare
ecosystem,
there
may
be
multiple
overlapping
sets
of
adaptations
-
by
healthcare
domain,
by
country,
by
institution,
and/or
by
vendor/implementation.
FHIR
provides
a
set
of
resources
that
can
be
used
to
represent
and
share
the
adaptations
listed
above
in
a
computable
fashion.
These
resources
are
collectively
called
the
conformance
resources
.
Although
these
conformance
resources
can
be
used
in
isolation
they
are
typically
used
in
the
context
of
an
Implementation
Guide
or
a
Capability
Statement
:
Implementation
Guides
are
documents
published
by
a
domain,
institution
institution,
vendor,
consortium,
or
vendor
other
organization
that
describe
how
FHIR
is
adapted
to
support
a
certain
use
case
(or
set
of
use
cases).
An
implementation
guide
combines
a
set
of
conformance
resources
and
supporting
narrative
into
a
document
for
use
by
implementers.
A
capability
statements
use
the
conformance
resources
to
document
how
a
client
or
server
has
implemented
FHIR,
i.e.
which
aspects
of
the
specification
and
API
are
implemented
and
how.
5.0.2
Contents
The
content
of
an
Implementation
Guide
is
described
using
the
ImplementationGuide
resource,
while
the
capability
statement
is
represented
by
the
CapabilityStatement
resource.
These
two
resources
make
use
of
the
complete
set
of
conformance
resources
to
fully
capture
the
set
of
adaptations
they
represent.
Note
that
the
CapabilityStatement
resource
is
one
of
the
conformance
resources
,
the
first
just
describing
the
capabilities
of
a
system,
while
the
latter
is
the
set
of
all
conformance
resources,
including:
The
StructureDefinition
defines
how
a
particular
structure
(Resource,
Extension
or
Data
Type)
Datatype)
is
used
to:
Describe
how
existing
elements
in
resources
and/or
data
types
datatypes
are
used
and
identify
existing
elements
that
are
not
used.
Exact
rules
on
how
to
do
this
can
be
found
in
the
section
on
conformance
rules
Define
extensions
that
can
be
used
in
resources
or
data
types.
datatypes.
The
MessageDefinition
describes
messages
that
can
be
sent
and
received,
including
the
driving
event,
contents
to
be
exchanged
and
responsibilities
on
receipt.
The
SearchParameter
describes
additional
search
capabilities
in
addition
to
those
in
the
base
specification
The
CompartmentDefinition
describes
a
logical
grouping
for
resources,
used
in
access
control
or
search
Conformance
resources
may
be
used
independently,
not
just
within
the
context
of
an
ImplementationGuide
resource
or
capability
statement.
See
the
section
Common
use
cases
for
examples
of
such
uses.
The
conformance
resources
and
their
relationships
are
shown
below:
Resources
shown
with
a
dotted
box
are
described
in
other
sections
of
the
specification:
ValueSet
,
ConceptMap
and
StructureMap
are
from
the
section
on
terminology
,
TestScript
is
part
of
the
section
on
Implementer
Support
.
5.0.3
Security
and
Privacy
The
conformance
resources
do
not
represent
patient-related
data,
and
as
such
are
less
susceptible
to
data
breaching.
Some
caution
is
required
however:
StructureDefinitions
may
contain
invariants
formulated
as
structured
expressions
that
are
evaluated
by
external
engines
(i.e.
xpath),
FHIRPath),
which
-if
improperly
sandboxed-
could
provide
low-level
access
to
the
system
A
server
may
be
implemented
in
such
a
way
that
it
will
automatically
support
additional
search
parameters
or
compartments
definitions
uploaded
to
that
system.
This
may
result
in
searches
that
use
large
amounts
of
processing
power,
expose
sensitive
patient
data,
or
both.
If
a
server
acts
as
a
repository
of
conformance
resources,
it
should
tightly
control
modifications
to
its
data:
updates
to
conformance
resources
are
usually
managed
by
a
review
process
to
ensure
backwards
compatibility
and
stability.
Worst
case,
changes
to
these
resources
may
result
in
dependent
systems
running
the
risk
of
being
misconfigured.
5.0.4
Common
use
Cases
Conformance
resources
are
commonly
used
as
part
of
an
Implementation
Guide
or
CapabilityStatement
resource.
There
are
many
ways
to
use
the
resources
independently
however,
including:
An
instance
of
a
resource
may
reference
one
or
more
StructureDefinitions
to
claim
conformance
to
the
rules
laid
out
in
those
StructureDefinitions
A
server
may
serve
CapabilityStatement
resources,
effectively
functioning
as
a
discovery
endpoint
for
services
within
an
organization
A
code-generation
tool
may
use
StructureDefinitions
and
OperationDefinitions
to
generate
code
that
represents
the
structures
as
classes
and
operations
as
remotely
callable
functions
to
provide
an
easier
programming
model
to
a
software
developer.
A
server
may
act
as
a
repository
of
NamingSystem
resources,
so
vendors
and
implementers
can
quickly
look
up
the
URLs
or
oids
for
a
given
terminology
or
identifier
system.
5.0.5
Developmental
Roadmap
A
subset
of
the
conformance
resources
has
been
tested
and
used
in
production
tooling
and
are
now
normative.
These
include
StructureDefinition
:
This
resource
is
normative
and
ValueSet.
Others,
like
CapabilityStatement,
stable
(see
Note
about
normative
status
).
No
additional
future
changes
to
scope
have
been
used
widely,
but
not
across
all
elements.
As
a
consequence,
these
discussed
or
considered
OperationDefinition
:
This
resource
is
normative
and
stable,
though
two
new
features
relating
to
the
use
of
parameters
were
added
in
this
release.
No
additional
future
changes
to
scope
have
a
considerable
number
been
discussed
or
considered
CapabilityStatement
:
The
core
of
this
resource
is
stable
and
normative.
There
are
still
a
few
elements
marked
on
the
resource
labelled
as
'trial-use'.
The
FHIR
Infrastructure
work
group
intends
to
develop
an
implementation
guide
for
"trial
use",
while
other
parts
are
normative
clients
to
use
to
ask
servers
about
their
capabilities
at
a
much
finer
granularity
than
that
offered
by
the
CapabilityStatement,
and
then
those
trial
use
elements
will
no
longer
change
be
removed
/
deprecated
or
made
normative
in
a
substantive
way.
Other
resources
are
future
version.
SearchParameter
:
This
resource
has
been
used
widely,
and
is
considered
stable,
but
some
parts
or
still
under
development:
undergoing
trial
use
ImplementationGuide
:
:
This
resource
has
been
used
in
the
HL7
production
tooling
widely,
and
is
considered
stable,
but
has
not
received
much
use
outside
of
these
all
tools
yet.
are
fully
across
all
the
changes
yet
CompartmentDefinition
:
was
new
:
This
resource
is
in
STU3,
and
as
such
trial-use.
HL7
is
expected
to
be
the
only
publisher
of
this
resource
StructureMap
:
This
resource
is
stable
but
new
feature
proposals
are
welcome;
there
is
a
spread
of
tools
but
it
has
not
undergone
much
production
use
These
resources
have
yet
been
mainly
used
in
the
tools
used
to
build
the
FHIR
publication,
early-adopter
implementation
guides
and
the
FHIR
Foundation
conformance
it's
full
potential
yet
MessageDefinition
:
This
resource
registry.
In
future,
we
expect
to
see
more
widespread
use
of
these
resources
is
still
undergoing
testing;
messaging
has
not
been
used
that
widely
(though
it
has
been
used
deeply
in
validation
tooling,
code-generators
a
couple
of
countries)
GraphDefinition
:
This
resource
was
re-written
from
ground
up
and
more
extensive
model-based
guide
authoring
tools.
needs
considerable
testing
before
the
design
can
be
considered
proven