Foundation
This
page
is
part
of
the
FHIR
Specification
(v3.3.0:
R4
Ballot
2).
(v4.2.0:
R5
Preview
#1).
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
R2
|
FHIR
Infrastructure
Work
Group
|
Maturity
Level
:
|
|
|
This
page
standard.
See
the
Infrastructure
Package
|
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
conformance
to
Systems
can
only
claim
FHIR
that
does
not
reference
a
CapabilityStatement
instance
has
limited
utility.
System
capabilities
that
cannot
be
Conformance
for
functionality
described
by
a
in
the
applicable
CapabilityStatement
cannot
be
considered
FHIR
conformant.
.
This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in 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
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. 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.
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
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
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 other than "ok"). 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
MustSupport
means
that
implementations
that
produce
or
consume
resources
SHALL
provide
"support"
for
the
element
in
some
meaningful
way.
Because
the
base
FHIR
specification
is
intended
to
be
independent
of
any
particular
implementation
context,
no
elements
are
flagged
as
"must-support"
mustSupport
=true
as
part
of
the
base
specification.
This
flag
is
intended
for
use
in
profiles
that
have
a
defined
implementation
context.
For
this
reason,
the
specification
itself
never
labels
any
elements
as
must-support.
MustSupport.
This
is
done
in
Resource
Profiles
StructureDefinitions
,
where
the
profile
labels
an
element
as
mustSupport=true.
When
a
profile
does
this,
it
SHALL
also
make
clear
exactly
what
kind
of
"support"
is
required,
as
this
can
mean
many
things.
could
involve
expectations
around
what
a
system
must
store,
display,
allow
data
capture
of,
include
in
decision
logic,
pass
on
to
other
data
consumers,
etc.
Note that an element that has the property IsModifier is not necessarily a "key" element (e.g. one of the important elements to make use of 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.
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 |
|
| 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 |
| XPath | An XPath expression that must evaluate to true when run on the element in the XML representation |
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.
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)
CI
Build
hl7.fhir.core#4.2.0
(GitHub
f996518d66)
generated
on
Tue,
Apr
3,
2018
12:18+1000.
QA
Page
Dec
31,
2019
21:18+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
QA
Page
|
Compare
to
DSTU3
R4
|
|
Propose
a
change