Enabling the seamless exchange of healthcare data among applications and systems is vital for realizing the full benefits of electronic health information. But for decades, data remained trapped within proprietary systems. To share information, providers, payers, and patients often had to fall back on old, time-consuming methods, from faxing chart notes to manually sharing paper-based documents.
The seeds for change were planted more than 30 years ago. In 1987, experts in technology and medicine founded Health Level Seven International (HL7)—a not-for-profit organization dedicated to developing standards for exchanging, integrating, sharing, and retrieving electronic health information. Today this organization is a leading provider of interoperability standards for medical information systems.
Over the years, HL7 has produced several standards to facilitate the exchange of healthcare information, including HL7 Version 2 and the Fast Healthcare Interoperability Resources (FHIR) standard. Though HL7 V2 and FHIR (pronounced “fire”) were created by the same organization and share some common goals and capabilities, they are distinct standards. Examining the differences between the two can help you understand the advantages of adopting FHIR.
What is HL7 V2?
Originally released in 1989, HL7 V2 became one of the most widely implemented healthcare standards across the globe. According to HL7, 95 percent of U.S. healthcare organizations today use a version of this standard. In 2005, HL7 released HL7 V3—a new, non-backward-compatible standard—to address some shortcomings of V2. But by far fewer organizations in the United States currently use V3.
HL7 V2 works by providing a language for communication among distinct systems, such as electronic medical record (EMR) systems, hospital information systems, radiology and picture archiving systems, laboratory information systems, billing systems, and more. That language comprises ASCII text–based messages. Systems transmit messages to one another when a patient is admitted to a hospital, a doctor places a pharmacy order, a provider bills a patient, or there is another important event.
By creating a way for distinct systems to communicate, HL7 V2 has helped organizations avoid some of the complex, customized software development work previously required to build interfaces. Still, because the standard was designed to be highly flexible and customizable, it still leaves a decent amount of work for developers. For example, HL7 V2 lacks an explicit model for messages, a semantic framework, and a methodology for building messages. Without precise definitions and specifications, HL7 V2 requires organizations to rely heavily on custom coding and the use of interface engines to achieve interoperability.
The HL7 V3 standard was designed to overcome some of the limitations and challenges of V2. Instead of the loosely defined framework of V2, HL7 V3 is a stricter standard that predefines more of the interface. But its extensive specifications and lack of backward compatibility add substantial time, cost, and complexity to implementation. As a result, it has not been widely adopted.
What is FHIR?
In 2014, HL7 introduced an important alternative to HL7 V2 and V3 standards: the Fast Healthcare Interoperability Resources (FHIR) standard. FHIR, which was first drafted in 2011, is an open standard that enables new apps and legacy systems to more easily exchange data than in the past. FHIR was developed to not only improve interoperability and enhance efficiency of communication but also streamline implementation compared with previous standards, providing easily understood specifications and enabling developers to capitalize on common Web technologies.
FHIR builds on previous standards, including HL7 V2, HL7 V3, and CDA (Clinical Document Architecture—part of HL7 V3). But unlike those other standards, FHIR employs RESTful web services and open web technologies, including not only XML (used by previous standards) but also JSON and RDF data formats. These technologies should be familiar to most developers, reducing the learning curve compared with other standards.
FHIR also offers multiple options for exchanging data among systems. For example, it supports messaging (similar to HL7 V2), documents (like CDA), as well as a RESTful API approach. The RESTful API approach can simplify data sharing and reduce the time to onboard new data exchange partners by replacing point-to-point interfaces with one-to-many interfaces. This approach offers the potential for greater interoperability among a wide array of systems and devices—including not only electronic health record (EHR) systems but also mobile apps, mobile devices, medical devices, and wearables.
FHIR defines the meaningful pieces of data that are stored or exchanged as “resources” (which are somewhat similar to “segments” within HL7 V2 messages). A resource can include metadata, text, or bundled collections of information that form clinical documents. Each resource has a unique identifying tag, just like a web page URL. That tag makes it easy for devices and applications to access required data without complicated data exchange processes. The RESTful API approach also enables resources to be updated and deleted.
FHIR is inherently suited for mobile apps. With FHIR, APIs can access required data from multiple systems and provide that data in formats that developers can easily integrate into their mobile apps. And with FHIR, that data can be shared rapidly (which is critical for mobile apps) since only the requested data is transmitted.
There has been clear momentum for using FHIR for mobile healthcare apps. In 2014, the SMART (Substitutable Medical Apps, Reusable Technologies) Health IT project created the SMART on FHIR API to enable developers to write an app once and run it anywhere in the healthcare system. And in 2018, Apple created a FHIR-based health records feature for its iOS operating system, giving users simple access to a range of healthcare information from hundreds of participating providers.
Why adopt FHIR?
FHIR can help facilitate information sharing, simplify implementation, and better support mobile apps. It also supports important use cases that benefit providers, payers, and patients.
Clinicians can more efficiently share patient data among teams to speed decision-making. Insurance companies can supplement claims data with clinical data to better assess risks, drive down costs, and improve outcomes. And patients can take greater control of their health by accessing medical information through consumer-friendly apps running on smartphones, tablets, and wearables.
All of these benefits are good reasons for adopting FHIR. But many organizations do not have a choice. In 2020, the U.S. Centers for Medicare & Medicaid Services (CMS) finalized a mandate for the use of FHIR by a variety of CMS-regulated payers and providers beginning in mid-2021. (See the CMS Interoperability and Patient Access final rule and the Office of the National Coordinator [ONC] Cures Act Final Rule for more information.)
FHIR vs HL7: Main differences.
The main difference between FHIR and HL7 is in the underlying development technologies. FHIR relies on RESTful web services and open web technologies, such as JSON and RDF data formats. Because developers are familiar with these technologies, FHIR minimizes the learning curve, allowing them to get to being productive more quickly.
Other advantages include:
- A RESTful API approach facilitates data exchange by introducing one-to-many interfaces.
- Interoperability is improved between EHR systems as well as mobile apps, mobile devices, and wearables.
- The API standards implemented in FHIR streamline data exchange and reconcile the processing of information received in different formats. This allows more in-depth processing and makes it easier to extract contextual information from the data sources.
- FHIR categorizes data elements as resources which each incorporate the collected information contained in medical documents. Resources have unique identifiers that enable access to the data without implementing comlex data exchange procedures.
Addressing the challenges of adopting FHIR
The FHIR standard has some clear advantages over previous standards, including the widely adopted HL7 V2. But even if organizations are still on the fence about FHIR implementation, the government mandate to adopt FHIR should propel many to move forward.
If your organization plans to adopt FHIR, just be aware that you still face some important implementation decisions and some potential challenges. For example, though FHIR was meant to simplify implementation, undertaking an in-house FHIR implementation could nevertheless require learning new skills. And building an interface or app is just the first step—your team will still need to manage and scale a backend FHIR service in the future, which might involve managing new infrastructure.
Building a FHIR-based service in the cloud could help overcome adoption hurdles. With the right cloud implementation, you could accelerate provisioning, customize the implementation by integrating cloud-based services, and gain sufficient scalability for the future—all while controlling costs.
Learn how using FHIR Works on AWS can help you simplify adoption of FHIR. Read the white paper, “Are you ready for FHIR? - speed adoption of the new data exchange standard with FHIR Works on AWS.”
