The Strengths and Weaknesses of the HL7 FHIR Messaging Standard
Healthcare IT Data Standards: FHIR
Health Level Seven’s (HL7) Fast Healthcare Interoperability Resources (FHIR) is a new interoperability 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 Versions 2, 3 and Clinical Document Architecture (CDA). Regardless of the version of HL7 standard used, the purpose of these standards is to share clinical data, whether with parties inside or outside your organization. HL7 devises flexible, expressive 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 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 significant number 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 U.S. 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 make a patient’s health record accessible to any stakeholder the patient authorizes, with little technical effort. Such a record could support an ecosystem of dozens of disease-specific or specialty-specific apps, enabling the clinical workflow and user experience. But for today, we are still faced with the tedious work of developing the needed Implementation Guides for each domain of interest.
It must be remembered that FHIR is only a data standard, and a very flexible one at that, but it is not a software app. Singularly, 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, diced, cooked and seasoned. Similarly, just designing one FHIR message does not make one interoperable. At an absolute minimum it takes a plan written down in an IG, work on the data quality problems and ongoing testing.
HL7 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 allow designers to defer complex domain or realm-specific issues to stakeholder-defined IGs. This flexibility can result in implementers having multiple ways of doing the same thing. Different implementers may very well unknowingly 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 may 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.
In HL7 Version 2 (V2), the ability to tweak the base standard with local requirements in additions called “Z segments” seriously diluted the ability of business partners to rely on the standardization that V2 promised. This was the primary reason that HL7 in the version 3 architecture tried to build a model that could accommodate any conceivable need, (an effort that failed for reasons that seem obvious in hindsight). Once version 3 was largely set aside, FHIR was designed to overcome previous failures in interoperability. FHIR is achieving market penetration comparable to that of V2, but in many more domains, due partly to adoption of the extension mechanism. As useful as that mechanism is, it threatens to reproduce the key pain points from V2. It will be of critical importance for teams to commit to open communication, publication of designs, reuse, and repudiation of the not-invented-here syndrome if they are to avoid that pain.
In the 21st Century Cures Act (Cures Act), [JL1] 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 the Trusted Exchange Framework and Common Agreement (TEFCA). 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.”
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.
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 a 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.
For help with your Healthcare IT Informatics project, contact us at 1 703 926-5539 or email us at Sales@JPsys.com.