FHIR
Release
3
(STU)
CI-Build
Terminology
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
STU
3).
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
|
Work
Group
|
|
Many
elements
in
the
FHIR
resources
have
a
coded
value
:
some
fixed
string
(a
sequence
of
characters)
assigned
elsewhere
that
identifies
some
defined
"concept".
"concept".
The
sequence
of
characters
and
its
meaning
may
be
defined
in
one
of
several
places:
code
system,
or
HL7
table)
,
or
SNOMED
CT
These
methods
of
defining
codes
are
collectively
called
"code
systems".
"code
systems".
This
list
is
far
from
complete;
there
are
many
ways
to
define
code
systems,
and
they
vary
widely
in
sophistication
and
size.
Throughout
this
specification,
coded
values
are
always
treated
as
a
pair
composed
of
"system"
"system"
and
"code",
"code",
where
the
system
is
a
URL
that
identifies
the
code
system
that
defines
the
codes.
Note
that
system
values
are
always
case
sensitive.
Different
code
systems
make
their
own
rules
as
to
whether
the
codes
they
define
are
case
sensitive
or
not.
Note
that
all
the
codes
defined
by
FHIR
itself
are
case
sensitive
and
SHALL
be
used
in
the
provided
case
(usually,
but
not
always,
lowercase).
The
FHIR
framework
for
using
coded
values
is
based
on
the
fundamental
framework
defined
in
section
5
of
the
HL7
v3
Core
Principles
document,
including
the
separation
between
code
systems
and
value
sets.
The general pattern for representing coded values is using the following four elements:
| system | A URI that identifies the system (see below ) |
| version | A string value representing a version of the original code system (see Code System Versioning ) |
| code | A string value that identifies a concept as defined by the code system |
| display | A description of the concept as defined by the code system |
The Coding datatype represents this pattern. This example shows a LOINC code with the LOINC system, the version of LOINC used for the definition, and the display assigned by LOINC:
{
"system" : "http://loinc.org",
"version" : "2.62",
"code" : "55423-8",
"display" : "Number of steps in unspecified time Pedometer"
}
|
When
codes
are
carried
in
resources,
one
of
|
|
| code | The instance represents the code only. The system is implicit - it is defined as part of the definition of the element, and not carried in the instance. |
| Coding |
A
|
| CodeableConcept |
A
type
that
represents
a
concept
by
plain
text
and/or
one
or
more
coding
elements
(See
the
datatype
notes
for
a
discussion
of
code
translations
and
using
text
in
CodeableConcept)
|
| CodeableReference | A type that can have either a reference to another resource, or a to a concept using a CodeableConcept |
| In addition, the following datatypes also carry coded values, or content that can be treated as a code and bound to a valueset: | |
| Quantity |
|
| string |
The
instance
carries
a
string.
In
some
cases,
applications
may
wish
to
control
the
set
of
valid
strings
for
a
particular
element,
so
the
string
value
can
be
treated
as
a
coded
element
(like
code
)
|
| uri |
Like
string
,
URIs
can
be
treated
as
a
coded
element
|
Notes:
.
The
set
of
coded
values
that
is
allowed
in
an
element
is
known
as
a
"value
set"
"value
set"
.
Anywhere
these
four
data
types
datatypes
are
used,
the
specification
"binds"
"binds"
a
value
set
to
the
element.
element,
and
for
the
types
code,
Coding,
and
CodeableConcept,
always
does.
The difference between a code system and a value set is an important distinction that is easily missed by implementers, since the difference is often overlooked in system design. For instance, it's not unusual to see an application table that is a mixed list of codes, containing some LOINC codes and also some additional in-house codes. Quite often, there is no explicit differentiation between them; only the fact that a code happens to look like a LOINC code betrays its origin.
For
data
exchange,
on
the
other
hand,
explicitly
tracking
the
source
The
code
system
identifier
of
the
code
concept
is
both
important
and
necessary.
In
order
to
do
this,
each
necessary
for
interoperable
data
exchange.
Each
code
system
that
defines
codes
is
assigned
a
URL
that
identifies
it,
uri.
The
combination
of
the
code
system
identifier
(uri)
and
all
the
codes
it
defines
are
actually
a
pair
("Code
Pair":
a
name
with
a
namespace).
So
in
concept
identifier
(e.g.,
code)
is
unique.
Note
that
code
system
version
may
be
necessary
to
achieve
uniqueness
when
the
code
system
does
not
follow
concept
permanence
rules.
In
the
case
of
this
the
mixed
list
example
from
the
previous
paragraph,
there
are
two
code
systems:
LOINC
(http://loinc.org)
and
a
local
one
(let's
say
it
has
been
given
with
the
URL:
http://example.com/codesystems/additional-test-codes).
uri:
http://example.com/codesystems/additional-test-codes.
The
application
table
is
a
single
value
set
(a
set
of
Code
Pairs)
that
definition
includes
codes
concept
identifier
(codes)
from
each
of
those
the
two
namespaces.
The
value
set
itself
code
systems.
ValueSet.url
(e.g.,
"http://example.com/fhir/ValueSet/test-codes")
is
given
its
own
URL
as
an
the
canonical
identifier
(e.g.
"http://example.com/fhir/ValueSet/test-codes").
This
identifies
for
the
value
set.
The
value
set
of
Code
Pairs,
but
uri
is
never
used
not
the
same
as
the
namespace
in
a
actual
code
pair,
or
in
an
instance.
In
FHIR,
Code
Pairs
system
uri.
Concepts
are
always
represented
as
"code"
identified
by
code
and
"system",
system
,
except
for
the
simple
data
type
datatype
code
where
the
namespace
(e.g.
the
code
system
element/property)
is
fixed
in
the
schema
a
specification
(e.g.,
core
specification,
implementation
guide,
profile)
and
not
represented
explicitly.
Note that for some code systems, there is a single correct mechanism by which to represent codes defined by the system as a single URL. These single URLs are used in the context of the RDF (Turtle) format to enable ontological reasoning. The URL is often a direct reference to a web source that can provide additional definitional material about the concept. Where the mechanism is known, and defined by the code system, it is described in this specification.
The
URL
in
a
system
is
always
a
reference
to
a
code
system,
not
to
a
value
set.
The
system
ensures
that
codes
can
be
unambiguously
traced
back
to
their
original
definition,
and
that
logical
comparisons,
matching
and
inferences
can
be
performed
consistently
by
different
systems.
For
this
reason,
choice
of
the
correct
URI
for
the
system
attribute
is
critical.
The correct value to use in the system for a given code system can be determined by working through the following list, in order:
(THO)
-
,
and
the
code
system
to
determine
if
a
request
is
in
process
to
obtain
an
identifier.
,
,
and
the
code
system
is
In
the
unusual
situation
where
a
code
system
is
not
resolved
by
this
list,
and
there
is
no
publisher
to
consult,
implementers
must
choose
a
URI
to
use.
The
priority
should
be
to
choose
a
unique
value
that
won't
accidently
be
used
by
another
implementer
for
a
different
purpose
-
or
a
very
similar
purpose
with
create
a
different
scope.
temporary
identifier
following
this
pattern:
terminology.hl7.org/temporary/CodeSystem/xxxx.
Contact
the
HL7
Vocabulary
co-chairs.
For publishers of code systems, the following considerations should be kept in mind when defining the correct URI to use:
,
RxNorm
,
LOINC
,
and
NDC
as
the
base.
Generally,
allocation
of
URLs
is
hierarchical,
and
most
care
is
required
in
choosing
the
Base
URL.
Note:
if
the
code
system
is
made
available
packaged
inside
a
ValueSet
resource,
the
correct
URL
for
the
system
value
is
ValueSet.codeSystem.system
,
not
ValueSet.uri
.
All code systems define a set of concepts, assign specific codes to them, and provide definitional material to guide implementers in the correct use and understanding of the codes. Many code systems define relationships between the different concepts - is-a, part-of, classifies-with, and many other relationships. These features are represented in the CodeSystem resource, and exchanged using one of the code datatypes described above.
Some code systems define rules for how complex expressions can be built using the basic concepts defined by the code system. This is sometimes referred to as "post-coordination". Some of the more notable code systems that define grammars for expressions are:
There are many others. Any expression defined by the code system is still regarded as a 'code' and represented as such.
This example shows a SNOMED CT expression:
{
"system" : "http://snomed.info/sct",
"code" : "128045006:{363698007=56459004}"
}
No
display
is
provided
in
this
example.
See
the
discussion
here:
https://confluence.ihtsdotools.org/x/UwbJAQ
When
an
element
is
bound
to
a
value
set,
the
it
has
a
binding
that
has
these
properties:
|
|
How the binding should be understood - see below |
|
|
A text description of the use of the codes. If there is no reference, this must be populated. When there is a reference, this can be used to make additional notes about the use and implementation of the value set |
| valueSet |
URL
that
defines
the
value
|
Some
bindings
also
have
a
name
that
is
assigned
for
the
convenience
of
implementers
-
used
for
code
generation.
The
name
is
not
part
of
the
formal
definition
of
the
binding,
and
is
not
used
in
processing.
See
the
extension
Binding
name
.
In addition, elements may have additional bindings . These additional bindings do not replace the main binding (the main binding always applies), but provide additional information and/or rules about the use of codes in the element sometimes in particular contexts of use. Additional bindings have the following properties:
|
| The use of this additional binding. See below for details . |
| valueSet | URL that defines the value set for the additional binding. This is a direct reference to a ValueSet resource |
| documentation | Markdown that describes the use of this value set in this element, given the purpose and usage |
| shortDoco |
A
short
plain
text
|
| usage |
A
set
of
qualifiers
that
restrict
the
|
| any |
If
an
element
repeats,
the
main
binding
applies
to
any
=
true
means
that
the
purpose
=
conformance
|
In
It's
possible
for
there
to
be
multiple
applicable
required
bindings
to
non-overlapping
value
sets
If
the
FHIR
declarative
datatypes,
a
binding
data
type
is
always
represented
using
CodeableConcept
or
CodeableReference,
then
that
would
mean
that
multiple
Codings
are
needed
to
satisfy
the
bindings.
For
other
data
types,
this
would
be
an
ElementDefinition.binding
.
error
(in
way
or
another).
There are a number of places in the specification where value sets are referenced in order to bind a coded value to a value set:
|
ElementDefinition
|
Used
to
bind
a
defined
element
to
a
value
ElementDefinition.binding.additional.valueSet
|
| ConceptMap .source[x] and .target[x] |
|
|
Questionnaire
|
Indicates that answers to a set of questions come from a value set |
|
ValueSet
|
The content of a value set includes the content in the imported value set too |
| OperationDefinition .parameter.binding.valueSet | Used to bind a defined parameter to a value set |
| ValueSet Reference Extension |
Indicates
that
a
|
When referencing value sets, the reference is usually made to the definition of a value set - that is, a value set that defines what codes are in the value set. A terminology server is required to convert this definition to the actual expansion that specifies what codes are in the value set in the context of operation.
There are two types of value set references in this list, direct and logical.
A direct value set reference has the type Reference , and refers directly to a ValueSet based on a URL, usually to a terminology server running a FHIR RESTful API . When accessing a value set based on this kind of reference, a system should access the URL directly (after converting a relative reference to an absolute reference according to the local context). If this process fails, the system is unable to resolve the value set and must handle the error appropriately.
Example:
GET fhir/Questionnaire/234
<Questionnaire>
...
<question>
<options>
<reference value="ValueSet/234234"/>
<reference value="ValueSet/234234"/>
</options>
</question>
....
</Questionnaire>
This
specifies
that
the
values
for
a
particular
questionnaire
come
from
the
ValueSet
with
id
234234
on
the
same
FHIR
end-point.
To
resolve
this,
the
system
would
GET
fhir/ValueSet/234234
Typically, a direct reference like this is good for in-process references, in closed or carefully managed eco-systems. In a more general context, these references tend to be fragile over time because web URLs - including RESTful API URLS - are easily reassigned. For this reason, systems are encouraged to use logical value set references.
A
logical
value
set
reference
has
the
type
uri
,
where
an
absolute
URI
is
provided
that
matches
the
one
in
ValueSet.url.
The
value
set
URL
can
-
and
is
preferred
to
be
-
a
web
address
that
actually
resolves
directly
to
a
fixed
web
address
that
serves
as
the
authoritative
source
for
that
value
set.
Alternatively,
the
system
can
query
its
terminology
server(s)
to
resolve
a
value
set
with
that
URL
as
its
identity.
Example:
<StructureDefinition>
...
<element>
...
<binding>
...
<valueSetUri value="http://hl7.org/fhir/ValueSet/clinical-findings"/>
<valueSet value="http://hl7.org/fhir/ValueSet/clinical-findings"/>
</binding>
...
</element>
....
</StructureDefinition>
This
specifies
that
the
element
is
bound
to
the
value
set
with
a
ValueSet.url
of
http://hl7.org/fhir/ValueSet/clinical-findings
.
One
way
to
accees
access
this
value
set
is
to
try
GET
http://hl7.org/fhir/ValueSet/clinical-findings
-
which
works,
for
this
value
set
-
http://hl7.org/fhir/ValueSet/clinical-findings
returns
the
authoritative
value
set
for
this
URL.
Alternatively, the value set could be resolved using a local terminology server. If that's running a FHIR Terminology Server , then this would work like this:
GET fhir/ValueSet?url=http://hl7.org/fhir/ValueSet/clinical-findings
if the terminology server knows the value set, then it will return the value set. If the URL doesn't resolve to an authoritative value set, and the terminology server(s) don't know the value set, the system is unable to resolve the value set and must handle the error appropriately.
The
value
set
URL
is
allowed
to
be
a
URI
such
as
a
UUID
(e.g.
(e.g.,
urn:uuid:c0e0d027-1250-4278-8f44-33a49dc67916).
These
value
sets
can
never
be
accessed
directly,
and
must
come
from
a
terminology
server.
Note
that
this
specification
HL7
Terminology
defines
many
value
sets
that
have
a
logical
URL
that
is
not
resolvable
(examples
for
SNOMED
CT
,
RxNorm
,
and
LOINC
)
Using a logical reference which is a direct reference to the authoritative value set is the easiest and most reliable approach. However, this requires suitable hosting arrangements, and cannot always be guaranteed, so it is not required.
Version specific Logical References
A
value
set
has
a
two
part
two-part
identifier:
a
url,
and
a
version.
Some
value
sets
only
ever
have
a
single
'version';
a
revision
of
the
value
set
contents
will
cause
a
new
url
to
be
assigned.
Others,
however,
maintain
the
same
URL,
and
change
the
version.
A
terminology
server
may
have
multiple
value
sets
for
the
same
ValueSet.url
with
different
versions.
To
be
precise
about
which
version
of
a
value
set
is
being
referred
to
in
a
value
set
reference,
append
the
version
to
the
canonical
url
URL
with
a
'|'
like
this:
<valueSetUri value="http://hl7.org/fhir/ValueSet/clinical-findings|0.8"/><valueSet value="http://hl7.org/fhir/ValueSet/clinical-findings|0.8"/>
This is a version specific reference to a value set. Searching for this on a terminology server would look like this:
GET fhir/ValueSet?url=http://hl7.org/fhir/ValueSet/clinical-findings&version=0.8
Note that if a value set reference does not have a version, and the server finds multiple versions for the value set, the system using the value set should pick the latest version of the value set and use that. Note that this applies to all conformance resources .
Almost
all
of
the
elements
that
have
a
coded
data
type
datatype
are
bound
to
a
value
set.
The
bindings
are
associated
with
various
degrees
of
flexibility
as
to
how
closely
the
value
set
should
be
followed:
| code | Usage | Documentation |
|---|---|---|
| required | Binding and Additional |
To
be
conformant,
the
concept
in
this
element
SHALL
be
from
the
specified
value
|
| extensible | Binding and Additional | To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead. |
| preferred | Binding and Additional | Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. |
| example | Binding Only | Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included. |
| descriptive | Binding Only | There is no constraint on the allowed set of codes at the root level, though there may be additional bindings that apply in certain contexts. The root binding element will be a description that gives guidance on potential downstream constraint of the allowed codes and/or highlights the presence of additional bindings. |
| component | Additional Only | the value set is a component of the main conformance binding. This is used to provide additional documentation about the use of the main value set, or parts of it. E.g. the main value set may allow for both SNOMED CT and LOINC, but the author wishes to provide additional specific documentation about how they are used (differently) |
| maximum | Additional Only |
If
the
main
conformance
binding
has
strength
=
extensible,
then
any
codes
used
to
extend
that
value
set
SHALL
come
from
this
specified
"maximum
value
set".
Note
that
this
additional
binding
replaces
the
extension
http://hl7.org/fhir/StructureDefinition/elementdefinition-maxValueSet
extension
which
is
no
longer
defined
in
FHIR
Release
5+
This
is
deprecated
-
it
is
equivalent
to
required
|
| minimum | Additional Only |
Define
a
minimum
set
of
codes
that
all
conformant
applications
are
required
to
accept
as
valid
values.
This
is
an
obligation
for
implementing
applications,
and
is
typically
associated
with
additional
obligations
expressing
just
what
the
application
should
do
with
the
codes.
Note
that
this
additional
binding
replaces
the
extension
http://hl7.org/fhir/StructureDefinition/elementdefinition-minValueSet
extension
which
is
no
longer
defined
in
FHIR
Release
5
|
| candidate | Additional Only |
A
value
set
that
is
a
candidate
to
substitute
for
the
overall
conformance
value
set
in
some
situations;
usually
these
are
defined
in
the
documentation,
or
in
the
usage
element
|
| current | Additional Only | A value set that is required to be used with new records. This would be the main conformance value set except that legacy records exist that don't meet this requirement, and never will. Again, this is an application obligation, not something that can be tested in the resource instances themselves |
| ui | Additional Only | This value set is provided to help with user look up in a given context |
| starter | Additional Only | This value set is a good set of codes to start with when designing your system. These are typically the important or commonly used codes. This is useful thing to provide when the conformance value set is very large, or infinite because of a grammar. Many systems can't implement these so a starter set can help them get going |
Notes:
Irrespective of the binding strength, when a StructureDefinition is used to describe local usage, it can bind the element to a different value set in order to be much more precise about exactly which coded values can be used for these elements, and/or increase the strength of the binding. There are different rules for this, depending on the binding strength, as discussed below. Generally it is expected that jurisdictions, projects and vendors will work together to choose actual working value sets.
To
be
conformant,
codes
in
this
the
data
element
SHALL
be
from
contain
one
of
the
specified
values
in
the
expansion
of
the
bound
value
set.
In
If
the
standard,
this
binding
strength
is
required,
the
data
element
SHALL
contain
one
of
the
values
in
the
bound
value
set.
Required
binding
strength
is
generally
used
for
elements
where
the
value
needs
to
be
strictly
controlled
so
that
everyone
the
element
can
interpret
it
be
interpreted
with
confidence.
Generally,
this
is
Required
binding
strength
SHALL
be
used
for
elements
with
type
code
:
(unless
the
element
is
bound
to
a
value
set
that
contains
has
a
list
of
distinct
codes
context-free
(i.e.,
no
binding.additional.usage
present)
additional
binding
with
purpose
=
maximum
,
a
specified
system
(and
version,
where
required)
the
element
combination
which
is
bound
strongly
discouraged
as
of
R6).
Exceptions
to
some
external
standard
that
defines
this
rule
need
to
be
approved
by
the
set
of
valid
codes
FHIR-I
work
group
which
will
document
the
patterns
that
can
be
used
(typical
examples
are
Mime
Types
,
Language
Codes
,
UCUM
,
etc.)
qualify
as
exceptions.
The
other
place
where
this
In
the
base
FHIR
specification,
required
binding
strength
is
typically
only
used
is
with
the
'code'
datatype.
In
profiles,
it
may
be
used
more
broadly
when
profiling
resources
,
and
there
is
agreement
within
a
particular
context
of
use
that
a
particular
specified
set
of
codes
are
the
only
ones
that
can
be
used.
In
these
cases,
the
data
type
SHALL
contain
one
of
the
values
in
the
value
set.
The
following
rules
apply
when
required
bindings
are
used
with
the
CodeableConcept
data
type:
datatype:
text
can
be
provided
as
well,
and
is
always
recommended,
but
is
not
an
acceptable
substitute
for
the
required
code
If a required binding is applied to an element with maximum cardinality > 1, the binding applies to all the elements.
Note:
when
a
binding
is
applied
to
a
CodeableReference
,
these
rules
also
apply
to
its
concept
property.
The
following
rules
apply
when
required
bindings
are
used
with
the
code
data
type:
datatype
outside
of
a
Coding
:
,
Language
Codes
,
UCUM
,
etc.)
When
an
element
is
bound
to
a
required
value
set,
derived
profiles
may
state
rules
on
which
codes
can
be
used,
including
removing
codes
from
allowed
use,
but
cannot
select
new
or
specify
additional
codes
for
these
elements.
For examples of Required bindings, see Terminology Binding Examples .
To
be
conformant,
codes
in
this
the
data
element
SHALL
be
from
contain
one
of
the
specified
values
in
the
expansion
of
the
bound
value
set
if
any
of
the
codes
within
the
value
set
can
apply
to
the
concept
being
communicated.
If
Extensible bindings are used when there is consensus at the specification or profiling level about the coded values that should be used, but it is impossible to create a bounded list of codes that are known to cover all use cases, including ones that are yet to arise.
Note
that
it
is
the
value
set
does
binding
that
is
extensible,
not
cover
the
value
set
itself.
In
the
interests
of
brevity
and
clarity,
please
consider
all
references
to
value
set
in
the
text
below
to
refer
to
an
evaluation
of
the
content
logical
definition
(CLD)
of
the
extensibly-bound
value
set
unless
the
reference
is
explicitly
noted
to
refer
to
a
value
set
definition.
If
the
value
set
can
be
expanded,
then
a
proper
expansion
is
equivalent
to
the
evaluation
of
the
CLD.
If
there
is
no
applicable
concept
in
the
value
set
(based
on
human
review),
an
alternate
system.code
concept
(either
system
/
code
pair,
system
/
version
/
code
triplet,
or
text
)
may
be
used
instead.
The
alternate
concept
can
have
any
level
of
specificity
in
an
is-a
hierarchy
(see
Condition
instance
#2
).
For
clarity,
this
table
summarizes
the
future.
rules
around
extensibility
for
each
bindable
data
type:
| CodeableConcept |
|
| Coding |
|
| Quantity |
|
| uri, string |
|
| code |
|
The
same
rules
apply
for
the
concept
property
of
a
CodeableReference
.
When
If
an
element
extensible
binding
is
extensibly
bound
applied
to
value
set,
an
element
with
maximum
cardinality
>
1,
the
binding
applies
to
all
the
element
repetitions.
For
an
extensibly-bound
element,
derived
profiles
may
state
rules
on
which
codes
can
be
used,
but
cannot
select
new
or
additional
codes
for
these
elements
unless
no
codes
with
appropriate
meanings
are
found
in
the
base
extensibly-bound
value
set.
set
in
the
parent
profile.
You
can
only
constrain,
not
relax.
Note that if the valueset-reference extension is being used and the code in the element instance is from outside the extensibly-bound value set, the extension must reference a different value set definition that the code was chosen from (or if no other value set reference is available the extension cannot be used in that instance).
See examples to help explain the difficult but important subject of Extensible bindings.
Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant.
If
the
data
type
is
CodeableConcept
,
then
one
of
the
coding
values
SHOULD
be
from
the
specified
value
set,
but
another
code
and/or
text
can
be
used
in
its
place.
Preferred
bindings
are
used
when
there
is
consensus
at
the
specification
level
about
the
coded
values
that
are
the
best
to
be
used,
but
there
is
recognition
that
some
implementation
contexts
are
unable
to
use
the
recommended
codes
for
a
variety
of
reasons.
Applications
should
consider
adopting
the
preferred
value
set
wherever
possible,
as
these
preferred
value
sets
are
the
most
likely
to
server
serve
interoperability
purposes
in
the
future.
For
these
bindings:
For examples of Preferred bindings, see Terminology Binding Examples .
When
an
element
is
bound
to
a
preferred
value
set,
derived
profiles
may
MAY
bind
the
element
to
any
value
set
they
choose.
Instances are not expected or even encouraged to draw from the specified value set. The value set merely provides examples of the types of concepts intended to be included.
Example bindings are used when an element has a very broad meaning (such as List .code), or there is no consensus over the correct codes to be used. For these bindings:
Some other coded value MAY be used, or (for a CodeableConcept), a text alternative MAY be provided. Example value sets are provided to assist implementers to understand the correct use of an element. Value sets based on code systems such as SNOMED CT that have restrictive license terms will only be used as example bindings in the base FHIR specification, though implementation guides for particular jurisdictions may adopt value sets that require licenses. In addition, well-specified realm-specific ValueSets may also be used as example bindings in the base specification.
For examples of Example bindings, see Terminology Binding Examples .
When an element is bound to an example value set, derived profiles may bind the element to any value set they choose.
A
binding
strength
of
'required'
or
'extensible'
does
not
indicate
that
ALL
of
the
codes
in
the
bound
value
set
will
be
supported.
It
constrains
the
set
of
codes
that
are
allowed
to
be
shared.
If
systems
flag
an
element
as
mustSupport
,
an
additional
binding
of
purpose
minimum
SHOULD
be
used
to
identify
a
specific
subset
(possibly
the
full
set)
of
the
bound
codes
that
must
be
supported
by
implementers.
If no MIN value set is specified, then there is no guidance for implementers regarding which code(s) must be supported. However, at least one of the codes MUST be supported.
Systems with legacy or external data that was constructed without an awareness of the terminology requirements asserted in a binding may have trouble complying with the expectations of the binding. Both 'required' and 'extensible' bindings impose an expectation of systems to map their existing data to the value set. For 'required' bindings, if no mapping is possible, the element can't be sent (not even with an extension). If the element and its ancestor elements all have a 'min' cardinality of 1 or more, then the system cannot produce a conformant instance. For extensible bindings, if a mapping has been tried and there is no corresponding concept, then the legacy data may be freely sent. However, this still imposes the expectation of performing a mapping, and this might not be possible if new externally sourced data with arbitrary codes is being regularly received. If no mapping has been performed, then the element would need to be omitted, or the instance would not be able to claim conformance to the specification that imposed the binding.
R5 introduces some new binding capabilities through the Additional Binding extension. This extension allows specifications to specify more refined types of bindings. In particular, the 'current' binding allows a specification to differentiate between terminology requirements that apply to data captured by a system from the time it complies with a specification as opposed to historical or externally sourced data. Implementers that find the bindings asserted by specifications are too onerous for external or historical data, but are reasonable for 'current' data, might encourage specification authors to consider making use of this Additional Binding extension to better reflect the expectations of systems.
Servers may support a variety of implementation guides. There is no guarantee that all data they have available on their FHIR interfaces will necessarily comply with all implementation guides. On the other hand, some clients might not be able to safely consume data that does not comply with a given IG. In environments where there will be a need to expose a mixture of IG-conformant and non-IG conformant data, but some consumers will depend on data being conformant to safely consume, then Resource.meta.profile can be used to explicitly flag the instances that conform. Clients can then filter using the _profile search parameter to ensure they only receive data they can safely handle - with the known cost that they won't necessarily have access to all data that exists.
minimum
may
be
FHIR has defined a Terminology Service specification which sets requirements for systems that support the use of codes, value sets and code systems.
FHIR
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Thurs,
Oct
24,
2019
11:53+1100.
QA
Page
Sun,
Nov
9,
2025
02:09+0000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
DSTU2
R4
|
Compare
to
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change