Even without the current patient centricity expectations, modern healthcare systems could hardly function without efficient data exchange mechanisms in place. From the moment people decided to entrust digital systems with medical data, the need for data circulation has only become increasingly obvious, be it for patient care, research, or administrative purposes. FHIR is the latest widely adopted standard that’s emerged to facilitate the exchange of information in healthcare, a true heir of the previous HL7, but allowing for better flexibility.
Health Level Seven has long stood for the very notion of responsible data exchange standards in healthcare; FHIR being its latest incarnation, it’s now commonly opposed to the more familiar HL7 V2. While both aim to streamline the sharing of healthcare information, they differ significantly in their approach and capabilities. In this post, we will look at some key differences between FHIR and HL7, exploring their histories, features, and future prospects. We will also provide guidance on when to choose FHIR over the traditional HL7 V2 standard.
What is FHIR?
FHIR (Fast Healthcare Interoperability Resources) is this decade’s leading standard for exchanging healthcare information between software systems. Created by none other than HL7 International, FHIR combines the best features of HL7’s Version 2, Version 3, and CDA (Clinical Document Architecture) while leveraging the latest web technologies to ensure simplicity, flexibility, and ease of implementation.
While today’s discourse tends to compare HL7 and FHIR as if they are somehow opposite notions, it’s not quite the case. By “HL7”, in this context, specialists usually mean HL7 V2, the standard that’s still widely used in multiple legacy systems. FHIR, on the other hand, is the newer standard developed by the same authority, but better in that it uses RESTful APIs for improved data exchange; among other things, RESTful APIs allow for one-to-many approaches in integration, essentially meaning the unified format of data transmitted by one system can potentially be supported by other systems.
History of healthcare data exchange
When healthcare data exchange began long ago, way before “digital” meant anything other than the literal digits of the human hand, there were already conflicts between local languages (solved with Latin) and security concerns (solved with the notoriously difficult-to-read handwriting that only real apothecaries could decipher). With the advent of computers and mobile apps, these two age-long problems were reincarnated, as well.
The actual evolution of healthcare data standards began with HL7 Version 2 (V2) in the late 1980s. The now classical HL7 V2 was designed to enable various healthcare systems to communicate effectively. Despite its widespread adoption, HL7 V2 has been criticized for its complexity and lack of consistency. As a “millennial fad”, in the early 2000s, HL7 Version 3 (V3) was introduced to address these issues, and it wasn’t that bad in principle, what with featuring a more rigorous data model and a well-formalized methodology. However, implementing V3 was often harder than could be justified in business terms: the majority silently voted for ignoring the standard and sticking with V2 instead.
The Clinical Document Architecture (CDA) was another attempt to standardize healthcare information exchange, focusing on document-based data sharing. While CDA provided a structured format for clinical documents, it did not fully address the need for real-time data exchange and integration, so by the time mobile apps on smartphones became ubiquitous, CDA was no longer an option to, say, exchange data between ERs and insurers, etc.
Finally, in 2011, HL7 International developed FHIR. This new standard was designed to be a simpler, more flexible, and developer-friendly standard, capable of leveraging JSON, XML, and, as mentioned, RESTful APIs.
Differences between FHIR and previous HL7 standards
What makes FHIR different from the previous HL7 standards is the underlying architecture. HL7 V2 relies on a message-based approach, meaning there are predefined “message types” through which the data is sent and recognized. Meanwhile, FHIR uses a resource-based approach, where data is represented as modular, reusable components aka “resources.” For example, there can be a “Patient” resource that includes fields for name, date of birth, gender, and contact information. When a healthcare application needs to access patient data, it can use the “Patient” resource, and will find all of that information in a standardized format.
Similarly, other resources like “Observation” (lab results), “Medication” (prescriptions), and “Appointment” (scheduling) can be used in their respective contexts, ensuring consistent and reliable data handling.
Another key difference is that FHIR is oriented toward today’s web technologies. FHIR leverages RESTful APIs, enabling seamless interaction with web-based applications. This makes FHIR more accessible to developers familiar with web development, reducing the learning curve and accelerating implementation.
Unlike V2, FHIR is not restricted to a single encoding syntax and supports one-to-many data exchanges. It also provides advanced security features and reduces the time needed for implementation. In essence, FHIR simplifies the adoption of healthcare interoperability. Vendors can more quickly integrate third-party applications, enabling them to function cohesively.
Additionally, FHIR supports a wide range of data formats, including JSON and XML, making it compatible with contemporary web standards. HL7 V2, on the other hand, primarily uses a custom delimiter-based format, which can be more challenging to work with.
Implications of FHIR
Now that FHIR has been around for a while, what are the implications for the healthcare industry? In reality, the standard is not so much a disruptor as it is an enabler: the underlying demand for interoperability had been present for a while before FHIR was ever a thing, so the implications are that now healthcare software can finally implement the stuff that’s been declared for a decade or so. This involves using digital tech for improving patient care, reducing administrative burdens, and facilitating innovative health solutions through a flexible, resource-based architecture.
Why was FHIR developed?
FHIR was developed as a response to the complexities and limitations of the previous HL7 standards. For instance, with FHIR, a mobile app can pull real-time lab results from an EHR system without compatibility issues. At the same time, a medication resource within one application can be reused in another without the need for someone to step in and manually reenter things.
What will change with FHIR in the near future?
- In short: the healthcare software market will become livelier (it’s already getting more agitated). The adoption of FHIR is by now also driven by regulatory mandates and industry initiatives aimed at enhancing interoperability. The U.S. Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC) have already mandated the use of FHIR-based APIs to promote patient access to health data.
All this will likely lead to the proliferation of new healthcare applications that leverage FHIR’s capabilities. In brief: while before FHIR, developing a startup app idea based on an “interplay” between multiple systems would require more investment, and hence, a higher threshold for “passing”, now the consumerization of healthcare is going for full swing. One more or less obvious example would be mHealth apps, telemedicine platforms, and (spurred by the early 20’s COVID situation) population health management tools.
Moreover, the use of FHIR can enhance research by facilitating the aggregation and analysis of diverse data sources, meaning the adoption of AI/ML for things like epidemiology will become the norm. Researchers can more easily access and integrate data from electronic health records (EHRs), clinical trials, and other health information systems, driving advancements in precision medicine and other fields.
A final outcome will be an increase in collaboration between HCPs, payers, and tech companies. In practice, this means the proliferation of startups that connect them in this way or another (depending on the target region or country), all of them driven by the ultimate goal of convenience for the patient. One of the mandates of patient centricity is to let the patient think more of their life beyond their condition and less about the condition itself; FHIR is an instrument to get there.
When to choose FHIR over HL7 V2?
As with every newer technology, there’s a dilemma of whether to go for the universally recognized standard or adopt the better one. The question is essentially whether it’s FHIR or HL7 V2, and it largely depends on your organization’s needs and goals in a roughly 4-year perspective. If you require a high degree of interoperability and flexibility, FHIR is likely the better choice. Its modern architecture, use of web technologies, and extensive resource set make it well-suited for integrating with diverse healthcare systems and supporting innovative applications.
FHIR is also a strong choice if you are developing conceptually new applications or modernizing existing ones to be able to hold up against the emerging competition. FHIR is developer-friendly, meaning its strong side is its compatibility with contemporary web standards. Also, seeing as how with FHIR, healthcare software development is likely to get cheaper, your solution is likely to benefit a lot from the added interoperability. Regulatory compliance is no longer a concern here, either: FHIR’s alignment with recent mandates makes it a future-proof option.
However, if your organization already has a well-established HL7 V2 infrastructure and you only need to maintain existing integrations, sticking with HL7 V2 may be more practical in the short-term perspective. Transitioning to FHIR can require varying levels of actual investment depending on what exactly it is you’re trying to achieve, so it’s important to weigh the benefits against the costs and potential disruption.
You can learn more about Lionwood.software’s experience in implementing FHIR-based healthcare projects by contacting our experts at any moment.
