FHIR has taken the healthcare industry by storm. Health plans are rushing to incorporate FHIR into their systems to not just evade penalties but also to attain the end goal of affordable, easily accessible healthcare and healthcare data.
In the previous two blogs, we have discussed the origin of FHIR, the need for FHIR, as well as what it entails. Here we shall take a deeper dive into FHIR and its interoperability capabilities and take a peek at a few challenges it poses.
FHIR has been able to solve both rigid custom HL7 V2 integration and non-practical cum hard-to-do HL7 V3 integrations. While many of the different EHR vendors are encouraging integration through their own web service APIs, the quality of those APIs varies from EMR vendor to vendor – some are RESTful, some use SOAP, but these still use custom implementation. Since every EHR vendor is trying to create an eco-system of compatible products that can overcome the interoperability problem– implementing FHIR based APIs will allow them to develop compatible APIs which can be used for the seamless exchange of data.
Interoperability Paradigms
FHIR supports 4 interoperability paradigms – REST, Documents, Messages, and Services. FHIR implementation entails one or all of the above paradigms according to the design and requirement of the workflow involved. FHIR leverages the same data models and profiles (everywhere regardless of interoperability approach) REST, Documents, Messages, and Services. These are lessons learned from HL7 version 3, where different models are being used depending on the integration approach, leading to additional implementation challenges.
Extensibility to New Platforms
There is no specification in FHIR that a system should only support one paradigm. Both providers and payers can utilize FHIR for a vast range of solutions across their operations. A complex implementation will involve using multiple paradigms smartly. For e.g. A hospital may primarily be using messaging paradigm for meeting request/response workflow for exchanging information, but it must use the documents paradigm for supporting the exchange/storage of discharge summaries, progress notes, clinical summaries, etc.
It may also need to expose registries, appointments, patient portal, and referral information via REST & a few custom services for decision support. Various platforms like the PMS, EHR, Patient portal, Labs, CDC’s can be integrated using FHIR. Once the APIs are exposed, any other system can communicate using FHIR once the authentication is granted.
FHIR Highlights
Member Experience
One of the main goals of FHIR is to ensure member-centricity, by equipping members with easy and quick access to their healthcare records. FHIR utilizes technologies that mobile devices readily and easily support such as HTTP REST and JSON. With FHIR-enabled Patient Access API in the picture, it helps payers and providers come up with a wide range of mobile applications and devices to support their members and patients.
Developers must look into developing these applications and devices, payers with FHIR APIs from the start itself. This way, providers can urge members to be proactive in their lifestyles to ensure that the propensity of falling ill decreases – through notifications, reminders, program updates, and what-not.
Improved Provider-Payer Collaboration
Prior authorization is dreaded by both providers and payers. It typically involves a labyrinth of phone calls faxes, emails, and web portals. The complex nature of this process hampers the collaboration and communication between payers and providers. The current prior authorization process could potentially harm patients as their access to diagnosis/prescription gets delayed. This leads to members receiving suboptimal care or abandoning treatment plans altogether.
With FHIR in the picture, payers can now create a single source of truth to avoid costly point solutions, improve their NPS scores, and armor themselves with Provider Access API and Provider Directory API to improve payer-provider collaboration.
Improved Data Management
The healthcare ecosystem runs on data, from various sources such as – claims data, prescriptions, historical health records, data from wearables, and so on. To deliver holistic care that has positive care outcomes, it is necessary that both providers and payers have easy access to all data of a member.
FHIR aims to do just that. The implementation of FHIR pushes payers and providers to transform all available information at hand to a standard common target data format. This promises data integrity, consistency, minimization of redundant data, and above all achieve interoperability. Data standardization makes it easier to track and manage patient data.
In spite of these benefits and more, FHIR is not all sunshine and rainbows. Payers and providers still need to invest resources and time into figuring out data ingestion, data transformation, governance, and addressing data privacy concerns.
FHIR Up Before It’s Too Late
Currently, FHIR seems to be the answer to all the problems. However, it comes with its own set of implementation complications of having to collect, ingest, transform data to be exchanged through these APIs.
Our healthcare IT experts have been working on payer systems for a good while and have their ears to the ground when it comes to updates on proposals or rules. Get in touch with our experienced healthcare IT team at Nalashaa by dropping an e-mail at info@nalashaa.com.
Shireen Noushad