Terminology
This
page
is
part
of
the
Continuous
Integration
Build
of
FHIR
Specification
(v5.0.0:
R5
-
STU
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
(will
be
available
incorrect/inconsistent
at
this
URL).
For
a
full
list
of
available
versions,
see
times).
See
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R4
R3
R2
|
Responsible
Owner:
Terminology
Infrastructure
Work
Group
|
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
V2
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 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 several different datatypes is used: | |
| 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 datatype that has a code and a system element that identifies where the definition of the code comes from |
| 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 | 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
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
of
the
concept
is
necessary
for
interoperable
data
exchange.
Each
code
system
is
assigned
a
uri.
The
combination
of
the
code
system
identifier
(uri)
and
the
concept
identifier
(e.g.
(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
the
mixed
list
example
from
the
previous
paragraph,
there
are
two
code
systems:
LOINC
(http://loinc.org)
and
a
local
one
with
the
uri:
http://example.com/codesystems/additional-test-codes.
The
value
set
definition
includes
concept
identifier
(codes)
from
each
of
the
two
code
systems.
ValueSet.url
(e.g.
(e.g.,
"http://example.com/fhir/ValueSet/test-codes")
is
the
canonical
identifier
for
the
value
set.
The
value
set
uri
is
not
the
same
as
the
code
system
uri.
Concepts
are
always
identified
by
code
and
system
,
except
for
the
simple
datatype
code
where
the
code
system
is
fixed
in
a
specification
(e.g.
(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)
-
If
a
code
system
is
listed
here,
the
canonical
CodeSystem
URL
SHALL
be
used.
,
and
the
code
system
is
external
to
HL7,
the
CodeSystem
identifier
authorized
by
HTA
SHALL
be
used.
to
determine
if
a
request
is
in
process
to
obtain
an
identifier.
communicating
the
temporary
identifier
you
assigned
,
and
the
code
system
is
internal
to
HL7,
and
is
expected
to
be
used
in
a
production
system
to
move
the
CodeSystem
content
to
THO
,
and
the
code
system
is
intended
to
never
be
used
in
a
production
system,
and
will
be
used
to
create
a
value
set
bound
with
Example
binding
strength
In the unusual situation where a code system is not resolved by this list, create a 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, 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 set for the binding. Usually, this is a direct reference to a ValueSet resource, but can be a more indirect reference, where the value set is inferred |
A
binding
Some
bindings
also
have
a
name
that
is
always
represented
using
an
ElementDefinition.binding
.
Additional
Bindings
and
assigned
for
the
element
ElementDefinition.binding.additional
is
considered
Trial
Use
convenience
of
implementers
-
used
for
FHIR
Release
5.
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.
bindings
.
These
additional
bindings
do
not
replace
the
main
binding,
binding
(the
main
binding
always
applies),
but
provide
additional
information
and/or
rules
about
the
use
of
codes
in
the
element.
element
sometimes
in
particular
contexts
of
use.
Additional
bindings
have
the
following
properties:
| purpose |
The
use
of
this
additional
|
| valueSet |
|
| 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
|
It's possible for there to be multiple applicable required bindings to non-overlapping value sets If the data type is CodeableConcept or CodeableReference, then that would mean that multiple Codings are needed to satisfy the bindings. For other data types, this would be an 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 .binding.valueSet |
Used
to
bind
a
defined
element
to
a
value
set,
and
also
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.
(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
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 .
Almost all the elements that have a coded 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 set. |
| 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, the data element SHALL contain one of the values in the expansion of the bound value set.
If the binding strength is required, the data element SHALL contain one of the values in the bound value set.
Required
binding
strength
is
used
for
elements
where
the
value
needs
to
be
strictly
controlled
so
the
element
can
be
interpreted
with
confidence.
Required
binding
strength
SHALL
be
used
for
elements
with
type
code
unless
(unless
the
element
has
a
context-free
(i.e.
(i.e.,
no
binding.additional.usage
present)
additional
binding
with
purpose
=
maximum.
maximum
,
a
combination
which
is
strongly
discouraged
as
of
R6).
Exceptions
to
this
rule
need
to
be
approved
by
the
FHIR-I
work
group
which
will
document
the
patterns
that
qualify
as
exceptions.
In the base FHIR specification, required binding strength is typically only used with the 'code' datatype. In profiles, it may be used more broadly when there is agreement within a context of use that a specified set of codes are the only ones that can be used.
The following rules apply when required bindings are used with the CodeableConcept 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 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 additional codes for these elements.
For examples of Required bindings, see Terminology Binding Examples .
To be conformant, the data element SHALL contain one of the 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 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
.
If an extensible binding is applied to 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 extensibly-bound value 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.
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 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
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
used
to
define
the
minimum
value
set
that
is
required
for
conformance.
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
R6
hl7.fhir.core#6.0.0-ballot3
generated
on
Sun,
Mar
26,
2023
15:26+1100.
Thu,
Nov
13,
2025
03:09+0000.
Links:
Search
|
Version
History
|
Contents
|
Glossary
|
QA
|
Compare
to
R4
|
Compare
to
R4B
R5
|
Compare
to
Last
Ballot
|
|
Propose
a
change