The Strengths and Weaknesses of the HL7 FHIR Messaging Standard

Healthcare IT Data Standards: FHIR

Jackie MulrooneyIt 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 HL7 Version 2, 3 and Clinical Document Architecture (CDA). Regardless of the version of HL7 standard used, the purpose of these standards is to send clinical data in messages, whether to a party inside or outside your organization. HL7 devises flexible message formats so the receiver of the message can open it up, know who sent it and why, and break it down into understandable segments and data fields.

Electronic Health Records (EHR) systems vendors such as Allscripts, Cerner and Epic, are already rapidly adopting FHIR. The FHIR standard can be specified 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 CDA standard 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. In contrast, with FHIR, a simple query will return just the allergies (or any other specifically requested information). In fact, FHIR can easily retrieve data for multiple patients at once, as opposed to the other standard's patient-by-patient queries.

Every major Health IT 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 applications, "apps," or API's, that provide new functionality to vendor EHR systems. For example, a team of diabetes specialists can create an app that incorporates best-practice treatment regimens into a physician's workflow by pulling out the necessary data from the physician's Electronic Health Record (EHR).

Theoretically, this same app with slight modifications, could run on top of multiple EHR systems, thus eliminating the need for customized development for each EHR and reducing costs to the end user as every EHR system installation would not have to reinvent the wheel. They could share tires, so to speak, in a library of APIs functions.

FHIR is in essence only a general international methodology for transmitting electronic messages containing clinical data. There is a lack of understanding in the health IT ecosystem of the gargantuan levels of details which must be kept in precise alignment for interoperability to be successfully maintained. Maintaining interoperability requires constant vigilance and testing. Great progress has been made in the last 3 years. In order for the FHIR standard to work it must first be "standardized" for a particular group of users in a guide book called an Implementation Guide or IG. Fortunately the U.S. has moved towards this by defining the USDI FHIR Core.

FHIR is at the center of many trends that are revolutionizing health information technology One of the key long term goals is to ultimately render the underlying EHR as a homogeneous commodity upon which an ecosystem of dozens of disease-specific or specialty-specific apps provide the clinical workflow and user experience. But for today, we are still faced with the slow and tedious work of developing the needed Implementation Guides for each domain of interest.

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 put a hot cooked meal on the dinner table. A lot more work is involved to pick out the right ingredients, get them home, sliced, properly cooked and seasoned. Similarly, just designing one FHIR message does not make one interoperable. At an absolute minimum it takes an IG, rework on the data quality problems and ongoing testing.

L7 FHIR boils down to a high level way of specifying the data fields and their expected contents to be sent in a message. FHIR is not a magic bullet or even a piece of software. It is a large set of generic specifications which are used just like blueprints to build something specific. In addition, while FHIR has been implemented worldwide, more changes of many types will always be forthcoming as it evolves. As part of the design, FHIR purposely does not attempt to handle all use-cases. Instead it relies 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 became clear that in order for FHIR to succeed, a U.S. organizational body, such as the Office of the National Coordinator for Health IT (ONC), must define standard interoperable methods for FHIR extension at the implementer level. The US FHIR Core project has established a body of assumptions which can guide interoperability efforts between different U.S. based organizations. See this HL7 web site for the official set of guidelines https://www.hl7.org/fhir/us/core/. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide.

Going beyond defined HL7 standards for individual clinical electronic messages, the Trusted Exchange Framework and Common Agreement (TEFCA) is also being developed successfully. 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 led to TEFCA. This article on TEFCA in a Nutshell describes that TEFCA's goal 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."

TEFCA was released on April 19, 2019 and outlines a common set of principles, terms, and conditions to support the development of a Common Agreement that would help enable nationwide exchange of electronic health information (EHI) across disparate health information networks (HINs). An article on national interoperability frameworks can be seen on the ONC website HealthcareIT.gov. In May 2020 it was announced that the public-private partnership between ONC and Sequoia Project would be extended as work on TEFCA continues. The planning for interoperability starts with an organization agreeing to the TEFCA Common Agreement, which is a contract creating the basic legal and technical requirements for allowing network-to-network connectivity for Health Information Networks (HINs). A QHIN is a Qualified HIN, a network of organizations working together to share data.

John Rancourt

The Recognized Coordinating Entity (RCE) will administer TEFCA. TEFCA consists of two parts: the TEF and the CA. The Trusted Exchange Framework, TEF, is a set of nonbinding, foundational principles - such as standardization, transparency, access, population level data and security - for facilitating trust between health information networks, explained John Rancourt and other panelists during the HIMSS Talk: A Journey to Trusted Exchange. The CA refers to the Common Agreement which described the governance necessary to scale TEFCA. The proposed overall architecture is a "network of networks" which will allow stakeholders the opportunity to participate as Participants, Participant Members, or Individual Users. The Common Agreement furthermore promotes a public/private partnership with HHS, and will administer three layers of governance necessary to scale the proposed system of connected HINs and QHINs.

The Healthcare IT ecosystem agrees that COVID-19 has played a role in highlighting the importance of seamless data sharing. Data must move at the speed of care! Investments in data quality analysis and improvement, ongoing interoperability testing of HINs and infrastructure continue to show value. FHIR IGs are a major focus now to allow for automated pulling of uniform, normalized data built from standardized reference terminologies from EHRs.

This post was originally published in the JPSys.com blog. It is reprinted by Open Health News with permission.