Release
4B
5
Implementation
Support
This
page
is
part
of
the
FHIR
Specification
(v4.3.0:
R4B
(v5.0.0:
R5
-
STU
).
The
This
is
the
current
published
version
which
supercedes
in
it's
permanent
home
(it
will
always
be
available
at
this
version
is
5.0.0
.
URL).
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R5
R4B
R4
R3
R2
|
FHIR
Infrastructure
Work
Group
|
Maturity Level : N/A | Standards Status : Informative |
HL7
v2
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
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
V2
messaging
structure
(though,
unlike
HL7
v2,
V2,
FHIR
supports
other
paradigms
as
well
including
documents,
REST
and
other
service
models).
Refer
to
the
Message
Header
resource.
Granularity:
HL7
v2's
V2's
"Segment"
structure
provides
re-usable
chunks
of
data
that
roughly
correspond
to
FHIR's
idea
of
resources
.
However,
HL7
v2
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
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
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
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
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
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
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
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
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
V2
tends
to
include
many
elements
that
are
used
in
only
very
limited
circumstances.
FHIR
uses
extensions
for
those
circumstances.
HL7
v2
V2
and
FHIR
both
provide
formal
mechanisms
for
defining
profiles
to
give
guidance
on
the
use
of
the
specification.
However,
the
HL7
v2
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
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
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
V2
elements
will
map
to
FHIR
core,
a
large
percentage
will
not.
Where
a
HL7
v2
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
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
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
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
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
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
V2
message
will
be
mapped
to
multiple
resource
instances
-
often
10s
or
even
100s
of
resource
instances.
To
maintain
consistency
with
the
HL7
v2
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
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,
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,
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
hl7.fhir.core#5.0.0
generated
on
Sat,
May
28,
2022
12:57+1000.
Sun,
Mar
26,
2023
15:26+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Glossary
|
QA
Page
|
Compare
to
R4
|
Compare
to
R4B
|
|
Propose
a
change