FHIR will be the foundation for achieving the Triple Aim of improving the patient experience, the health of populations, and the cost-efficacy of healthcare.
The Basics: What is FHIR?
FHIR (Fast Healthcare Interoperability Resources) is a standard for healthcare interoperability that acts as both the ‘pipes’ for sending data between systems, but also contains the instructions for what we can put into those pipes. A major part of the CURES Act, this standard for healthcare interoperability takes into account the existing use cases for interoperability, but also provides the structure for and flexibility within that structure for healthcare developers to take a huge leap forward.
FHIR stands to make it a lot easier for different systems to talk to each other. Right now, every time a software developer needs to create a new connection to an exchange or app, it’s extremely time-consuming because those connections use different standards or no standards at all.
The connection to each health information exchange is different and the connection from an EHR to an e-prescribing application usually has almost nothing to do with the connection you just built for the HIE. FHIR builds on the existing HL7 feeds used for these purposes by combining the ‘messages’ and the ‘delivery’ into a single modernized approach that can be used for a whole universe of use cases.
How is FHIR Different from Past Attempts at Healthcare Interoperability?
The previous gold standard for interoperability: ADT messages and C-CDA documents, were both complex to map to, generate, and parse. By creating a standard that’s based on a RESTFUL API that considers both content and use-case, FHIR should greatly reduce the burden on healthcare technology vendors.
Generating, sending, and receiving ADT and C-CDA messages meant procuring and building an expensive and resource-consuming technology stack. This created a large barrier to entry for small to midsize vendors, forcing them to choose between dedicating R&D to future use cases and certification or focusing on more acute customer needs.
Is a Fully Interconnected Healthcare System in Our Future?
FHIR should effectively resolve many of these types of difficult decisions. Amazon Web Services, Google Cloud Platform and Azure all have distinct and scalable FHIR as a service strategies for customers. Amazon Web Services’ strategy is based around their serverless compute Lambda product used in conjunction with an open source integration model. Google Cloud Platform and Azure have both productized their serverless FHIR implementations, giving companies an end-to-end solution to add FHIR endpoints to their applications. In addition to the large public cloud providers, there are also companies like Redox that offer interoperability as a service by using proprietary APIs.
FHIR was designed from the ground up to address a multitude of use cases such as care coordination, health information exchange, and payer exchange. In addition, ONC has invested in both laboratory testing with the INFERNO testing tool and mandated Real World Testing as part of the CURES Act. This should go great lengths in practice to making sure that two applications that meet the same specifications and standards can actually talk to each other to support evolving customer use cases using the same set of endpoints for every use case.
For a fully connected healthcare system to flourish, all of the actors in the healthcare community (patients, providers, and developers) will have to become more collaborative, guided by law and incentives. The benefit for developers to that collaboration is that there are so many untapped markets and areas for innovation in healthcare. Together, we can all work together to improve patient experience and the overall health of our communities — and do so more cost-effectively.
FHIR will hopefully be the foundation to create new relationships in the healthcare community that enable us to achieve the joint goals of IHI Triple Aim and a fully connected healthcare system in the not so distant future.