J P Systems, Inc.

blog header picture

J P Systems HIT Blog

Emerging Healthcare IT Technologies: The Strengths and Weaknesses of FHIR


It has been several years since we reviewed the progress of the HL7 FHIR standards adoption rate. Health Level Seven’s (HL7) Fast Healthcare Interoperability Resources (FHIR) is an emerging standard that has rapidly captured the mind-share of the Health Information Technology (HIT) standards community. FHIR is a standard that enables healthcare data sharing between systems in a manner that is more easily implemented and more expressive than previous HL7 standards such as Version2, 3 and CDA. HIT vendors such as Allscripts, Cerner, and Epic are already rapidly adopting FHIR. The standard can be specified in on a more “granular” level in its resources than previous standards, with the result that implementers can perform more precise queries with it.


The HL7 Clinical Document Architecture (CDA) is document-based, which means that in order to retrieve information, such as a patient’s allergies, an entire document (or more) must be retrieved and parsed. Whereas in FHIR, a simple query will return just the allergies (or any other requested information). In fact, FHIR can easily retrieve data for multiple patients at one time as opposed to the current standard’s by-patient queries. Every major HIT vendor has embraced new FHIR-based offerings and/or has “FHIR-enabled” their existing offerings. By utilizing FHIR, vendors can expose standardized health data and functionality, thus enabling the use of innovative “apps” that can enhance the functionality of underlying systems. For example, a team of diabetes specialists can create an app that incorporates best-practice treatment regimens into a physician’s work flow by pulling out the necessary data from the physician’s Electronic Health Record (EHR). Theoretically, this same app could run on top of multiple EHR systems, thus eliminating the need for customized codes for each EHR and reducing costs to the end user. In reality, that is not how things automatically work under the hood of the FHIR ‘car’ right now in the real world where large EHR vendors cannot be dictated to. Everyone assumes this though.


FHIR is in its essence is only a general methodology for transmitting electronic messages with clinical data. Pervading the HIT ecosystem is a lack of understanding of the gargantuan levels of details which must be in precise alignment for interoperability to occur and be maintained. Maintaining interoperability requires constant vigilance and constant testing. It is wishful thinking that we have arrived at a solution, but we are no doubt light years ahead of where we were 5 years ago. FHIR is at the center of many trends that hope to revolutionize HIT, ultimately rendering the underlying EHR in the long term as a homogeneous commodity upon which an ecosystem of dozens of disease-specific or specialty-specific apps provide the clinical work flow and user experience. But for today, we are still faced with the slow and tedious work of ensuring interoperability between different EHR systems which may all be using FHIR but in a different way. It must be remembered that FHIR is only an international standard, and a very flexible one at that. It is no more a cure for data silos, than eating a paper prescription is a cure for a disease. Let’s restate this as saying that walking into a grocery store does not automatically get your dinner cooked and on the table. A lot more work is involved to pick out the right ingredients, get them properly cooked and have them taste good. Similarly, using FHIR does not make one interoperable.


FHIR is not a magic bullet, and some of the features that form FHIR’s strengths also form its weaknesses. For example, while FHIR has been rapidly evolving, current iterations of the FHIR standard are not backwards-compatible with its own previous versions. Beginning with FHIR Release 4, some portions of FHIR will be considered normative, meaning that any changes to those portions must be backwards compatible. Until that time, however, changes between versions have been substantial. Additionally, while FHIR has been implemented worldwide, , more changes are forthcoming. Lastly, FHIR purposely does not attempt to handle all use-cases, relying instead on extension mechanisms that result in implementers having multiple ways of doing the same thing. Different implementers will extend FHIR differently, making interoperability a challenge. Even very slight differences, such as a lack of dashes in a social security number, or an unknown local code will cause problems. It is clear that in order for FHIR to succeed, a US organizational body, such as the HHS ONC, must define standard interoperable methods for FHIR extension at the implementer level so that FHIR’s weaknesses do not disillusion its user community. The US FHIR Core projects still holds hope for establishing a body of assumptions which can produce interoperability between different US based EHR systems. See this HL7 web site for the official set of guidelines http://hl7.org/fhir/us/core/. This Implementation Guide is published by the HL7 US Realm Steering Committee. Going beyond defined HL7 standards for individual clinical electronic messages, the Trusted Exchange Framework and Common Agreement (TEFCA) also holds promise. In the 21st Century Cures Act (Cures Act), Congress identified the importance of interoperability and set out a path for the interoperable exchange of Electronic Health Information. Specifically, Congress directed ONC to “develop or support a trusted exchange framework, including a common agreement among health information networks nationally.” This voluntary standard coordinated by the ONC can be seen here: TEFCA. This article on TEFCA in a Nutshell describes that TEFCA’s goals is “… to establish a single “on-ramp” for HIE that will enable providers, hospitals and other healthcare stakeholders to join any health information network (HIN) and then to automatically connect and participate in nationwide health information exchange.”





J P Systems Twitter


We are #HealthcareIT interoperability architects for large enterprises, UML data modelers, use case developers, business logic analysts and #HL7 messaging standards developers.