DSTU2
This
page
is
part
of
the
FHIR
Specification
(v0.0.82:
(v1.0.2:
DSTU
1).
2).
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 : N/A | Ballot Status : DSTU 2 |
The
contents
of
the
resource
and
the
formats
used
to
represent
it
SHALL
conform
to
the
rules
described
in
this
specification,
as
defined
in
the
narrative
FHIR
specification
describes
a
set
of
the
specification,
and
as
controlled
by
the
conformance
properties
defined
below.
Note:
This
spec
uses
the
conformance
verbs
SHALL,
SHOULD,
resources
,
and
MAY
as
defined
in
RFC
2119
.
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
(unlike
RFC
2119),
consequence,
this
specification
allows
that
different
applications
may
not
be
able
to
be
interoperate
because
of
how
they
use
optional
features.
To
allow
As
a
consequence,
applications
claiming
conformance
to
manage
this,
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:
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:
| Value Set | Defines a set of coded values (see " Using Codes " for more details) |
|
|
Makes
rules
about
how
a
resource
(or
type)
and
|
| 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 |
| Implementation Guide | 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:
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:
Note
that
none
The
contents
of
these
tools
are
able
a
resource
and
the
formats
used
to
check
complete
conformance
represent
resources
SHALL
conform
to
the
rules
described
in
this
specification.
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.
All
elements
attributes
defined
in
FHIR
have
a
cardinality
as
part
of
their
definition
-
a
minimum
number
of
required
appearances,
appearances
and
a
maximum
number.
This
number
specifies
These
numbers
specify
the
number
of
times
the
element
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
either
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
sometimes
very
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.
This
In
some
cases,
this
specification
may
publish
publishes
additional
profiles
that
define
which
elements
are
required
in
which
situation,
or
alternatively,
such
particular
situations.
Similar
profiles
might
be
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.
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
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
profiles
declare
extensions.
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
Resource
Profile
.
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
element
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 |
|
status
| ?! Σ | 0..1 | code |
active
|
unconfirmed
|
confirmed
|
inactive
|
resolved
|
refuted
|
entered-in-error
AllergyIntoleranceStatus ( Required ) |
|
criticality
| Σ | 0..1 | code |
CRITL
|
CRITH
|
CRITU
AllergyIntoleranceCriticality ( Required ) |
The
value
of
element
"didNotOccurFlag"
affects
the
entire
meaning
of
the
resource
-
if
it
is
set
to
true,
refuted,
the
whole
entire
resource
must
be
understood
differently,
and
so
it
is
not
safe
for
implementations
to
ignore
it.
Generally,
elements
labeled
"Is-Modifier
As
a
consequence,
it
is
labelled
as
'is
modifier
=
true"
also
have
true'.
In
this
tabular
representation
of
the
resource,
this
shows
as
the
flag
'?!'.
The
JSON
and
XML
representations
of
a
minimum
cardinality
resource
definition
have
their
own
representation
of
1,
to
introduce
certainty
'is
modifier
=
true'
status,
and
it
is
defined
directly
in
their
handling.
a
ElementDefinition
.
Is-Modifier elements SHALL be represented in the narrative summary of the resource.
If
the
value
of
such
an
a
modifier
element
is
not
explicit
in
the
instance,
or
known
by
the
context,
the
resource
cannot
may
not
be
able
to
be
safely
understood.
Irrespective
of
the
Wherever
possible,
elements
labeled
"Is-Modifier
=
true"
also
have
a
minimum
cardinality,
implementations
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
SHALL
SHOULD
ensure
that
appropriate
values
for
isModifier
elements
are
provided.
Is-Modifier
elements
SHALL
be
represented
in
the
narrative
summary
of
the
resource.
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,
sure
that,
due
to
their
implementation
environment,
that
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 .
Labelling
Labeling
an
element
Must-Support
means
that
implementations
that
produce
or
consume
resources
SHALL
provide
"support"
for
the
element
in
some
meaningful
way.
Exactly
what
this
means
is
impossible
to
describe
or
clarify
as
part
of
the
FHIR
specification.
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 | 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 | Whether the constraint is an error, or a warning. The exact difference in meaning of these depends on context, but an error is associated with "SHALL" and systems rejecting content, where as a warning might not be |
| Human Description | A human description of the rule intended to be show as the explanation for a message when the constraint is not met |
| XPath Expression | An XPath expression that must evaluate to true when run on the element in the XML representation. To use the constraint in JSON, the resource must be converted to XML |
DSTU Note: Alternatives to XPath are being sought. Not only are XPath expressions XML specific, but the expressions defined in the specification require XSLT2, which is not well supported. The ideal solution will apply to either XML or JSON, and be widely supported in off the shelf tools.
Feedback is welcome here
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.
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:
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
DSTU
(v0.0.82.2943)
DSTU2
(v1.0.2-7202)
generated
on
Tue,
Sep
30,
2014
18:10+1000.
Sat,
Oct
24,
2015
07:44+1100.
Links:
What's
a
DSTU?
Search
|
Version
History
|
Table
of
Contents
|
Compare
to
DSTU1
|
|
Propose
a
change