Implementation
Support
This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions 
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
|
|
|
|
HL7 v3
was intended to be the next generation of HL7's messaging standards. It introduced a common Reference Information Model (RIM), data type model and set of vocabulary as well as a formal standards development methodology. In addition, it introduced the use of "documents" as an alternative architecture to messaging for sharing healthcare information (see
the CDA comparison
was
intended
to
be
the
next
generation
of
HL7's
messaging
standards.
It
introduced
a
common
Reference
Information
Model
(RIM),
data
type
model
and
set
of
vocabulary
as
well
as
a
formal
standards
development
methodology.
In
addition,
it
introduced
the
use
of
"documents"
as
an
alternative
architecture
to
messaging
for
sharing
healthcare
information
(see
the
CDA
comparison
).
While
nominally
covering
both,
the
term
"v3"
is
typically
used
to
refer
to
"v3
messaging".
The
data
types
used
as
a
basis
for
v3
have
also
been
adopted
by
ISO
as
ISO
21090.
The
HL7
RIM
has
also
been
adopted
as
an
ISO
standard.
v3
messaging
has
been
adopted
by
a
number
of
large
projects,
particularly
in
the
electronic
health
record
area,
though
it
has
not
achieved
the
market
penetration
of
HL7
v2
). While nominally covering both, the term "v3" is typically used to refer to "v3 messaging". The data types used as a basis for v3 have also been adopted by ISO as ISO 21090. The HL7 RIM has also been adopted as an ISO standard.
v3 messaging has been adopted by a number of large projects, particularly in the electronic health record area, though it has not achieved the market penetration of
HL7 v2
.
The
HL7
RIM
and
the
ISO
21090
data
types
have
also
been
used
by
other
SDOs
and
projects
that
have
not
leveraged
the
full
HL7
v3
methodology.
Most
of
the
comments
and
guidance
provided
here
will
apply
to
those
solutions
as
well.
. The HL7 RIM and the ISO 21090 data types have also been used by other SDOs and projects that have not leveraged the full HL7 v3 methodology. Most of the comments and guidance provided here will apply to those solutions as well.
Reference model:
The use of the HL7 RIM is a core aspect of the HL7 v3 methodology and it is front and center in the specification and the wire format. All data elements in HL7 v3 instances are derived from either the RIM or the ISO data types. In FHIR, this is true of most resources and data type elements, but not all. Some resources (
StructureDefinition
,
,
Conformance
,
,
ValueSet
,
etc.)
deal
with
content
that
is
outside
the
RIM's
scope.
And
in
a
few
circumstances,
adjustments
have
been
made
in
the
FHIR
data
types
that
are
not
yet
supported
in
the
HL7
v3
data
types
model.
The
expectation
is
that
these
changes
will
be
supported
in
the
next
version
of
the
v3
data
types
model.
The
main
difference
is
that
the
wire
format
of
FHIR
is
not
driven
by
the
RIM
mappings.
This
results
in
considerably
more
concise
and
intuitive
instances.
It
is
possible
to
implement
FHIR
with
absolutely
no
knowledge
of
the
HL7
RIM.
, etc.) deal with content that is outside the RIM's scope. And in a few circumstances, adjustments have been made in the FHIR data types that are not yet supported in the HL7 v3 data types model. The expectation is that these changes will be supported in the next version of the v3 data types model. The main difference is that the wire format of FHIR is not driven by the RIM mappings. This results in considerably more concise and intuitive instances. It is possible to implement FHIR with absolutely no knowledge of the HL7 RIM.
Codes:
v3
places
considerable
reliance
on
coded
attributes
to
convey
the
meaning
of
instances.
Examples
include
v3 places considerable reliance on coded attributes to convey the meaning of instances. Examples include
classCode
,
,
moodCode
,
,
determinerCode
,
etc.
The
allowed
codes
for
these
attributes
are
strictly
controlled
by
HL7.
FHIR
also
has
attributes
that
are
limited
to
codes
defined
in
the
FHIR
specification
-
those
using
the
, etc. The allowed codes for these attributes are strictly controlled by HL7. FHIR also has attributes that are limited to codes defined in the FHIR specification - those using the
code
data
type.
However,
these
are
generally
limited
to
attributes
with
business
meaning
-
status,
contact
types,
etc.
Both
FHIR
and
v3
make
use
of
value
sets
to
define
the
sets
of
codes
that
can
be
used
for
attributes
in
particular
contexts.
However,
in
FHIR,
a
data type. However, these are generally limited to attributes with business meaning - status, contact types, etc.
Both FHIR and v3 make use of value sets to define the sets of codes that can be used for attributes in particular contexts. However, in FHIR, a
ValueSet
is
just
another
type
of
resource,
meaning
it
can
be
sent
as
part
of
an
instance
just
like
any
other
piece
of
data.
(The
same
is
true
of
is just another type of resource, meaning it can be sent as part of an instance just like any other piece of data. (The same is true of
StructureDefinition
,
,
Conformance
and
other
meta-level
resources.)
Granularity
&
referencing:
HL7
v3
models
are
broken
into
3
main
types
-
wrappers,
payloads
and
Common
Message
Element
Types
(CMETs).
These
are
combined
into
interactions
to
define
the
set
of
content
that
can
be
sent
over
the
wire
at
one
time.
In
some
cases,
the
granularity
of
each
of
these
models
will
exactly
align
with
the
granularity
of
FHIR
resources,
but
not
always.
v3
models
are
divided
based
on
the
expectation
of
re-use.
FHIR
models
are
divided
based
on
whether
the
objects
they
represent
are
considered
to
be
able
to
"stand
alone".
In
HL7
v3,
numerous
models
can
exist
to
represent
the
same
essential
underlying
healthcare
information
construct.
For
example,
at
the
HL7
International
level,
there
are
10
different
CMETs
for
the
concept
of
"Patient".
In
addition,
some
payload
models
represent
patient
directly
without
using
CMETs.
Further
variation
exists
in
the
v3
models
created
by
HL7
affiliates
and
other
v3
implementers.
Each
of
these
different
CMETs
has
their
own
schema
and
may
use
different
element
names,
different
levels
of
nesting
and
different
constraints.
With
FHIR,
there
is
only
one
and other meta-level resources.)
Granularity & referencing:
HL7 v3 models are broken into 3 main types - wrappers, payloads and Common Message Element Types (CMETs). These are combined into interactions to define the set of content that can be sent over the wire at one time. In some cases, the granularity of each of these models will exactly align with the granularity of FHIR resources, but not always. v3 models are divided based on the expectation of re-use. FHIR models are divided based on whether the objects they represent are considered to be able to "stand alone". In HL7 v3, numerous models can exist to represent the same essential underlying healthcare information construct. For example, at the HL7 International level, there are 10 different CMETs for the concept of "Patient". In addition, some payload models represent patient directly without using CMETs. Further variation exists in the v3 models created by HL7 affiliates and other v3 implementers. Each of these different CMETs has their own schema and may use different element names, different levels of nesting and different constraints. With FHIR, there is only one
Patient
resource.
Many
profiles
can
be
created
on
that
resource,
but
all
of
them
will
use
the
same
schema
and
support
the
same
wire
format.
Design
by
constraint:
The
design
methodology
in
v3
is
one
of
"design
by
constraint".
The
idea
is
that
all
data
needed
for
any
sort
of
healthcare
communication
is
represented
in
the
HL7
RIM.
All
other
data
models
simply
constrain
the
RIM
to
reflect
the
needs
of
particular
domain
spaces.
This
starts
at
the
international
level
with
further
refinement
happening
in
individual
countries,
projects
and
finally
specific
implementations.
As
models
become
closer
to
the
implementer,
they
become
less
abstract.
The
result
is
a
tendency
for
v3
models
to
be
extremely
broad
in
their
coverage
and
capability
and
also
somewhat
abstract.
They
need
to
be
this
way
in
order
to
ensure
that
all
possible
implementations
in
the
space
covered
by
that
model
can
be
properly
constrained.
As
well,
each
model
produces
its
own
schema
and,
in
most
cases,
constrained
schemas
are
not
strictly
wire-compatible
with
the
schemas
of
the
model
being
constrained.
FHIR
takes
a
different
approach.
FHIR
resources
do
not
attempt
to
represent
all
data
elements
that
could
possibly
be
used
in
a
space.
Instead,
only
those
data
elements
that
are
expected
to
be
used
by
"most"
implementations
within
the
scope
of
the
resource
are
considered
part
of
the
core
resource
definition.
(This
is
sometimes
referred
to
as
"The
80%
rule"
-
if
approximately
80%
of
systems
maintaining
the
resource
will
support
the
element,
then
it
is
part
of
core).
All
other
data
elements
are
expected
to
be
handled
using
extensions.
resource. Many profiles can be created on that resource, but all of them will use the same schema and support the same wire format.
Design by constraint: The design methodology in v3 is one of "design by constraint". The idea is that all data needed for any sort of healthcare communication is represented in the HL7 RIM. All other data models simply constrain the RIM to reflect the needs of particular domain spaces. This starts at the international level with further refinement happening in individual countries, projects and finally specific implementations. As models become closer to the implementer, they become less abstract. The result is a tendency for v3 models to be extremely broad in their coverage and capability and also somewhat abstract. They need to be this way in order to ensure that all possible implementations in the space covered by that model can be properly constrained. As well, each model produces its own schema and, in most cases, constrained schemas are not strictly wire-compatible with the schemas of the model being constrained.
FHIR takes a different approach. FHIR resources do not attempt to represent all data elements that could possibly be used in a space. Instead, only those data elements that are expected to be used by "most" implementations within the scope of the resource are considered part of the core resource definition. (This is sometimes referred to as "The 80% rule" - if approximately 80% of systems maintaining the resource will support the element, then it is part of core). All other data elements are expected to be handled using extensions.
Profiles
are
used
both
to
constrain
resources
and
to
define
extensions
appropriate
to
narrower
implementation
spaces.
Wire
format
interoperability
is
retained
across
all
profiles
on
a
given
resource.
Context
conduction:
When
conveying
healthcare
information
between
humans,
much
data
can
be
inferred
from
context.
For
example,
if
a
report
has
an
"author"
noted
on
a
cover
page,
it
is
generally
inferred
that
each
statement
within
the
report
is
authored
by
that
same
person.
This
inference
grows
more
challenging
when
data
needs
to
be
analyzed
by
computers,
whether
for
query,
decision
support
or
other
analysis.
Thus
far,
the
HL7
v3
methodology
has
provided
three
distinct
mechanisms
to
allow
data
models
to
define
how
"context"
should
propagate
through
models,
making
explicit
for
computers
what
humans
would
normally
understand
intuitively.
FHIR
has
chosen
a
different
path.
In
FHIR,
no
context
is
conducted
-
everything
is
explicit.
If
a
report
about
a
patient
contains
100
observations
all
about
that
same
patient,
each
observation
will
include
a
reference
to
the
patient.
However,
this
is
relatively
painless
because
it's
only
a
reference
-
an
id
and
possibly
a
short
display
value.
One
of
the
benefits
of
this
approach
is
that
each
resource
can
be
safely
consumed
and
examined
without
concern
for
the
context
in
which
that
resource
was
communicated.
The
meaning
of
each
resource
instance
is
fully
self-contained.
Null
flavors:
In
healthcare,
it's
quite
common
for
data
to
be
unknown,
unavailable,
have
an
exceptional
value
or
otherwise
fall
outside
the
bounds
of
a
"normal"
value.
To
deal
with
this,
v3
introduced
the
concept
of
"null
flavor"
on
almost
every
attribute
and
data
type
property
in
its
models.
These
coded
null
flavors
could
be
sent
in
place
of
or
in
addition
to
the
data
that
would
typically
be
sent
for
the
attribute,
association
or
data
type
property.
Examples
include
the
ideas
of
"Unknown",
"Not
asked",
"Positive
infinity",
"Trace
amount",
"Masked",
"Other",
etc.
Unless
an
element
was
explicitly
marked
as
"mandatory"
-
meaning
no
null
flavors
were
permitted,
these
null
flavors
could
appear
absolutely
anywhere.
FHIR
approaches
the
problem
differently.
Null
flavors
are
only
introduced
in
the
core
specification
in
those
circumstances
where
it
is
expected
that
most
systems
will
need
them.
Where
needed,
the
flavors
are
constrained
to
those
relevant
to
that
element.
are used both to constrain resources and to define extensions appropriate to narrower implementation spaces. Wire format interoperability is retained across all profiles on a given resource.
Context conduction: When conveying healthcare information between humans, much data can be inferred from context. For example, if a report has an "author" noted on a cover page, it is generally inferred that each statement within the report is authored by that same person. This inference grows more challenging when data needs to be analyzed by computers, whether for query, decision support or other analysis. Thus far, the HL7 v3 methodology has provided three distinct mechanisms to allow data models to define how "context" should propagate through models, making explicit for computers what humans would normally understand intuitively. FHIR has chosen a different path. In FHIR, no context is conducted - everything is explicit. If a report about a patient contains 100 observations all about that same patient, each observation will include a reference to the patient. However, this is relatively painless because it's only a reference - an id and possibly a short display value. One of the benefits of this approach is that each resource can be safely consumed and examined without concern for the context in which that resource was communicated. The meaning of each resource instance is fully self-contained.
Null flavors: In healthcare, it's quite common for data to be unknown, unavailable, have an exceptional value or otherwise fall outside the bounds of a "normal" value. To deal with this, v3 introduced the concept of "null flavor" on almost every attribute and data type property in its models. These coded null flavors could be sent in place of or in addition to the data that would typically be sent for the attribute, association or data type property. Examples include the ideas of "Unknown", "Not asked", "Positive infinity", "Trace amount", "Masked", "Other", etc. Unless an element was explicitly marked as "mandatory" - meaning no null flavors were permitted, these null flavors could appear absolutely anywhere.
FHIR approaches the problem differently. Null flavors are only introduced in the core specification in those circumstances where it is expected that most systems will need them. Where needed, the flavors are constrained to those relevant to that element.
Using RIM mappings: Most resource elements and data type properties include mappings to the RIM. These mappings serve two purposes. They help to define FHIR semantics in terms of HL7's reference models, helping to ensure that the Work Groups defining the data elements have a good and consistent understanding of the meaning of every element. They also provide guidance for implementers of v3 specifications that may be looking to migrate to or map between v3 and FHIR. However, for the latter use it's important to understand some limitations on the RIM mappings. The RIM is a language which allows the same "idea" to be conveyed in a number of different ways with varying granularity and expressiveness. Thus it's entirely possible for a RIM element to map to a core FHIR element even though its RIM representation is somewhat different than described in the mapping. In addition, not all v3 models adhere to good modeling practices, so some data elements that would appear to map to a FHIR element might not map if the information has not been well represented. Therefore RIM mappings should be taken as a guide, not an absolute, and mappings must be done in the context of the v3 specification being mapped. (Also see Abstract models below.)
v3 extensions: While the core of the v3 methodology is "design by constraint", it still makes provision for the use of extensions - either in a foreign namespace or denoted by a special attribute. When converting between v3 and FHIR, the use of such extensions will need to be taken into account. As a rule, most v3 extensions will map to FHIR extensions, as the v3 design-by-constraint principle suggests that anything that would qualify as "core" in FHIR would already have been part of the base v3 specification.
Abstract models:
As
previously
noted,
many
of
the
v3
models
created
at
the
HL7
International
level
are
quite
abstract.
As
a
result,
the
models
can
be
used
to
say
a
wide
variety
of
things,
often
in
a
wide
variety
of
different
ways.
This
makes
defining
a
mapping
between
those
specifications
and
FHIR
(or
any
other
specification)
quite
tricky.
For
practical
v3
<->
FHIR
interoperability,
mappings
will
need
to
be
created
at
the
level
of
message
specifications,
implementation
guides
and/or
templates
that
are
more
concrete
and
closer
to
the
implementation
level.
For
example,
mapping
all
of
CDA
to
FHIR
would
be
impossible
given
the
expressive
capability
of
the
right-hand-side
of
the
CDA
model.
However,
mapping
the
Consolidated
CDA
(CCDA)
templates
to
FHIR
is
quite
possible.
Context
conduction:
As
discussed
above,
HL7
v3
models
rely
on
context
conduction
-
either
implicitly
or
explicitly
controlled.
When
converting
to
FHIR,
the
context
will
need
to
be
propagated
into
each
resource.
Update
mode:
In
HL7
v3
instances,
updates
are
generally
handled
in
snapshot
mode,
similar
to
the
FHIR
approach
-
if
any
information
changes,
the
entire
record
is
sent,
including
the
modified
data
elements.
However,
the
v3
methodology
does
support
the
introduction
of
an
"updateMode"
property
to
allow
only
the
changes
to
be
sent
for
all
or
part
of
an
instance.
Each
element
repetition
is
flagged
with
an
updateMode
to
indicate
whether
the
element
is
to
be
added,
removed,
updated,
etc.
Additional
updateModes
allow
further
control
over
updates.
As
with
the
V2
discussion
above,
implementers
will
need
to
generate
a
full
snapshot
of
each
resource
or
will
need
to
introduce
modifier
extensions
to
allow
similar
behavior
to
v3.
Additional
considerations:
Most
of
the
implementation
considerations
for
interoperating
between
FHIR
and
HL7
v2
As previously noted, many of the v3 models created at the HL7 International level are quite abstract. As a result, the models can be used to say a wide variety of things, often in a wide variety of different ways. This makes defining a mapping between those specifications and FHIR (or any other specification) quite tricky. For practical v3 <-> FHIR interoperability, mappings will need to be created at the level of message specifications, implementation guides and/or templates that are more concrete and closer to the implementation level. For example, mapping all of CDA to FHIR would be impossible given the expressive capability of the right-hand-side of the CDA model. However, mapping the Consolidated CDA (CCDA) templates to FHIR is quite possible.
Context conduction: As discussed above, HL7 v3 models rely on context conduction - either implicitly or explicitly controlled. When converting to FHIR, the context will need to be propagated into each resource.
Update mode: In HL7 v3 instances, updates are generally handled in snapshot mode, similar to the FHIR approach - if any information changes, the entire record is sent, including the modified data elements. However, the v3 methodology does support the introduction of an "updateMode" property to allow only the changes to be sent for all or part of an instance. Each element repetition is flagged with an updateMode to indicate whether the element is to be added, removed, updated, etc. Additional updateModes allow further control over updates. As with the V2 discussion above, implementers will need to generate a full snapshot of each resource or will need to introduce modifier extensions to allow similar behavior to v3.
Additional considerations:
Most of the implementation considerations for interoperating between FHIR and
HL7 v2
also
hold
with
v3.
Specifically:
also hold with v3. Specifically:
Extensions
,
Independent
vs.
Contained
resources
,
Resource
Identification
,
Merging
references
and
resources
and
Generating
human-readable
content
.
©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
generated
on
Sat,
Oct
24,
2015
07:44+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Compare
to
DSTU1
,
Independent vs. Contained resources
,
Resource Identification
,
Merging references and resources
and
Generating human-readable content
.
© HL7.org 2011+. FHIR STU3 Ballot (v1.6.0-9663) generated on Thu, Aug 11, 2016 17:07+1000.
QA Page
Links:
Search
|
|
Version History
|
Table of Contents
|
Compare to DSTU2
|
|
Propose
a
change
|
Propose a change