Release
4
5
Terminology
This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
(v5.0.0:
R5
-
Mixed
Normative
and
STU
)
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
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
|
Work
Group
|
Maturity Level : Normative | Standards Status : Normative |
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
elements
values
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
data
type
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
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)
|
| CodeableReference | A type that can have either a reference to another resource, or a to a concept using a 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
data
types
datatypes
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.
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
an
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 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
accidentally
be
used
by
another
implementer
for
a
different
purpose
-
or
a
very
similar
purpose
with
create
a
different
scope.
See
Registering
Code
Systems
for
further
advice.
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
data
types
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}"
}
Note
that
there
is
no
No
display
defined
for
SNOMED
CT
expressions.
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:
| 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 .
Additional
Bindings
and
the
element
ElementDefinition.binding.additional
is
considered
Trial
Use
for
FHIR
Release
5.
In addition, elements may have additional bindings. These additional bindings do not replace the main binding, but provide additional information about the use of codes in the element. Additional bindings have the following properties:
| purpose |
The
use
of
this
additional
binding:
|
| valueSet | A canonical URL that refers to the value set for the additional binding |
| documentation | Markdown that describes the use of this value set in this element, given the purpose and usage |
| shortDoco | A short plain text string, typically just a sentence, that summarizes the documentation, for use in the tabular formal of a profile |
| usage | A set of qualifiers that restrict the scope of use for the additional binding. Typically, the binding is restricted by jurisdiction/realm, but it may also be restricted to particular clinical or workflow contexts. This specification does not detail exactly how implementations determine when usage criteria apply, so this is a subject that should be addressed in implementation guides when usages are specified |
| any |
If
an
element
repeats,
the
main
binding
applies
to
all
the
repeats
equally.
By
default,
the
same
is
true
for
an
additional
binding,
but
setting
any
=
true
means
that
the
additional
binding
can
be
met
by
any
one
of
the
repeats.
This
allows
multiple
bindings
for
different
repeats
without
the
overhead
of
slicing.
Setting
any
to
true
only
really
makes
sense
for
additional
bindings
with
purpose
=
conformance
|
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
ElementDefinition.binding.additional.valueSet
|
| 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
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 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
data
types
datatypes
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
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:
| 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
data
type
datatype
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,
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
a
specified
system
(and
version,
where
required)
the
element
is
bound
purpose
=
maximum.
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
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
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
specify
new
or
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.
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
).
For
clarity,
this
table
summarizes
the
closest
available
match
rules
around
extensibility
for
each
bindable
data
type:
| CodeableConcept |
|
| Coding |
|
| Quantity |
|
| uri, string |
|
|
code
|
|
The
same
rules
apply
for
the
specified
value
set
if
concept
property
of
a
code
applies,
but
if
no
suitable
code
exists
in
the
value
set,
an
alternate
code
may
be
provided
in
its
place.
CodeableReference
.
If
an
extensible
binding
is
applied
to
an
element
with
maximum
cardinality
>
1,
the
binding
applies
to
all
the
elements.
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.
element
repetitions.
When
For
an
element
is
extensibly-bound
to
a
value
set,
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
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 , the minimumValueSet extension 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.
When binding a ValueSet to an element, values may be limited by declaring a maximum value set in the additional bindings .
A binding may be further constrained to declare a value set for use when the binding strength is 'extensible' or 'preferred'. This value set is the value set from which additional codes can be taken from. This defines a 'required' binding over the top of the 'extensible' binding.
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.
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
4
(Technical
Correction
#1)
(v4.0.1)
R5
hl7.fhir.core#5.0.0
generated
on
Fri,
Nov
1,
2019
09:37+1100.
QA
Page
Sun,
Mar
26,
2023
15:26+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
R3
R4
|
Compare
to
R4B
|
|
Propose
a
change