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 v2
was
HL7's
first
information
exchange
standard
and
is
one
of
its
most
widely
adopted,
being
prominent
in
in-patient
settings
throughout
the
world,
though
also
used
in
a
variety
of
other
contexts
as
well.
HL7
v2
uses
messages
composed
of
re-useable
segments
to
communicate
healthcare-related
information
between
a
sending
and
receiving
system
as
well
as
to
invoke
particular
behavior
(patient
transfers,
lab
orders,
etc.)
It
also
supports
one-way
communication
through
notifications,
provides
support
for
queries
and
other
workflow.
was HL7's first information exchange standard and is one of its most widely adopted, being prominent in in-patient settings throughout the world, though also used in a variety of other contexts as well. HL7 v2 uses messages composed of re-useable segments to communicate healthcare-related information between a sending and receiving system as well as to invoke particular behavior (patient transfers, lab orders, etc.) It also supports one-way communication through notifications, provides support for queries and other workflow.
Event-based:
FHIR
supports
an
event-based
messaging
paradigm
similar
to
the
HL7
v2
messaging
structure
(though
unlike
HL7
v2,
FHIR
supports
other
paradigms
as
well
including
documents,
REST
and
other
service
models).
Refer
to
the
Message
Header
resource.
FHIR supports an event-based messaging paradigm similar to the HL7 v2 messaging structure (though unlike HL7 v2, FHIR supports other paradigms as well including documents, REST and other service models). Refer to the
Message Header
resource.
Granularity:
HL7
v2's
"Segment"
structure
provides
re-useable
chunks
of
data
that
roughly
correspond
to
FHIR's
idea
of
HL7 v2's "Segment" structure provides re-useable chunks of data that roughly correspond to FHIR's idea of
resources
.
However,
HL7
v2
segments
can't
be
independently
manipulated.
Additionally,
not
all
segments
have
the
characteristics
of
independent
identity
held
by
FHIR
resources.
Due
to
differences
in
scope
and
approach
to
extensibility,
HL7
v2
segments
and
data
types
are
frequently
cluttered
with
data
elements
that
are
not
used
by
(or
even
understood
by)
the
majority
of
implementations
Segments
can
be
composed
into
repeating
and/or
optional
collections
called
"groups"
to
represent
full
healthcare
business
objects.
For
example,
the
"Order"
component
of
an
OMP
(Pharmacy/Treatment
Order
Message)
includes:
an
ORC
segment
dealing
with
workflow
aspects
of
the
order
an
RXO
segment
dealing
with
pharmacy-specific
order
aspects
optional
TQ1
and
TQ2
segments
describing
the
timing
of
the
order
optional
NTE
segments
dealing
with
supplemental
notes
or
rendering
of
the
order
optional
RXR
segments
describing
route
information
. However, HL7 v2 segments can't be independently manipulated. Additionally, not all segments have the characteristics of independent identity held by FHIR resources. Due to differences in scope and approach to extensibility, HL7 v2 segments and data types are frequently cluttered with data elements that are not used by (or even understood by) the majority of implementations
Segments can be composed into repeating and/or optional collections called "groups" to represent full healthcare business objects. For example, the "Order" component of an OMP (Pharmacy/Treatment Order Message) includes:
The HL7 v2 approach to granularity emphasizes re-use of "patterns" of information. For example, timing and route information are not useful on their own, but they are useful in many circumstances. Due to the 3-level nesting limit, separate segments are also required for data structures that would otherwise nest too deeply. FHIR takes a different approach to reusability, focusing on objects that can be maintained independently. The
MedicationOrder
resource
encompasses
all
of
the
aspects
of
the
above
segments,
with
the
exception
of
some
of
the
workflow
aspects
of
ORC
which
is
handled
by
the
Order
resource.
The
resource encompasses all of the aspects of the above segments, with the exception of some of the workflow aspects of ORC which is handled by the
Task
resource. The
MedicationOrder
resource
is
itself
complex,
having
nested
structures
for
dosage
instructions,
dispensing
instructions,
etc.
that
are
not
simple
data
types.
resource is itself complex, having nested structures for dosage instructions, dispensing instructions, etc. that are not simple data types.
Extensibility:
HL7
v2
provides
an
extensibility
mechanism
through
the
use
of
"Z-segments".
The
meaning
of
these
extensions
is
opaque
without
prior
manual
explanation
by
the
sender.
Extensions
are
supposed
to
be
restricted
to
data
elements
that
do
not
affect
the
meaning
of
the
"standard"
segments.
FHIR
HL7 v2 provides an extensibility mechanism through the use of "Z-segments". The meaning of these extensions is opaque without prior manual explanation by the sender. Extensions are supposed to be restricted to data elements that do not affect the meaning of the "standard" segments. FHIR
Extensions
,
on
the
other
hand,
can
appear
at
any
level
(including
within
data
types).
, on the other hand, can appear at any level (including within data types).
ModifierExtensions
may
be
used
in
circumstances
where
an
extension
can
change
the
meaning
of
other
elements
(e.g.
the
introduction
of
a
negation
indicator
on
a
record).
Finally,
the
meaning
of
FHIR
extensions
is
discoverable
by
resolving
the
URI
that
defines
the
extension.
The
URI
approach
also
ensures
that
extensions
created
by
independent
systems
won't
collide.
(This
can
be
an
issue
with
Z-segments.)
Inter-version
compatibility:
HL7
version
2
has
strict
processes
for
maintaining
forward
and
backward
compatibility.
Content
can
only
be
added
to
the
end
of
existing
fields,
components,
etc.
Applications
are
expected
to
ignore
unexpected
content
or
repetitions.
FHIR
promises
similar
compatibility
rules.
The
path
to
an
element
within
a
FHIR
instance
will
remain
unchanged
in
future
versions.
Specific
rules
on
handling
"new"
elements
(ignoring,
checking
for
"must
understand"
indicators,
etc.
will
be
developed
during
the
DSTU
period.
Human
readability:
In
general,
HL7
v2
instances
do
not
provide
for
human
readable
versions
of
the
content
exchanged.
While
some
systems
may
make
use
of
NTE
segments
to
provide
a
human-readable
rendering
of
all
or
part
of
a
message
payload,
the
rules
for
when
or
if
this
occurs
is
site-specific.
FHIR
requires
human
readable
content
to
be
provided
for
each
resource.
Update
behavior:
HL7
v2
data
is
typically
exchanged
in
"snapshot"
mode
-
updates
are
communicated
by
sending
a
complete
copy
of
the
instance
with
the
new
data
filled
in.
However,
some
segments
and
messages
in
HL7
v2
support
more
sophisticated
exchanges
where
only
changed
data
is
sent
and
codes
or
special
values
indicate
what
sort
of
change
is
to
occur
(e.g.
add
this
address,
remove
this
name).
Out-of-the-box,
FHIR
only
functions
using
snapshot
mode.
While
the
use
of
may be used in circumstances where an extension can change the meaning of other elements (e.g. the introduction of a negation indicator on a record). Finally, the meaning of FHIR extensions is discoverable by resolving the URI that defines the extension. The URI approach also ensures that extensions created by independent systems won't collide. (This can be an issue with Z-segments.)
Inter-version compatibility: HL7 version 2 has strict processes for maintaining forward and backward compatibility. Content can only be added to the end of existing fields, components, etc. Applications are expected to ignore unexpected content or repetitions. FHIR promises similar compatibility rules. The path to an element within a FHIR instance will remain unchanged in future versions. Specific rules on handling "new" elements (ignoring, checking for "must understand" indicators, etc. will be developed during the DSTU period.
Human readability: In general, HL7 v2 instances do not provide for human readable versions of the content exchanged. While some systems may make use of NTE segments to provide a human-readable rendering of all or part of a message payload, the rules for when or if this occurs is site-specific. FHIR requires human readable content to be provided for each resource.
Update behavior:
HL7 v2 data is typically exchanged in "snapshot" mode - updates are communicated by sending a complete copy of the instance with the new data filled in. However, some segments and messages in HL7 v2 support more sophisticated exchanges where only changed data is sent and codes or special values indicate what sort of change is to occur (e.g. add this address, remove this name). Out-of-the-box, FHIR only functions using snapshot mode. While the use of
ModifierExtensions
to
introduce
equivalent
behavior
to
HL7
v2
is
possible,
doing
so
would
create
interoperability
issues
and
would
make
use
of
the
resources
difficult
outside
the
messaging
paradigm.
Optionality
&
Profiles:
Both
HL7
v2
and
FHIR
provide
a
similar
degree
of
flexibility
at
the
international
standard
level.
Most
data
elements
are
optional.
However,
there
are
two
differences.
FHIR
resources
are
much
more
limited
in
terms
of
what
elements
are
included
in
the
core
specification
-
only
those
elements
that
the
vast
majority
of
systems
will
support.
HL7
v2
tends
to
include
many
elements
that
are
used
in
only
very
limited
circumstances.
FHIR
uses
extensions
for
those
circumstances.
HL7
v2
and
FHIR
both
provide
formal
mechanisms
for
defining
profiles
to
give
guidance
on
the
use
of
the
specification.
However,
the
HL7
v2
mechanism
has
not
been
widely
used.
FHIR
to introduce equivalent behavior to HL7 v2 is possible, doing so would create interoperability issues and would make use of the resources difficult outside the messaging paradigm.
Optionality & Profiles:
Both HL7 v2 and FHIR provide a similar degree of flexibility at the international standard level. Most data elements are optional. However, there are two differences. FHIR resources are much more limited in terms of what elements are included in the core specification - only those elements that the vast majority of systems will support. HL7 v2 tends to include many elements that are used in only very limited circumstances. FHIR uses extensions for those circumstances. HL7 v2 and FHIR both provide formal mechanisms for defining profiles to give guidance on the use of the specification. However, the HL7 v2 mechanism has not been widely used. FHIR
Profiles
form
an
essential
component
of
the
methodology
and
are
built
into
tooling,
increasing
the
likelihood
of
their
use.
form an essential component of the methodology and are built into tooling, increasing the likelihood of their use.
Mapping:
One
of
the
biggest
challenges
with
HL7
v2
interoperability
is
the
variation
of
implementation.
Even
when
identical
scenarios
are
being
handled
in
similar
business
environments,
the
data
elements
supported
can
vary
and
even
the
place
where
a
given
data
element
is
placed
in
an
instance
can
vary.
As
a
result,
defining
consistent
mapping
rules
between
HL7
v2
and
FHIR
at
an
international
or
even
regional
level
is
not
terribly
realistic.
The
FHIR
mappings
provided
give
a
starting
point
for
consideration,
but
mappings
will
generally
need
to
be
done
on
an
implementation
by
implementation
basis.
One of the biggest challenges with HL7 v2 interoperability is the variation of implementation. Even when identical scenarios are being handled in similar business environments, the data elements supported can vary and even the place where a given data element is placed in an instance can vary. As a result, defining consistent mapping rules between HL7 v2 and FHIR at an international or even regional level is not terribly realistic. The FHIR mappings provided give a starting point for consideration, but mappings will generally need to be done on an implementation by implementation basis.
Extensions:
While
some
HL7
v2
elements
will
map
to
FHIR
core,
a
large
percentage
will
not.
Where
a
HL7
v2
element
is
not
supported
by
core,
an
extension
will
be
needed
to
share
the
information.
Where
there
is
interest,
HL7
may
choose
to
publish
and
maintain
extensions
for
HL7
v2
elements
that
are
not
supported
as
part
of
the
core
FHIR
specification.
The
FHIR
extension
registry
should
be
searched
prior
to
defining
local
extensions.
If
time
permits,
the
relevant
HL7
WG
should
be
contacted
with
a
request
to
define
additional
HL7
v2
extensions
if
needed
ones
are
not
present.
If
time
does
not
permit,
applications
can
define
their
own
extensions,
but
should
have
a
migration
plan
for
if/when
HL7
defines
it
later.
For
Z-segments,
URIs
should
be
defined
to
be
specific
to
the
system/environment
that
defined
the
Z-segment
(e.g.
http://acme.org/fhir/extensions/consent),
not
based
on
the
name
of
the
Z-segment
itself
(given
that
Z-segments
with
the
same
name
but
different
meaning
may
exist)
(e.g.
http://hl7.org/ZAC).
Resource
identification:
While some HL7 v2 elements will map to FHIR core, a large percentage will not. Where a HL7 v2 element is not supported by core, an extension will be needed to share the information. Where there is interest, HL7 may choose to publish and maintain extensions for HL7 v2 elements that are not supported as part of the core FHIR specification. The FHIR extension registry should be searched prior to defining local extensions. If time permits, the relevant HL7 WG should be contacted with a request to define additional HL7 v2 extensions if needed ones are not present. If time does not permit, applications can define their own extensions, but should have a migration plan for if/when HL7 defines it later. For Z-segments, URIs should be defined to be specific to the system/environment that defined the Z-segment (e.g. http://acme.org/fhir/extensions/consent), not based on the name of the Z-segment itself (given that Z-segments with the same name but different meaning may exist) (e.g. http://hl7.org/ZAC).
Resource identification:
HL7
v2
messages
will
often
reference
objects
that
have
already
been
referred
to
in
previous
messages.
When
converting
the
messages
to
FHIR,
these
references
will
need
to
point
to
the
same
resource
URI.
Given
that
not
all
HL7
v2
message
objects
have
identifiers
in
the
message,
this
can
be
somewhat
problematic.
An
approach
to
handling
this
issue
exists
for
FHIR
HL7 v2 messages will often reference objects that have already been referred to in previous messages. When converting the messages to FHIR, these references will need to point to the same resource URI. Given that not all HL7 v2 message objects have identifiers in the message, this can be somewhat problematic. An approach to handling this issue exists for FHIR
transactions
.
However,
the
ramifications
of
using
this
approach
in
a
messaging
environment
have
not
yet
been
resolved.
Implementers
will
need
to
explore
their
own
strategies
as
part
of
early
adoption.
Merging
references
and
resources:
. However, the ramifications of using this approach in a messaging environment have not yet been resolved. Implementers will need to explore their own strategies as part of early adoption.
Merging references and resources:
HL7
v2
message
instances
may
well
reference
the
same
"object"
numerous
times.
For
example,
a
message
containing
a
patient's
medication
history
is
likely
to
include
references
to
the
same
clinicians
and
clinics/hospitals
many
times.
While
in
some
cases,
the
data
captured
for
a
given
object
might
be
identical
in
all
uses,
in
other
cases
the
information
might
vary.
For
example,
the
sending
system
might
convey
historical
phone
numbers
for
old
records
and
current
phone
numbers
for
newer
records.
Alternatively,
the
message
design
might
allow
expression
of
different
amounts
of
detail
in
different
portions
of
the
message
or
the
sending
application
might
simply
be
designed
to
convey
different
amounts
of
detail
in
different
portions
of
the
message
(e.g.
conveying
phone
number
for
an
ordering
clinician,
but
not
for
a
data-entry
clinician).
When
converting
to
FHIR,
all
references
to
the
same
"object"
will
generally
have
a
single
resource
identifier
and
be
referenced
only
once
in
the
instance
-
with
the
complete
set
of
information
needed/available.
This
creates
two
challenges:
HL7 v2 message instances may well reference the same "object" numerous times. For example, a message containing a patient's medication history is likely to include references to the same clinicians and clinics/hospitals many times. While in some cases, the data captured for a given object might be identical in all uses, in other cases the information might vary. For example, the sending system might convey historical phone numbers for old records and current phone numbers for newer records. Alternatively, the message design might allow expression of different amounts of detail in different portions of the message or the sending application might simply be designed to convey different amounts of detail in different portions of the message (e.g. conveying phone number for an ordering clinician, but not for a data-entry clinician). When converting to FHIR, all references to the same "object" will generally have a single resource identifier and be referenced only once in the instance - with the complete set of information needed/available. This creates two challenges:
Identified vs. Contained resources:
Each
HL7
v2
message
will
be
mapped
to
multiple
resource
instances
-
often
10s
or
even
100s
of
resource
instances.
To
maintain
consistency
with
the
HL7
v2
messaging
paradigm,
all
resource
data
will
typically
be
sent
over
the
wire
as
part
of
the
FHIR
message
rather
than
being
sent
by
reference
as
would
be
typical
in
a
RESTful
implementation.
However,
FHIR
provides
two
different
ways
of
communicating
the
resources
as
part
of
the
message
bundle
:
they
can
either
be
sent
as
"fully
identified"
resources
(direct
entries
in
the
Each HL7 v2 message will be mapped to multiple resource instances - often 10s or even 100s of resource instances. To maintain consistency with the HL7 v2 messaging paradigm, all resource data will typically be sent over the wire as part of the FHIR message rather than being sent by reference as would be typical in a RESTful implementation. However, FHIR provides two different ways of communicating the resources as part of the message
bundle
with
their
own
identity,
and
able
to
be
the
subject
of
independent
transactions),
or
they
can
be
sent
as
: they can either be sent as "fully identified" resources (direct entries in the bundle with their own identity, and able to be the subject of independent transactions), or they can be sent as
contained
resources,
meaning
they
are
only
identified
relative
to
another
resources
and
cannot
be
retrieved
or
otherwise
manipulated
on
their
own.
A
HL7
v2
to
FHIR
conversion
process
will
need
to
make
the
determination
of
what
data
elements
are
or
must
be
present,
for
a
resource
to
be
fully
identified.
In
some
cases,
the
determination
will
be
done
at
the
time
of
mapping.
In
other
cases,
it
may
depend
on
the
content
of
a
particular
instance.
As
an
example,
an
XCN
containing
just
a
name
(
resources, meaning they are only identified relative to another resources and cannot be retrieved or otherwise manipulated on their own. A HL7 v2 to FHIR conversion process will need to make the determination of what data elements are or must be present, for a resource to be fully identified. In some cases, the determination will be done at the time of mapping. In other cases, it may depend on the content of a particular instance. As an example, an XCN containing just a name (
|^Smith^John|
)
doesn't
contain
enough
information
to
identify
the
physician
from
any
other
John
Smith,
so
will
need
to
be
contained
resource,
whereas
an
XCN
of
) doesn't contain enough information to identify the physician from any other John Smith, so will need to be contained resource, whereas an XCN of
|12345^Smith^John|
generally
does,
though
the
conversion
process
will
need
to
be
aware
of
the
scope
and
management
processes
around
the
identifier.
Generating
human-readable
content:
generally does, though the conversion process will need to be aware of the scope and management processes around the identifier.
Generating human-readable content:
FHIR
requires
that
every
resource
have
a
human
readable
FHIR requires that every resource have a human readable
narrative
that
contains
all
information
relevant
to
human
decision-making.
When
converting
from
HL7
v2,
developers
(likely
with
guidance
from
clinicians)
will
need
to
determine
what
information
from
the
message
should
be
rendered
and
how
to
generate
this
content.
Nulls
and
update
modes:
that contains all information relevant to human decision-making. When converting from HL7 v2, developers (likely with guidance from clinicians) will need to determine what information from the message should be rendered and how to generate this content.
Nulls and update modes:
In
HL7
v2,
"action"
codes
can
determine
whether
particular
segments
represent
information
to
be
added,
updated
or
deleted.
Fields
can
be
populated
with
"null"
(two
consecutive
double-quotes
with
no
other
characters)
to
note
a
field
is
to
be
deleted.
An
omitted
element
or
repetition
is
generally
interpreted
as
"retain
existing
data
unchanged".
This
contrasts
with
the
FHIR
approach
of
requiring
all
data
to
be
present
as
a
snapshot.
Systems
will
either
need
to
build
in
logic
to
generate
a
full
snapshot
of
each
resource
or
will
need
to
introduce
modifier
extensions
to
allow
similar
behavior
to
HL7
v2.
©
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
In HL7 v2, "action" codes can determine whether particular segments represent information to be added, updated or deleted. Fields can be populated with "null" (two consecutive double-quotes with no other characters) to note a field is to be deleted. An omitted element or repetition is generally interpreted as "retain existing data unchanged". This contrasts with the FHIR approach of requiring all data to be present as a snapshot. Systems will either need to build in logic to generate a full snapshot of each resource or will need to introduce modifier extensions to allow similar behavior to HL7 v2.
© 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