Foundation
This
page
is
part
of
the
FHIR
Specification
(v3.3.0:
R4
Ballot
2).
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
|
Responsible
Owner:
FHIR
Infrastructure
Work
Group
|
|
The
FHIR
specification
describes
a
set
of
resources
,
and
several
different
frameworks
for
exchanging
resources
between
different
systems.
Because
of
its
general
nature
and
wide
applicability,
the
rules
made
in
this
specification
are
generally
fairly
loose.
As
a
consequence,
this
specification
allows
that
different
applications
might
not
be
able
to
interoperate
because
of
how
they
use
optional
features.
As
a
consequence,
applications
Applications
claiming
conformance
to
this
specification
make
the
claim
in
respect
of
a
specific
exchange
framework,
and
in
regard
to
specific
details
about
their
usage
of
those
frameworks
and
resource
contents.
Applications claim conformance to one (or more) of the following exchange frameworks:
To
provide
details
about
specific
usage
of
the
frameworks
and
resource
contents,
FHIR
provides
a
conformance
layer
that
implementers
and
implementers,
national/regional
programs
programs,
and
other
profiling
organizations
such
as
IHE,
can
use
to
provide
a
computable
statement
about
how
the
resources
and
their
exchange
paradigms
are
used
to
solve
particular
use
cases.
The
conformance
layer
itself
is
implemented
using
the
following
key
resources:
| Value Set | Defines a set of coded values (see " Using Codes " for more details) |
| StructureDefinition |
Makes
rules
about
how
a
resource
(or
type)
and
its
data
elements
are
used
in
a
particular
|
| CapabilityStatement | A statement of the kinds of resources and operations provided and/or consumed by an application. The Capability Statement references profiles to describe specific use of resources by the application |
| Implementation Guide |
A
single
coherent
collection
of
capability
statements,
profiles,
extensions,
value
|
The specification also provides a number of tools that can assist with enforcing technical conformance to this base specification.
FHIR
is
a
closed
specification.
The
specification
defines
what
is
possible
and
profiles
on
it.
required
for
those
portions
of
an
API
or
exchange
framework
that
wish
to
declare
themselves
as
FHIR
conformant,
and
that
includes
exchange
resources
that
conform
to
the
documented
requirements
of
this
specification.
Systems
may
choose
to
support
capabilities
beyond
those
defined
by
FHIR
(e.g.,
by
adding
additional
end
points/services
with
other
names),
but
those
portions
of
their
interfaces
that
extend
beyond
what
FHIR
explicitly
allows
cannot
be
considered
or
described
as
"FHIR
conformant".
Conformance with this specification does not provide any guarantee of patient or data safety. However, choosing to not conform to this specification carries additional risk in two ways:
Any
assertion
of
Systems
can
only
claim
FHIR
Conformance
for
functionality
described
in
the
applicable
CapabilityStatement
.
RESTful
Servers
are
required
to
provide
a
CapabilityStatement
on
request.
Other
systems
or
applications
that
wish
to
assert
formal
conformance
to
FHIR
that
does
not
reference
MAY
choose
to
publish
a
CapabilityStatement
instance
has
limited
utility.
System
capabilities
that
cannot
be
described
by
defining
how
they
conform.
Assertions
of
conformance
to
FHIR
in
the
absense
of
a
CapabilityStatement
have
little
meaning
because
they
cannot
be
considered
FHIR
conformant.
tested/verified.
This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in the RFC 8174 clarification of RFC 2119. Unlike RFC 2119, however, this specification allows that different applications might not be able to interoperate because of how they use optional features. In particular:
The contents of a resource and the formats used to represent resources SHALL conform to the rules described in this specification, as defined in the narrative of the specification, and as controlled by the conformance properties defined below.
Data
elements
defined
in
resources
and
data
types
datatypes
have
3
properties
that
are
directly
related
to
conformance:
Cardinality,
Is-Modifier,
and
Must-Support.
MustSupport.
These
interact
to
place
conformance
requirements
on
implementations.
All attributes defined in FHIR have cardinality as part of their definition - a minimum number of required appearances and a maximum number. These numbers specify the number of times the attribute may appear in any instance of the resource type. This specification only defines the following cardinalities: 0..1, 0..*, 1..1, and 1..*. Profiles that describe specific use cases may use other values for cardinality within the limits of the cardinality defined by the base resource.
Note
that
when
present,
elements
cannot
be
empty
-
they
SHALL
have
a
value
attribute,
child
elements,
or
extensions.
The
element's
value
attribute/property
can
never
be
empty.
Either
it
is
absent,
or
it
is
present
with
at
least
one
character
of
non-whitespace
content.
This
means
that
setting
an
element
to
a
minimum
cardinality
of
1
does
not
ensure
that
valid
data
will
be
present;
specific
FHIRPath
constraints
are
required
to
ensure
that
the
required
data
will
be
present.
In this specification, very few elements have a minimum cardinality of 1. Resources are used in many contexts, often quite removed from their primary use case, and sometimes even basic information is quite incomplete. For this reason, the only elements that have a minimum cardinality of 1 are those where they are necessary to any understanding of the resource or element that contains them. The minimum cardinalities should not be taken as a guide to what elements are expected to be present in any particular use of the resource, including their normal/primary usage purpose. In some cases, this specification publishes additional profiles that define which elements are required in particular situations. Similar profiles are published by jurisdictions, vendors, profiling organizations, or projects. If a parent element has a minimum cardinality of 1 and all of its children elements have a mimimum cardinality of 0, then this implies that at least one of the children elements must be present.
For
elements
that
have
cardinality
>
1,
the
order
in
which
they
appear
may
have
meaning.
Unless
the
element
definition
(either
in
this
specification
or
the
extension)
defines
a
meaning
to
the
order
explicitly
(using
ElementDefinition.orderMeaning
,
),
the
meaning
of
the
order
is
not
defined,
and
implementations
are
allowed
to
reorder
the
elements.
Note
that
it
is
not
possible
to
define
a
meaning
for
the
order
of
the
elements
in
a
profile
using
a
StructureDefinition
.
When
there
is
no
definition
of
the
meaning
of
the
order,
implementations
that
need
to
choose
a
single
element
from
a
list
of
elements
for
some
use
SHALL
do
so
based
on
the
semantics
of
the
content
of
the
elements
element
that
repeats.
Profiles
and
Implementation
guides
may
often
make
rules
about
this
selection
process.
Clients should not depend on servers maintaining ordering of elements, unless the retrieved resource conforms to a profile which mandates maintenance of ordering. If a server cannot maintain ordering, it must strip off known profile tags which require maintenance of ordering, and strip off unknown profiles (since they might require maintenance of ordering).
Is-Modifier is a boolean property that is assigned when an element is defined, either as part of the base resource contents in this specification, or when extensions are defined .
An
element
is
labeled
"Is-Modifier
=
true"
a
modifier
if
and
only
if
the
value
it
contains
cannot
be
safely
ignored
because
its
value,
or
its
meaning
if
missing
,
may
change
cause
the
interpretation
of
the
containing
element
that
contains
it
(including
if
or
one
of
its
descendants
to
no
longer
conform
to
the
element
is
stated
definition
for
the
resource
as
a
whole).
element.
Typical
examples
of
elements
that
are
labeled
"Is-Modifier"
are
elements
such
as
"status",
"active",
"refuted",
or
"certainty".
"certainty"
that
invert
or
negate
the
meaning
of
the
resource
(or
element)
that
contains
them.
Modifier is not an indication of the degree of importance for a particular piece of information or whether the element ought to be ignored when the resource is used for common use-cases. It is expected that if you ignore an element you may miss an important piece of computable meaning.
For example, consider Observation:
Observation.status
is
a
modifier.
This
element
allows
the
entered-in-error
code,
which
indicates
that
no
actual
Observation
occurred
at
all.
The
definition
of
Observation
indicates
that
it
is
a
measurement
that
has
been
made
-
and
doesn't
allow
for
the
possibility
of
a
measurement
that
wasn't
made.
As
a
result,
if
the
status
element
were
ignored
and
an
Observation
were
interpreted
at
face
value
based
on
its
definition,
a
system
or
user
would
infer
that
an
Observation
had
occurred,
which
would
be
false
Observation.subject
is
not
a
modifier.
If
an
application
ignores
the
element,
it
wouldn't
know
who
or
what
was
observed,
which
would
make
the
remaining
information
largely
useless
for
most
usage.
However,
any
system
that
ignores
the
subject
would
not
have
a
false
understanding
of
the
Observation
as
it's
defined.
The
system
would
understand
what
type
of
observation
was
made,
when
and
what
was
found,
just
not
who
it
was
about
Observation.code
is
not
a
modifier
element.
While
the
Observation
would
have
little
utility
without
the
code,
the
understanding
when
ignoring
the
element
that
“some”
Observation
had
been
made
on
the
specified
subject
at
the
specified
date
and
time
would
still
be
true
when
the
element
was
reintroduced.
The
only
exception
would
be
if
a
value
expressed
in
the
Observation.code
element
could
somehow
convey
that
the
Observation
had
not
occurred
or
otherwise
cause
the
instance
to
diverge
from
the
defined
meaning
of
Observation
when
ignoring
the
element
The
definition
of
is-modifier
has
a
corollary:
any
element
that
meets
the
requirement
that
it
could
cause
the
interpretation
of
the
containing
element
or
its
descendants
to
diverge
from
their
definition
SHALL
explicitly
declare
how
such
divergence
could
occur
and
must
be
marked
as
a
modifier
element.
Any
element
not
marked
is-modifier
and
without
that
explanation
SHALL
NOT
be
used
by
an
implementer
in
such
a
manner
as
to
make
the
element
behave
as
a
modifier.
For
example,
using
a
special
"name"
on
a
patient
to
indicate
that
the
subject
isn’t
a
real
patient,
but
is
instead
an
artificial
structure
used
for
non-patient
tests
would
be
non-conformant
with
FHIR
because
Patient.name
is
not
a
modifier
element
Whether
an
element
is
a
modifier
cannot
be
changed
when
element
usage
is
described
in
a
profile
(i.e.
a
constraining
Structure
Definition
).
.
When
an
element
is
labeled
as
Is-Modifier,
the
documentation
must
be
clear
about
why
it
is
a
modifier.
A typical example of a modifier element is one that negates the element that contains it. For instance, in the following fragment of a resource definition:
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
AllergyIntolerance
|
DomainResource | Allergy or Intolerance (generally: Risk of Adverse reaction to a substance) | ||
onset
|
Σ | 0..1 | dateTime | Date(/time) when manifestations showed |
patient
|
Σ | 1..1 | Reference ( Patient ) | Who the sensitivity is for |
|
verificationStatus
|
?! Σ | 0..1 |
|
unconfirmed
|
confirmed
|
refuted
|
entered-in-error
AllergyIntoleranceVerificationStatus ( Required ) |
|
criticality
|
Σ | 0..1 | code |
CRITL
|
CRITH
|
CRITU
AllergyIntoleranceCriticality ( Required ) |
The
definition
of
an
AllergyIntolerance
is
that
it
contains
information
about
"Risk
of
harmful
or
undesirable,
physiological
response
which
is
unique
to
an
individual
and
associated
with
exposure
to
a
substance".
If
the
value
of
the
'verificationStatus'
element
affects
the
entire
meaning
of
the
resource
-
if
it
is
set
to
refuted,
entered-in-error
,
the
entire
resource
must
be
understood
differently,
does
not
actually
contain
valid
information
about
any
risk
of
exposure,
and
so
it
is
not
safe
for
implementations
applications
to
ignore
it.
this
element.
As
a
consequence,
it
is
labeled
as
'is
modifier
=
true'.
In
this
tabular
representation
of
the
resource,
this
shows
as
the
flag
'?!'.
The
JSON
and
XML
representations
of
a
resource
definition
have
their
own
representation
of
'is
modifier
=
true'
status,
and
it
is
defined
directly
in
a
ElementDefinition
.
If
a
narrative
summary
is
present,
and
the
status
is
generated
,
Is-Modifier
elements
SHALL
be
represented
in
the
narrative
summary
of
the
resource.
If
Narrative
is
present
with
some
other
status
Is-modifier
elements
SHOULD
be
represented.
If the value of a modifier element is not explicit in the instance, or known by the context, the resource might not be able to be safely understood. Wherever possible, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, in order to introduce certainty in their handling. However, sometimes this is not possible - much legacy data is not well described. Implementations producing resources SHOULD ensure that appropriate values for isModifier elements are provided at all times.
Implementations
processing
the
data
in
resources
SHALL
understand
the
impact
of
the
element
when
using
the
data.
Implementations
are
not
required
to
"support"
the
element
in
any
meaningful
way
-
they
may
achieve
this
understanding
by
rejecting
instances
that
contain
values
outside
those
they
support
(for
instance,
an
application
may
refuse
to
accept
observations
with
a
reliability
status
other
than
"ok").
"final").
Alternatively,
implementations
may
be
able
to
be
sure
that,
due
to
their
implementation
environment,
such
values
will
never
occur.
However
applications
SHOULD
always
check
the
value
irrespective
of
this.
Note that processing the data of a resource typically means copying or filtering data out of a resource for use in another context (display to a human, decision support, exchange in another format where not all information is included or storing it for this kind of use). Servers and background processes that simply move whole resources around unchanged are not "processing the data of the resource", and therefore these applications are not required to check Is-Modifier elements.
Every
element
in
the
base
resource
has
a
value
of
"true"
or
"false"
for
the
Is-Modifier
flag.
The
value
of
the
flag
cannot
be
changed
by
profiles
on
the
resource,
in
either
direction.
When
a
profile
StructureDefinition
defines
an
extension,
it
labels
the
extension
with
the
Is-Modifier
flag,
and
this
cannot
be
changed
in
other
profiles.
Note
that
extensions
that
have
is-Modifier
=
true
are
represented
differently
in
resource
instances
("modifierExtension"
instead
of
"extension"),
and
there
are
additional
rules
about
how
they
are
handled
.
Here
is
a
list
of
all
the
modifier
elements
defined
in
the
specification:
The
Most
status
and
experimental
elements
on
are
marked
as
modifiers
because
of
the
resources
ActivityDefinition
,
CapabilityStatement
,
CodeSystem
,
CompartmentDefinition
,
ConceptMap
,
ExpansionProfile
,
GraphDefinition
,
ImplementationGuide
,
Library
,
Measure
,
MessageDefinition
,
OperationDefinition
,
PlanDefinition
,
Questionnaire
,
SearchParameter
,
StructureDefinition
,
StructureMap
,
TestScript
and
ValueSet
presence
of
the
entered-in-error
status.
Other
modifiers
are
defined:
Labeling
an
element
Must-Support
means
that
implementations
that
produce
or
consume
resources
SHALL
provide
"support"
for
the
element
in
some
meaningful
way.
Because
the
base
The
FHIR
specification
is
intended
to
be
independent
of
any
particular
implementation
context,
no
elements
are
flagged
as
"must-support"
as
part
primarily
concerned
with
valid
interfaces
of
various
kinds
(APIs,
messaging,
etc.)
and
the
base
specification.
This
flag
is
intended
rules
for
use
the
content
in
profiles
resource
instances
exchanged
between
applications.
Implementation
guides
that
have
a
defined
describe
specific
implementation
context.
solutions
and
application
roles
are
also
concerned
with
application
behavior
-
what
information
must
be
provided
under
what
conditions,
and
setting
expectations
for
how
particular
data
elements
are
handled.
For
this
reason,
Implementation
guides
can
make
rules
about
the
specification
itself
never
labels
any
elements
as
must-support.
This
is
done
in
Resource
Profiles
,
where
behavior
of
applications
by
using
the
profile
labels
an
element
as
mustSupport=true.
When
a
profile
does
this,
it
SHALL
also
make
clear
exactly
what
kind
mustSupport
property
of
"support"
is
required,
as
this
can
mean
many
things.
ElementDefinition
in
profiles,
and
the
Obligation
Extension
extension.
For
further
information,
read
Implementation
Obligations
.
Note
that
an
element
that
has
since
the
property
IsModifier
base
specification
is
only
describing
the
interfaces
and
resources,
not
necessarily
a
"key"
element
(e.g.
one
of
any
particular
solution,
the
important
elements
to
make
use
of
base
application
does
not
specify
any
application
obligations
in
the
resource),
nor
is
it
automatically
mustSupport
-
however
both
of
these
things
are
more
likely
to
be
true
for
IsModifier
elements
than
for
other
elements.
resource
definitions.
All elements may have constraints attached to them (also known as 'invariants'). Constraints defined on an element have the following properties:
| Key | Identifies the constraint uniquely amongst all the constraints in the context - typically, this is used to refer to the constraint in an error message |
| Requirements | An explanation of why the constraint has been applied - what harmful conditions are being avoided |
| Severity |
|
| Suppress |
Allows
for
suppress
warnings
or
|
| Human Description |
A
human
description
of
the
rule
intended
to
be
|
| Expression | A FHIRPath expression that must evaluate to true when run on the element |
|
|
|
Many constraints are defined in the base specification. In addition, additional constraints may be defined in profiles that apply to resources. Systems are not required to evaluate the constraints, just as they are not required to check for conformance, or schema validity. However, systems SHOULD always ensure that all resources are valid against all applicable constraints.
Constraints have a severity level:
| Error (rule) | A rule that all resources must conform to. Validators should report it as an error if the rule is violated, and applications processing the content can reject it as an invalid resource |
| Warning | Report this as a warning that there may be a problem with the resource, but it is considered valid and can be processed normally |
| Guideline | A warning marked with an extension ( http://hl7.org/fhir/StructureDefinition/elementdefinition-bestpractice ) that indicates that it should be a treated as an error if the implementation context asks a validator to enforce best practice rules. See Best Practices for a full list |
Elements can also be explicitly associated with constraints defined elsewhere. This is a notification to implementers that the element is affected by the constraint. It has no meaning when the constraints are evaluated.
Profiles may define additional constraints that apply to an element, but they cannot alter or remove constraints that are already applied.
Constraints have a key that is used to identify the constraint, for example, in an error message. The constraint keys are required to be unique when they are declared. However constraints are repeated throughout profiles where ever the original element definitions, which means that there's no simple way to constrain the keys to be unique. FHIR validators will validate that constraint keys are meaningfully unique as they can.
In
addition
to
the
conformance
metadata,
each
element
has
other
metadata
properties:
properties
defined
in
the
ElementDefinition
:
This specification includes many examples. While every effort has been made to ensure that the examples are fully conformant to the specification, if the examples disagree with the specification, the specification is considered correct and normative, not the examples. This same rule applies to the reference implementations.
The examples reflected in this specification do *not* represent actual people. Any resemblance to real people - alive or dead - is entirely coincidental. In some cases, examples may be drawn from real clinical data. However, if this has occurred, the content has been scrubbed to remove any identifying information.
FHIR
®©
HL7.org
2011+.
FHIR
Mixed
Nomative/Trial
Use
Ballot
(v3.3.0-13671)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Tue,
Apr
3,
2018
12:18+1000.
QA
Page
Fri,
Nov
14,
2025
21:00+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU3
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change