Implementation
Support
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
(v4.0.1:
R4
-
Mixed
Normative
and
STU
3).
)
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
R4
R3
R2
|
FHIR
Infrastructure
Work
Group
|
Maturity Level : N/A |
|
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-usable
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
workflows.
Event-based:
FHIR
supports
an
event-based
messaging
paradigm
similar
to
the
HL7
v2
messaging
structure
(though
(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"
"Segment"
structure
provides
re-usable
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"
"groups"
to
represent
full
healthcare
business
objects.
For
example,
the
"Order"
"Order"
component
of
an
OMP
(Pharmacy/Treatment
Order
Message)
includes:
The
HL7
v2
approach
to
granularity
emphasizes
re-use
of
"patterns"
"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
MedicationRequest
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
MedicationRequest
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".
"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"
"standard"
segments.
FHIR
Extensions
,
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"
"new"
elements
(ignoring,
checking
for
"must
understand"
"must
understand"
indicators,
etc.
etc.)
will
be
developed
during
the
STU
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"
"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 Profiles 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.
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: 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:
HL7
v2
message
instances
may
well
reference
the
same
"object"
"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"
"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"
"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
resource
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
discern
the
physician
from
any
other
John
Smith,
so
will
need
to
be
a
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: 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:
In
HL7
v2,
"action"
"action"
codes
can
determine
whether
particular
segments
represent
information
to
be
added,
updated
or
deleted.
Fields
can
be
populated
with
"null"
"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
"retain
existing
data
unchanged".
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
consider
using
the
Patch
Operation
instead.
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
4
(Technical
Correction
#1)
(v4.0.1)
generated
on
Thurs,
Oct
24,
Fri,
Nov
1,
2019
11:53+1100.
09:37+1100.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU2
R3
|
|
Propose
a
change