Release
5
4
Terminology
This
page
is
part
of
the
FHIR
Specification
(v5.0.0:
R5
(v4.0.1:
R4
-
Mixed
Normative
and
STU
).
This
is
the
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
The
current
published
version.
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
|
Work
Group
|
Maturity Level : Normative | Standards Status : Normative |
|
This
page
has
been
approved
as
part
of
an
ANSI
standard.
See
the
Infrastructure
Package
for
further
details.
|
Many elements in the FHIR resources have a coded value : some fixed string (a sequence of characters) assigned elsewhere that identifies some defined "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". 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"
and
"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
elements
is
using
the
following
four
elements:
| system | A URI that identifies the system (see below ) |
| version |
|
| code |
A
string
|
| display | A description of the concept as defined by the code system |
The
Coding
datatype
data
type
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
several
different
|
|
| 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)
|
|
In
addition,
the
following
|
|
| Quantity | The instance has system and code elements for carrying a code for the type of unit, and these can be bound to a value set |
| 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"
.
Anywhere
these
datatypes
data
types
are
used,
the
specification
"binds">
"binds"
a
value
set
to
the
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.
The
code
system
identifier
For
data
exchange,
on
the
other
hand,
explicitly
tracking
the
source
of
the
concept
code
is
necessary
for
interoperable
data
exchange.
Each
both
important
and
necessary.
In
order
to
do
this,
each
code
system
that
defines
codes
is
assigned
a
uri.
The
combination
of
the
code
system
identifier
(uri)
and
the
concept
identifier
(e.g.
code)
is
unique.
Note
URL
that
code
system
version
may
be
necessary
to
achieve
uniqueness
when
identifies
it,
and
all
the
code
system
does
not
follow
concept
permanence
rules.
In
codes
it
defines
are
actually
a
pair
("Code
Pair":
a
name
with
a
namespace).
So
in
the
case
of
the
this
mixed
list
example
from
the
previous
paragraph,
there
are
two
code
systems:
LOINC
(http://loinc.org)
and
a
local
one
with
(let's
say
it
has
been
given
the
uri:
http://example.com/codesystems/additional-test-codes.
URL:
http://example.com/codesystems/additional-test-codes).
The
application
table
is
a
single
value
set
definition
(a
set
of
Code
Pairs)
that
includes
concept
identifier
(codes)
codes
from
each
of
the
those
two
code
systems.
ValueSet.url
(e.g.
"http://example.com/fhir/ValueSet/test-codes")
is
the
canonical
identifier
for
the
value
set.
namespaces.
The
value
set
uri
itself
is
not
given
its
own
URL
as
an
identifier
(e.g.
"http://example.com/fhir/ValueSet/test-codes").
This
identifies
the
same
set
of
Code
Pairs,
but
is
never
used
as
the
namespace
in
an
actual
code
system
uri.
Concepts
pair,
or
in
an
instance.
In
FHIR,
Code
Pairs
are
always
identified
by
code
represented
as
"code"
and
system
,
"system",
except
for
the
simple
datatype
data
type
code
where
the
code
namespace
(e.g.
the
system
element/property)
is
fixed
in
a
specification
(e.g.
core
specification,
implementation
guide,
profile)
the
schema
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 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:
In
the
unusual
situation
where
If
a
code
system
is
not
resolved
by
this
list,
create
and
there
is
no
publisher
to
consult,
implementers
must
choose
a
temporary
identifier
following
this
pattern:
terminology.hl7.org/temporary/CodeSystem/xxxx.
Contact
the
HL7
Vocabulary
co-chairs.
URI
to
use.
The
priority
should
be
to
choose
a
unique
value
that
won't
accidentally
be
used
by
another
implementer
for
a
different
purpose
-
or
a
very
similar
purpose
with
a
different
scope.
See
Registering
Code
Systems
for
further
advice.
For publishers of code systems, the following considerations should be kept in mind when defining the correct URI to use:
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
data
types
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
Note
that
there
is
provided
in
this
example.
See
the
discussion
here:
https://confluence.ihtsdotools.org/x/UwbJAQ
no
display
defined
for
SNOMED
CT
expressions.
When
an
element
is
bound
to
a
value
set,
it
has
a
the
binding
that
has
these
properties:
| Name | A descriptive name used when presenting information about the binding |
| Strength | How the binding should be understood - see below |
| Reference | A URL that defines the value set. Usually, this is a direct reference to a ValueSet resource, but can be a more indirect reference, where the value set is inferred |
| Description | 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 |
A binding is always represented using an ElementDefinition.binding .
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 .binding.valueSet |
Used
to
bind
a
defined
element
to
a
value
|
| ConceptMap .source[x] and .target[x] | Used to indicate the scope of the mapping in the Concept Map - from one value set to another |
| Questionnaire .item.answerValueSet | Indicates that answers to a set of questions come from a value set |
| ValueSet .compose.include.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 coded value was chosen from the specified value set |
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"/>
</options>
</question>
....
</Questionnaire>
This specifies that the values for a 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 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>
...
<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
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.
urn:uuid:c0e0d027-1250-4278-8f44-33a49dc67916).
These
value
sets
can
never
be
accessed
directly,
and
must
come
from
a
terminology
server.
Note
that
HL7
Terminology
this
specification
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 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 with a '|' like this:
<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 .
Note
that
as
a
matter
of
ongoing
development,
a
few
elements
that
have
coded
datatypes
data
types
are
not
bound
to
any
value
set
at
all.
Bindings
are
to
be
provided
for
these
elements.
Almost
all
the
elements
that
have
a
coded
datatype
data
type
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:
| required | To be conformant, the concept in this element SHALL be from the specified value set. |
| extensible | 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 | Instances are encouraged to draw from the specified codes for interoperability purposes but are not required to do so to be considered conformant. |
| example | 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. |
The
precise
conformance
criteria
for
'required'
and
'extensible'
binding
strengths
vary
by
the
datatype
data
type
to
which
they
are
applied,
as
described
in
the
paragraphs
below.
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,
the
data
codes
in
this
element
SHALL
contain
one
of
the
values
in
the
expansion
of
be
from
the
bound
specified
value
set.
If
the
binding
strength
is
required,
the
data
element
SHALL
contain
one
of
the
values
in
In
the
bound
value
set.
Required
binding
strength
standard,
this
is
generally
used
for
elements
where
the
value
needs
to
be
strictly
controlled
so
the
element
that
everyone
can
be
interpreted
interpret
it
with
confidence.
Required
binding
strength
SHALL
be
Generally,
this
is
used
for
elements
with
type
code
unless
:
,
Language
Codes
,
UCUM
,
etc.)
In
the
base
FHIR
specification,
required
binding
strength
The
other
place
where
this
is
typically
only
used
with
the
'code'
datatype.
In
profiles,
it
may
be
used
more
broadly
is
when
profiling
resources
,
and
there
is
agreement
within
a
context
of
use
that
a
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
datatype:
data
type:
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
datatype
outside
of
a
Coding
:
data
type:
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 specify new or additional codes for these elements.
To
be
conformant,
the
data
codes
in
this
element
SHALL
contain
one
of
the
values
in
the
expansion
of
be
from
the
bound
specified
value
set
if
any
of
the
codes
within
the
value
set
can
apply
to
the
concept
being
communicated.
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
binding
that
is
extensible,
not
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
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
).
If
there
is
not
a
concept
that
matches
the
meaning
in
the
extensibly-bound
value
set
and
there
is
at
least
one
applicable
concept
in
the
extensibly-bound
value
set
with
a
meaning
which
includes
but
is
more
general
than
the
meaning
that
is
intended
to
be
represented
by
the
element
in
the
resource
instance,
then:
The
then
the
code
that
is
used
in
the
instance
SHALL
be
taken
from
one
of
the
applicable
concepts
from
the
value
set
and
SHOULD
should
be
the
closest
more
general
available
match
for
the
intended
element
instance
meaning.
If
the
datatype
is
Coding
then
the
only
concept
that
can
be
sent
is
the
applicable
concept
from
the
value
set.
If
the
datatype
is
CodeableConcept,
meaning
(i.e.
neither
more
general
or
more
specific).
However,
a
more
specific
code
that
is
not
in
the
extensibly
bound
value
set
that
more
completely
represents
the
intended
meaning
MAY
may
also
be
included
in
the
instance
as
an
additional
Coding,
Coding
if
the
data
type
is
CodeableConcept,
but
it
cannot
be
used
instead
of
the
code
from
the
value
set
expansion.
set.
This
helps
ensure
that
systems
know
which
codes
they
should
expect
to
receive
and
build
logic
for,
for
and
it
facilitates
interoperability.
Only
if
the
above
two
cases
do
not
apply
then:
Alternate
code(s)
from
outside
When
a
code
for
an
applicable
concept
in
the
extensibly-bound
value
set
may
be
is
used
instead.
Text
in
CodeableConcept.text
MAY
it
should
always
be
sent.
For
clarity,
this
table
summarizes
the
rules
around
extensibility
closest
available
match
for
each
bindable
data
type:
CodeableConcept
a
Coding
drawn
from
the
ValueSet
is
present,
intended
element
instance
meaning,
regardless
of
hierarchical
(i.e.
"is-a")
relationships
in
the
underlying
code
system(s)
or
hierarchical
"level"
of
the
concept.
However,
as
noted
above,
a
Coding
that
represents
code
for
a
concept
inexpressable
by
the
ValueSet
is
present,
or
CodeableConcept.text
present
with
no
Codings,
or
any
extension
is
present
that
conveys
an
alternative
concept
inexpressable
by
is
outside
of
the
ValueSet
Coding
extensibly-bound
value
set
with
a
Coding
drawn
from
the
ValueSet
meaning
which
is
present,
"covered
by"
(i.e.
is
more
specific
than
or
a
Coding
that
represents
has
an
"is-a"
relationship
to)
a
concept
inexpressable
by
the
ValueSet
is
present,
or
any
extension
that
is
present
included
in
the
value
set
cannot
be
used.
In
that
conveys
an
alternative
case
a
code
for
a
concept
inexpressable
by
that
is
in
the
ValueSet
Quantity
Quantity.code
and
Quantity.system
are
from
extensibly-bound
value
set
SHALL
be
used
in
the
ValueSet,
or
Quantity.code
element
instance
and
Quantity.system
represents
a
it
should
be
the
code
for
the
concept
inexpressable
by
that
most
closely
matches
the
ValueSet
is
present,
or
any
Quantity.extension
intended
element
instance
meaning.
If
the
data
type
is
present
that
conveys
an
alternate
unit
concept
inexpressable
by
CodeableConcept
,
then,
as
noted
above,
one
of
the
ValueSet
uri,
string
a
value
drawn
Coding
values
SHALL
be
from
the
ValueSet
is
present,
or
A
specified
extensibly-bound
value
expressing
set
if
a
concept
inexpressable
by
the
ValueSet
is
present
any
extension
is
present
code
in
that
conveys
an
alternative
concept
inexpressable
by
the
ValueSet
(e.g.,
value
set
applies,
but
if
a
datatype
other
than
URI
needs
to
be
conveyed)
no
applicable
code
a
exists
in
the
value
drawn
set
alternate
code(s)
from
outside
the
ValueSet
is
present,
or
any
extension
value
set
may
be
used
instead.
If
no
codes,
including
local
codes,
are
available,
then
text
alone
(in
CodeableConcept.text)
may
be
used.
If
the
data
type
is
present
that
conveys
an
alternative
concept
inexpressable
by
Coding
,
then
the
ValueSet
The
same
rules
apply
for
code/system
SHALL
be
from
the
concept
property
of
specified
value
set
if
a
CodeableReference
.
code
applies,
but
if
no
suitable
code
exists
in
the
value
set,
an
alternate
code
may
be
provided
in
its
place.
If
an
extensible
binding
is
applied
to
an
element
with
maximum
cardinality
>
1,
the
binding
applies
to
all
the
element
repetitions.
elements.
For
Identified
gaps
in
value
sets
should
be
submitted
to
the
organization
administering
the
value
set
in
order
to
improve
interoperability
in
the
future.
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.
When
an
element
is
extensibly-bound
element,
to
a
value
set,
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
extensibly-bound
base
value
set
in
the
parent
profile.
You
can
only
constrain,
not
relax.
set.
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
serve
interoperability
purposes
in
the
future.
For
these
bindings:
code
:
Preferred
binding
SHALL
NOT
be
used
with
the
code
datatype
because
the
meaning
is
not
predictable
due
to
the
inability
to
specify
the
system.url
for
a
code
that
is
not
included
in
the
bound
ValueSet
Coding
:
The
value
SHOULD
be
from
the
specified
value
set,
but
another
code
and/or
text
can
be
used
in
its
place
CodeableConcept
:
One
of
the
Coding
values
SHOULD
be
from
the
specified
value
set,
but
another
code
and/or
text
can
be
used
in
its
place
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.
See examples of how Preferred bindings work.
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.
In
a
few
special
cases,
humans
customarily
use
codes
directly
for
elements
that
have
type
"string".
A
typical
case
is
codes
for
states,
and
there
are
several
places
where
a
URI
must
come
from
a
set
of
controlled
values.
An
element
of
type
string
or
uri
can
also
be
used
bound
to
define
the
minimum
a
value
set
that
set.
When
a
string
or
URI
is
required
for
conformance.
bound
to
a
value
set,
the
value
property
SHALL
contain
the
code
specified
by
the
value
set,
and
the
system
and
display
values
are
ignored.
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
R5
hl7.fhir.core#5.0.0
Release
4
(Technical
Correction
#1)
(v4.0.1)
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Fri,
Nov
1,
2019
09:37+1100.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Glossary
|
QA
|
Compare
to
R4
Credits
|
Compare
to
R4B
R3
|
|
Propose
a
change