Most people in healthcare have heard of Health Level 7 (HL7) but not all may be familiar with it on a super-technical level. Still, most at least know HL7's needed for interfacing different healthcare-related systems, and that they'd only want to implement software that is HL7-compliant.
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") might not be as well-known, even though it has been around for years. But now, there's much-renewed interest in FHIR, especially since it was recently adopted and promoted by no less than Apple and CMS as their preferred healthcare interface mechanism.
Both FHIR and HL7 are crucial to the future of electronic health records (EHR). This article helps explain each, and why your EHR-eye should be on FHIR.
What is FHIR, and how does it differ from HL7?
Perhaps the first thing to know is that FHIR was created by HL7. So, there's no competition per se between each interface utility or between rival companies.
Apple and CMS brought FHIR to light by launching FHIR's patient-centric mobile solutions app, which empowers patients to connect and manage their clinical records securely.
With the FHIR app, patients can use their iOS devices to quickly check things as diverse as their eligibility for preventative care visits, to the status of any outstanding claims. Patients can "pull" their charts from any organization to which Apple and CMS are connected.
The powerful combination of the FHIR application programming interface (API) and web services means the future of healthcare technology could resemble the type of integration that already exists outside of healthcare, such as in social media newsfeeds.
With HL7, there's no app, and there's nothing to download. Instead, HL7 interfaces would need to be written by a programmer or programming team to connect the systems that need interfacing. And then, interfaces need to be supported and maintained to ensure their integrity.
So, FHIR removes the complexities of "traditional" EHR interfacing. For example, health information exchanges (HIEs) lost some steam as a possible solution for exchanging patient health information seamlessly. Instead, the FHIR app/API method better enables communication between multiple sources such as EHRs, mobile applications, devices, and more.
That's because, in general, APIs provide a standardized, public interface enabling authorized applications to receive and send data with the proper security authentication. It's the difference between breaking down a locked door with an ax vs. having the key.
FHIR's EHR advantage
HL7 developed FHIR, specifically with EHRs in mind. FHIR's sole reason to exist is to make EHRs that are FHIR-compatible, and specific other healthcare applications, easily interoperable. To get a little technical, FHIR 4 (currently in its fourth iteration) is a draft standard describing data formats and elements or "resources."
Being SMART about FHIR
FHIR is smart in two ways.
As we just saw, it's smart in terms of how well it facilitates interoperability with EHRs and related healthcare applications.
It's also SMART (another acronym) on something called "Sustainable Medical Applications, Reusable Technologies" which is an open, standards-based technology platform enabling healthcare app creators to interconnect their systems across the healthcare spectrum.
When an EHR supports the SMART standard through an app such as FHIR, patients, doctors, and healthcare practitioners can draw on it to improve clinical care, research, and public health.
At the same time, SMART supports a powerful authorization model for apps based on the OAuth standard which, in turn, supports patients and providers remaining in control of their data.
Lastly, the SMART platform is composed of open standards.
What are Open Standards?
As applicable to healthcare technology, open standards support connectivity across systems without requiring any specialized knowledge about the systems to be connected.
Open standards encompass open-source tools for developers in building apps and a publicly accessible app gallery. SMART/open standards applications are being used to provide clinical care at healthcare institutions such as Boston Children's Hospital and Duke Medicine.
The Future of FHIR
A recent JASON (CMS) taskforce report named FHIR the best candidate for its API approach.
It even noted that FHIR should be part of the compliance criteria for stage 3 meaningful use (MU). It certainly seems FHIR is on track to become a standard, or perhaps the standard, in healthcare API interoperability. And with HL7's provenance in the healthcare interface arena, FHIR seems bound to become a best friend to any EHR, and to any EHR user and patient who has data in the EHR.
The MedicsCloud EHR from Advanced Data Systems has been HL7 and FHIR compatible for over twenty years. To learn more, watch our free MedicsCloud demo.
Key Takeaways
-
Two of the major stumbling blocks to having clean interoperability between EHRs are apparent: (1) there are a lack of standards for disparate EHRs to communicate, and (2) the expense and time involved in creating needed interfaces between EHRs.
-
It would be invaluable to have unique patient identifiers so that the patients can be associated with their correct information across an enterprise or system-wide spectrum.
-
APIs such as FHIR appears as one of the best avenues for overcoming these interoperability roadblocks.
-
One of meaningful use's reason for existing was to get EHRs talking to each other. FHIR now seems to be the utility for accomplishing that.