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.
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.