Foundation
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
|
|
|
|
The FHIR specification describes a set of
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
may
not
be
able
to
be
interoperate
because
of
how
they
use
optional
features.
As
a
consequence,
applications
claiming
conformance
to
this
specification
make
the
claim
in
respect
of
a
specific
exchange
framework,
and
in
regard
to
a
specific
details
about
their
usage
of
those
frameworks
and
resource
contents.
Application
claim
conformance
to
one
(or
more)
of
the
following
exchange
framworks:
"RESTful
FHIR":
the
RESTful
API
, 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 may not be able to be interoperate because of how they use optional features. As a consequence, applications claiming conformance to this specification make the claim in respect of a specific exchange framework, and in regard to a 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 national/regional programs 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:
|
|
Defines a set of coded values (see "
|
|
StructureDefinition
| Makes rules about how a resource (or type) and its data elements are used in a particular context. A structure definition references value sets for the coded elements in a resource |
|
Conformance
| A statement of the kinds of resources and operations provided and/or consumed by an application. The conformance resource references profiles to describe specific use of resources by the application |
|
| A single coherent collection of conformance statements, profiles, value set, and documentation describing a set of interoperable applications |
The specification also provides a number of tools that can assist with enforcing technical conformance to this base specification and profiles on it.
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:
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.
Note: 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
may
not
be
able
to
interoperate
because
of
how
they
use
optional
features.
Data
elements
defined
in
resources
and
data
types
have
3
properties
that
are
directly
related
to
conformance:
Cardinality,
Is-Modifier,
and
Must-Support.
These
interact
to
place
conformance
requirements
on
implementations.
. Unlike RFC 2119, however, this specification allows that different applications may not be able to interoperate because of how they use optional features.
Data elements defined in resources and data types have 3 properties that are directly related to conformance: Cardinality, Is-Modifier, and Must-Support. 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 XPath 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, 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, 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
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
that
repeats.
Profiles
and
Implementation
guides
may
often
make
rules
about
this
selection
process.
. 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 that repeats. Profiles and Implementation guides may often make rules about this selection process.
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" if the value it contains may change the interpretation of the element that contains it (including if the element is the resource as a whole). Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty". 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:
). 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 |
|
|---|---|---|---|---|
AllergyIntolerance
|
DomainResource |
|
||
onset
|
Σ | 0..1 | dateTime |
|
patient
|
Σ | 1..1 | Reference ( Patient ) |
|
|
status
|
|
0..1 | code |
AllergyIntoleranceStatus |
|
criticality
|
Σ | 0..1 | code |
AllergyIntoleranceCriticality |
The value of element affects the entire meaning of the resource - if it is set to refuted, the entire resource must be understood differently, and so it is not safe for implementations to ignore it. As a consequence, it is labelled as 'is modifier = true'. In this tabular representation of the resource, this shows as the flag '?!'. The
JSON
and
and
XML
representations
of
a
resource
definition
have
their
own
representation
of
'is
modifier
=
true'
status,
and
it
is
defined
directly
in
a
representations of a resource definition have their own representation of 'is modifier = true' status, and it is defined directly in a
ElementDefinition
.
Is-Modifier
elements
SHALL
be
represented
in
the
narrative
summary
of
the
resource.
If
the
value
of
a
modifier
element
is
not
explicit
in
the
instance,
or
known
by
the
context,
the
resource
may
not
be
able
to
be
safely
understood.
Wherever
possible,
elements
labeled
"Is-Modifier
=
true"
also
have
a
minimum
cardinality
of
1,
or
a
default
value,
in
order
to
introduce
certainty
in
their
handling.
However
sometimes
this
is
not
possible
-
much
legacy
data
is
not
well
described.
Iimplementations
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
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
.
.
Is-Modifier elements SHALL be represented in the narrative summary of the resource.
If the value of a modifier element is not explicit in the instance, or known by the context, the resource may not be able to be safely understood. Wherever possible, elements labeled "Is-Modifier = true" also have a minimum cardinality of 1, or a default value, 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 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:
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 FHIR specification is intended to be independent of any particular implementation context, no elements are flagged as "must-support" 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. This is done in Resource Profiles , 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.
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 |
|
| Requirements |
|
| Severity |
|
|
|
|
|
|
expression that must evaluate to true when run on the element
|
|
|
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.
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.
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.
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.
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:
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.
© 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