If you were to attend the HL7 Working Group meeting in New
Orleans this February, you would have had a hard time finding anyone who is still
involved with HL7 version 2.x development. Yes, HL7 version 2.8 has been issued
and there is work going on to specify 2.9 but given the fact that most of the
US deployments (est. 80 percent) is still on version 2.3 or 2.3.1, which dates
from the last century, one might wonder how useful it is to keep on developing
these new versions.
The question you might ask is “will version 2 will be
replaced by FHIR (Fast Healthcare Interoperability Resources)?” My answer to
that question is “possibly, but only to a
certain degree.” In order to have an opinion about this, you have to
understand what FHIR is, its benefits, and what it could do for an
implementation. Here are my observations about common myths and truths about
FHIR:
1.
FHIR is just another message encoding - This is
incorrect, it is much more than that. This has been the problem with HL7 version
3, which does not provide any more benefits than being another way of encoding messages.
Hence, v3 failed miserably because there was no business case to support
upgrading all those existing interfaces. A v3 encoded message, which is encoded
in XML, is more verbose than the compact, pragmatic “pipe” encoded v2 messages,
and early implementations choked the interface engines and IT infrastructure.
Also, XML is not really “mobile-friendly” as
it requires overhead for decoding. Instead, most FHIR implementations use JSON
(JavaScript Object Notation) encoding for the messages, which is more compact,
efficient and easy to interpret. However, this is not the most important
benefit. FHIR messaging is more “normalized” than a “composite” v2 message and
uses so-called resources to encode this information. As an example, think about
mapping the v2 registration message PID segment into a FHIR patient resource,
the PV1 segment into an organization and practitioner resource, and the OBX
segment into an observation resource, each being web-accessible. The messaging
paradigm is one of four paradigms and the basis of FHIR and an important part
of the standard, but not the only and not the most important part.
2.
FHIR uses resources that are shared - This is
correct and, in my opinion, the most powerful capability of FHIR. To explain
this, let’s look at the current duplication of data in a typical scenario. A
patient is registered when admitted in the ER and patient information is stored
in the registration system. Clinical information is entered into the EMR
together with patient information. An order is placed for a lab and radiology
procedure, results are stored locally, again with corresponding patient
information. The radiology department produces images and a report; the images
are labeled with the patient information again. This scenario shows the
duplication of data just for patient information (four times in this simple use
case).
What happens if someone discovers
that the patient information was incorrectly entered, or there were some previous
records available under a different name (e.g. maiden name), or additional
demographic information becomes available, etc. HL7 version 2 defines many
transactions for updates, moves, and merges, to synchronize these records. But
what if there was only one single source of patient information, which can be
accessed by any application through a simple API web interface? It would
greatly simplify the development and management of patient demographics. The
same applies for many other resources, such as practitioner information,
medications, scheduling, appointments, etc. This is the beauty of FHIR, using
easily accessible resources for important medical information.
3.
There could be hundreds of shared FHIR resources
- Not quite, a FHIR resource is a small logically related set of parameters of
interest to healthcare, having a known identity and location so it can be
accessed, such as a “patient,” “organization,” practitioner,” “consent,”
“schedule,” and about 150 more that are defined.
Access is provided using the
second of the four FHIR paradigms, i.e. it is based on REST (REpresentational
State Transfer). REST is a client server protocol that provides access to a
resource to create, retrieve, update or delete information. As an analogy let’s
look at how resources are used in the non-healthcare field. Think about a
website for a hotel which contains access to a map resource (Google Maps),
customer rating (Trip advisor), Activities (TheCrazyTourist), and secure
checkout (Paypal).
Similarly, one could create a
webpage of an EMR that has links to the patient resource, linked to its
scheduled appointments, list of practitioners, and showing medications,
recorded observations and diagnostic reports. The EMR provider can merely use
these resources to create a “mash-up,” which is very light weight as it relies
on these resources instead of having to manage all of this data itself. Using
standard interfaces has been demonstrated at various “FHIR hackathon” events,
showing that one could use a simple client implementation using standard
resources in literally a couple of hours.
4.
FHIR is ready to be implemented - Here is where
one could have a difference of opinion. The issue is that the FHIR standard is
still very much a living standard based on drafts, called DSTU or “Draft
Standard for Trial Use,” which means that subsequent changes are not
necessarily backwards compatible. Knowing that, implementing the latest version
is DSTU 4 means that implementations based on versions 1, 2 and 3 won’t be
compatible. This has become one of the major pain points and causes for
interoperability problems among FHIR implementations.
The good news is that parts of the
standard passed the balloting process and are reliable and stable enough. For example,
12 of the defined resources, including “patient” are now called “normative,” but
one should remember that 12 resources represents less than 10 percent of the
list of all defined resources. So if one would, for example, implement the access
of a radiology report using the “diagnostic report” resource, it has to be
based on a draft standard.
Even though there are a couple of
early FHIR implementations, there are not a lot of production systems that even
partially use FHIR. The first draft was published in 2012, and most of the
standard is still in draft format as of today. This is one of the most common complaints;
why is it still mostly in draft and why does it take so long? The short answer
is that standardization just takes time, but it definitely impacts early
implementations.
5.
FHIR is an all-encompassing standard - Incorrect,
FHIR covers only 80 percent of the most common use cases. The remaining 20
percent are covered by so-called “extensions.” The goods news is that the
conformance and related extensions are well documented, retrievable and
interchangeable. The bad news is that extensions are semi-proprietary and
require code changes in case they are important enough to be interpreted by a
client. There are two different types of extensions, the “normal” extensions,
which can be ignored by a recipient, and the “modifier” extensions which cannot
be ignored as they change the meaning and/or context of the information to be
exchanged. The 80 percent rule implies that the FHIR standard is going to be
relatively compact, unlike HL7 v2, which has lots of options, but it would not
necessarily be better from an interoperability perspective. However, if one
considers how poorly v2 interoperates with its many options (patient
registration, aka ADT, alone has 60 event types) the relatively “bare bones”
FHIR might, in the long term, be better especially with a well-defined
conformance and extension definition. Time will tell.
6.
FHIR is a document standard - Yes, this is
correct, unlike v2, that is primarily a messaging standard. The third paradigm
of FHIR is the capability to exchange persistent objects such as documents. By linking
and exchanging multiple resources in a so-called “bundle,” you can create a
document. For example a patient resource combined with resources of his/her
allergies, a list of medications, observations and reports could be exchanged
between a hospital and referring physician to document a hospital visit. These
documents can be signed and authenticated.
A receiver can either store the document, e.g. in a EMR, or use the
information available in the document to update its internal database or
record, for example, with details from a lab report.
FHIR can also exchange existing
CDA (Clinical Document Architecture) documents. CDA, and the US version called
Consolidated or CCDA is the most used and pretty much the only surviving part
of the HL7 v3 standard that is in use to exchange information between EMR’s
from different institutions and physicians. These CDA’s are being created and exchanged
routinely by several Health Information Exchanges (HIE’s), therefore, we can
use the FHIR messaging standard to exchange these.
7.
The FHIR interface provides for all use cases - Incorrect,
The FHIR REST interface is somewhat limited, which is where we use the FHIR Services,
the fourth FHIR paradigm, which is based on the SOA (Service-oriented
Architecture). Services are a higher-level functionality that can be accessed
using a standard Application Programming Interface or API. These services
maintain responsibility for certain related information, for example
terminology management, which keeps medical terminology up-to-date, or identity
management, which is responsible patient demographics and updating and cross
referencing different identities among different domains and institutions.
8.
FHIR implementation is optional - This is
correct but that might change, at least for the US. To comply with what used to
be called “Meaningful Use” and is now called MACRA, healthcare providers need
to use an EMR to get full Medicare/Medicaid reimbursement payments. To comply,
the Office of the National Coordinator for Health Information Technology (ONC)
requires an EMR to be certified using a so-called Open API, which is basically
the REST interface, consequently FHIR is strongly recommended.
9.
FHIR is a US standard - Incorrect, as a matter
of fact, two of the main FHIR standard architects are based in Australia and
the Netherlands, and initial implementations seem to be more prevalent outside the
US than inside the US. This is caused by the fact that centralized national healthcare
systems can sometimes more easily make changes happen than in the US. For
example, there is a project up and running in Canada for prescription
management and in the Netherlands for medications.
10.
FHIR will replace all existing interfaces - Incorrect,
HL7 version 2 is widespread and entrenched in many systems. If there is no
incentive to modify or change, v2 will continue to be used and form the
backbone of healthcare delivery communication. There are going to be v2
interfaces for a long time, and there will also be interfaces using v3 CDA
document exchanges. But, for new applications, such as a physician directory
resource in the state of Texas that will be used through a public HIE for
accessing diagnostic reports by a patient through a web portal, or for
accessing a scheduling application or prescription renewal application from a
smart phone, FHIR will become the standard of choice.
There is no question that there is a lot of hype around
FHIR, but the fact is implementations are (still) very limited. Part of it has
to do with the required learning curve, especially if you are an HL7 v2
developer, the immaturity of the FHIR standard, which is still very much in
draft status, means that changes and updates are inevitable, and lack a
business case for converting existing applications. But, for new developments,
FHIR deserves, at a minimum, a fresh look and evaluation if one could use this
new paradigm for implementation. Just don’t go overboard and implement
something just because it is new and “hot,” but do due diligence before making
this choice.
From a support and clinical perspective, it is likely that
you’ll see some initial limited niche applications, which very well could be
expanded as the experience and support into day-to-day software applications
such as the EMR’s, HIE’s, mobile health-aps, and others grow. Note that more
information can be found at the FHIR website (www.hl7.org/fhir)
or, if you are interested to learn more, you can sign up for the OTech FHIR
core webcast training.
