Most people in healthcare have heard of Health Level 7 (HL7), but not all could also be at home with it on a super-technical level. Still, most of them might not know the use of HL7’s for interfacing different healthcare-related systems, which they’d only want to implement software that’s HL7-compliant.
Fast Healthcare Interoperability Resources (FHIR) may not be as well-known, while it’s been around for years. But now, there’s much-renewed interest in FHIR, especially since it was recently adopted and promoted by no but Apple and CMS as their preferred healthcare interface mechanism.
Perhaps the primary thing to understand is that FHIR is a branch of HL7. So, there is not any competition intrinsically 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 securely attach and manage their clinical records.
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 long run of healthcare technology could resemble the kind of integration that already exists outside of healthcare, like in social media news feeds.
Instead, HL7 interfaces would wish to be written by a programmer or programming team to attach the systems that require interfacing. And then, interfaces have to be supported and maintained to confirm their integrity. So, FHIR removes the complexities of “traditional” EHR interfacing.
For instance, health information exchanges (HIEs) lost steam as a possible solution for seamlessly exchanging patient health information. Instead, the FHIR app/API method can enable communication between multiple sources like EHRs, mobile applications, devices, and more.
That’s because, in general, APIs provide an even, public interface enabling authorized applications to receive and send data with the right security authentication. It is the difference between breaking down a locked door with an ax vs. having the key.
HL7 developed FHIR, specifically with EHRs in mind. FHIR’s sole reason to exist is to create EHRs that are FHIR-compatible and specific to other healthcare applications, easily interoperable. to urge a touch technical, FHIR 4 could be a draft standard describing data formats and elements or “resources.”
A recent JASON (CMS) taskforce report named FHIR the simplest candidate for its API approach.
It even noted that FHIR should be a part of the compliance criteria for stage 3 meaningful use (MU). It certainly seems FHIR is on course to become a regular, or perhaps the quality, in healthcare API interoperability. And with HL7’s provenance within the healthcare interface arena, FHIR seems sure to become a successor to any EHR user and patient who has data within the EHR.
