Contact Our Experts
A few years back, at one of the big HIMSS conferences, representatives from HL7 were socializing a new interoperability standard proposal called RIM V3 that was supposed to replace the old HL7 V2.x. The discussion following the presentation turned heated, transforming the gathering from a meeting of typically calm healthcare technologists into a scene reminiscent of a session in the British Parliament. In an attempt to be all-encompassing, HL7 designed RIM V3 as a highly diverse and complex model. Ironically, this approach failed to satisfy everyone or address all use cases. Needless to say, RIM V3 has never enjoyed a wide adoption.
HL7 V2.x on the other hand has been in use since the 70s. It is a very straightforward record-based, delimited message format that is easy to understand and fairly easy to implement. However, there are a few issues with HL7 V2.x. It is not strict and is open to interpretation. Every major vendor had their flavor of the protocol that they supported. Consequently, integration with each system was different, even for the same messages within the same version of the protocol. HL7 V2.x is not exciting by any means. Try forcing a new college CS graduate to build HL7 V2.x interfaces, and they will quit in a few days. The job of building such interfaces, therefore, has always been relegated to bold silver-bearded men who quoted Yogi Berra and gorged on root beer. There have been several other problems with HL7 that warranted an imminent replacement,
There have been numerous attempts to find a viable alternative to HL7 V2.x. In 2012 a small team in Australia led by Graham Grieves, instead of trying to model the entire world (like RIM V3 did), created a relatively limited protocol focused on core healthcare data types, called “resources”. This new protocol was built on Internet standards and technologies already used by industries outside of healthcare. It is rooted in web standards such as XML, JSON, HTTP, and OAuth and can co-exist and leverage those earlier standards.
The protocol eventually became FHIR - Fast Healthcare Interoperability Resources. FHIR went through several iterations before publication as a Draft Standard for Trial Use in 2014.
To gain industry acceptance, any interoperability standard must first be adopted by major EHR vendors. By 2015, The Argonaut Project, which included major EHR vendors such as Cerner, EPIC, AllScripts, and Athenahealth, and health systems such as Mayo Clinic and Intermountain, brought FHIR to the mainstream. Eventually, FHIR adoption spread across various EHRs, the U.S. government, Apple, Microsoft, Google, and other technology powerhouses.
FHIR was originally conceived to be expressed in multiple forms, but the one that enjoys the most popularity and adoption is the REST API with JSON representation as a payload. From 49 original resources, FHIR has grown into 150+ supported resources and continues to expand. It brings together and enables multiple other standards and technologies such as SMART on FHIR, CDS Hooks, and others.
One of the key benefits of FHIR is that each resource can be more or less independently used and developed. Each resource is individually maintained and versioned, with “Maturity Levels” assigned to them to indicate how reliable a given component is for use. There is now consensus that the FHIR 4 release is ready for wide-scale adoption.
There is another new exciting direction, beyond systems interoperability, that FHIR standard and its underlying technologies are taking.
Since the dawn of the Electronic Healthcare Record systems (EHR), we’ve been accumulating a wealth of healthcare data that is invaluable and usable for many purposes - such as operational and payor analytics, population health management, care quality improvements, clinical research, and others. As one of the examples, Real World Evidence (RWE) research that predominantly relies on healthcare data alone, greatly accelerates clinical trials and studies. The challenge is - nearly all of the patient and provider data resides within EHR systems in their proprietary formats. To expose and use this data outside of the EHR and other systems, research communities and consortiums are formed to develop and support Common Data Formats (CDMs). The rationale for CDMs is simple - in the majority of cases, there is not enough patient data in individual institutions that match the eligibility criteria for a specific clinical trial or study. By standardizing on representation of clinical data and exporting it in the same format, researchers can conduct eligibility queries and find patients across multiple institutions.
Many CDMs have evolved over the years for different purposes and different reasons: examples include i2b2, CDISC, PCORINet, OMOP, and others. The mere presence of multiple such CDMs creates fragmentation in the communities and creates unnecessary overheads.
The issue with CDMs is not limited just to the presence of multiple competing standards. To populate a CDM repository, clinical data needs to go through the ETL (Extract Transform Load) process from EHR systems. Building a high-quality ETL data pipeline is complex, requiring significant engineering and medical informatics expertise, knowledge of multiple data standards, and understanding of coded medical terminology domains. The work is laborious and the data extraction processes are slow and resource intensive.
There is a fast-growing interest in FHIR as a new and ubiquitous CDM. After all, if EHR systems can serve FHIR data natively, why not store and use clinical data persistently as FHIR resources, in the same format the data is coming out of the source systems? Virtually no ETL is required. Well, almost.
More and more healthcare institutions, CROs, Pharma, and research organizations chose to store and operate on clinical data in FHIR repositories. FHIR was predominantly designed as an interoperability standard and not exactly suitable for persistent and efficient storage. It lacks referential integrity, and JSON format is not easy to query.
Multiple high-profile players are developing technologies to make FHIR more suitable for persistent storage and usage. For example, InterSystems has implemented its SQL to FHIR exposure in its IRIS for health products. Health Samurai has developed specialized database technologies for native and efficient FHIR storage and retrieval. Just about every major technology vendor involved in healthcare is implementing some capabilities for FHIR persistence.
It is too early however to declare FHIR’s dominance as a CDM. Numerous institutions, research organizations, CROs, and Pharma have invested heavily in existing CDMs. These CDMs boast richer data support, accommodating a wider range of data types compared to FHIR. There are whole ecosystems of tools and applications that have been built for major CDMs. FHIR is catching up fast, but it will take a few years before it can become a viable alternative or a replacement for established CDMs.
FHIR is in a state of rapid evolution and adoption. In 2021, 24% of institutions worldwide reported a transition to FHIR API, while 67% of providers and 61% of payers utilized FHIR APIs at scale in 2023. Far greater adoption is expected in 2024. There are still significant limitations to address. The underlying data stores prevent the cloud vendors from implementing desired features, such as advanced search (text, filter, named query), and transaction capabilities.
The future of FHIR is taking shape in many forms. The Centers for Medicare & Medicaid Services are analyzing how to most effectively transition to FHIR quality measurements. However, the federal agency is still in the research and testing stages of moving towards FHIR as the electronic clinical quality measure (eCQM) standard.
FHIR and Generative AI are a match made in heaven. Generative AI models can evolve to generate FHIR® documentation or profiles. We often want to ensure that the data sets we use are FHIR compliant, and we can use AI to generate custom schematic formats with added elements to maintain compliance.
Our Clinovera team has built an AI-based patient eligibility query tool that uses free-form natural language and operates on raw FHIR data from EHRs. It translates unstructured human requests into structured queries against FHIR resources.
Of course, we can only speculate about the future of this powerful standard. But one thing is certain, even today FHIR is already a lingua franca of modern healthcare with many more exciting applications and use cases yet to come.
Authored by Anatoly Postilnik, Managing Director.