Release
4B
5
Ballot
Implementation
Support
This
page
is
part
of
the
FHIR
Specification
(v4.3.0:
R4B
(v5.0.0-ballot:
R5
Ballot
-
STU
see
ballot
notes
).
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
|
FHIR
Infrastructure
Work
Group
|
Maturity Level : N/A | Standards Status : Informative |
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, 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-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
datatypes
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
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.
datatypes.
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
Extensions
,
on
the
other
hand,
can
appear
at
any
level
(including
within
data
types).
datatypes).
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 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" 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" 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
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
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
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
Delete
indicator
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"
a
"delete
indicator"
(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
consider
using
the
Patch
Operation
instead.
FHIR
®©
HL7.org
2011+.
FHIR
Release
4B
(v4.3.0)
hl7.fhir.r4b.core#4.3.0
R5
Ballot
hl7.fhir.core#5.0.0-ballot
generated
on
Sat,
May
28,
Sep
10,
2022
12:57+1000.
05:07+1000.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Glossary
|
QA
Page
|
Compare
to
R4
R4B
|
Compare
to
R5
Draft
|
|
Propose
a
change