Three FHIR myths that hold back digital health enterprises
Nov 2, 2023
Healthcare software vendors prioritize projects that use HL7® Fast Healthcare Interoperability Resources (FHIR®) over those built on other standards for many reasons. Because FHIR resources have a defined structure, they can be accessed, manipulated, and exchanged in ways that other standards aren’t today.
In addition to the benefits of FHIR, interoperability mandates are moving the market incrementally, but towards FHIR domination. There is a delicate balance that organizations must strike between using FHIR APIs where possible, while having to maintain expertise and knowledge for how to exchange data with organizations using alternative standards. This balance is particularly hard to calculate when stubborn myths about the realities and capabilities of FHIR persist. A few of these myths are a result of the reputation that FHIR has taken on as the complete solution to the interoperability question.
Rather, FHIR APIs still greatly differ from organization to organization, required adoption is still years away, and alternative standards will continue to be used for the foreseeable future.
To overcome these persistent myths, it’s crucial that organizations understand what working with FHIR realistically looks like. The success of interoperability depends on getting this right. Let’s dive in.
The mirage of market size
Myth: Healthcare organizations relying on FHIR APIs represent an addressable market for digital health revenue
Reality: Few hospitals and health systems have the resources to commit to comprehensive FHIR adoption in the short term.
Regulations such as the 21st Century Cures Act stipulate that health IT must incorporate FHIR APIs for patient access to health data. To meet these regulatory requirements, many digital health enterprises have focused on implementing FHIR. As of 2022, more than two-thirds of U.S. hospitals reported using a FHIR API to enable some kind of patient access to data.
However, beneath this promising surface lurks a crucial caveat: inconsistent implementations of FHIR APIs used for common workflows across hospitals and health systems. Because FHIR adoption isn’t uniform across healthcare organizations, the addressable market for FHIR-only implementations is significantly smaller than many digital health enterprises think.
While nearly 70% of hospitals are taking steps to implement FHIR, only half of them have enabled the capability to read EHR data using FHIR APIs exclusively. In addition, only one-third of hospitals have enabled external applications to both write to the EHR and access non-EHR data using FHIR APIs.
The stark reality is that providers, saddled with resource constraints, are progressing more slowly towards comprehensive FHIR integration than previously expected.
Quite simply, providers lack the skilled IT personnel, time, and budget required to pursue it. For these reasons, smaller, independent hospitals that use non-market leading EHRs tend to lag behind their counterparts in FHIR API adoption. Without further immediate regulatory pressures, full FHIR adoption can expect to take many more years.
This delay has profound implications for digital health companies because it shrinks their addressable market significantly—therefore reducing their revenue potential, competitive clout, and innovation ability.
The illusion of uniformity
Myth: FHIR behaves identically across healthcare organizations using the same EHR
Reality: Each organization implements FHIR based on its own set of clinical workflows, practices, and business rules, which results in wide variations
FHIR's appeal lies in its inherent flexibility, as it is designed to foster interoperability while accommodating the idiosyncrasies of specific healthcare organizations. While FHIR establishes a standardized framework for structuring healthcare data, it does not impose rigid rules on how organizations should implement it. Instead, FHIR provides a foundation upon which organizations can build their own unique implementations.
In fact, several factors contribute to variations in FHIR implementation and behavior:
Different security and access control policies, authentication mechanisms, and authorization rules can lead to variances in how FHIR APIs handle user authentication and data access.
Custom data elements, profiles, and extensions, which are required to capture specific patient information and address local workflow and practice needs, lead to variations in the structure and content of FHIR resources.
EHR configurations differ between healthcare organizations based on their unique needs. This can affect how data is structured within FHIR resources and how FHIR APIs are exposed, making it a significant driver of API differences.
The reality is that no two healthcare organizations will have the same implementation of FHIR APIs to execute their workflows.
Consider what happens when an external application needs to send a document to an encounter in a patient’s chart. To create this new document, the external application would likely use the DocumentReference resource and a “create” interaction. But not all EHRs share the same formatting requirements for this standard reference. Cerner allows the attached document to be in many formats: pdf, plain text, rich text, html text, and more. On the other hand, Epic requires that the attached document is in plain text only.
Another example of variations within the DocumentReference resource are coded values that can be defined in several ways, such as standard LIONC or SNOMED terminology. EHRs can format their resources this way, or even allow providers’ IT teams to use values pulled from a locally maintained dictionary. This is not unique to the DocumentReference resource, and can be seen with nearly all FHIR resources. These variances mean that even two organizations using the same EHR will inevitably use and implement FHIR resources differently.
When two organizations want to exchange healthcare data but have different formats for these resource variables, it leads to data mismatches that require consolidation, normalization, and translations— even though they are both using FHIR APIs. FHIR does not behave uniformly across healthcare organizations and assuming so leads to a host of challenges including lengthy integration timelines, data mismatches, and poor data quality and consistency. Accordingly, each FHIR implementation will require configurations that are unique to that project.
The workflow wager
Myth: Because there are tons of FHIR resources, digital health enterprises don’t need to worry about being compatible with other standards
Reality: FHIR support within EHRs is often limited to a select set of integrated workflows
While many EHR systems have recognized the potential of FHIR for data exchange, provider adoption rates vary significantly. The majority have been slower to fully integrate it into their systems.
The covered scope of FHIR support within EHRs is smaller than it seems, especially when it comes to more complex workflows. While bi-directional data exchange and real time notifications are possible with FHIR, many EHR vendors have not built in these capabilities. For this reason, EHRs don’t consistently support providers’ more complex workflows, such as submitting new patient information, updating source records, or reconciling medication lists. As a result, data exchange with external systems requires using multiple protocols and technologies to complete any single workflow.
In many healthcare organizations, especially those with legacy systems, traditional interfaces like HL7 or CDA interfaces or custom APIs continue to play a pivotal role in bi-directional data exchange and real time notifications. In the absence of regulatory mandates, these interfaces are likely already deeply ingrained in provider workflows and unlikely to be replaced completely with FHIR APIs.
While multiple standards and technologies are necessary for powering complete workflows, they add complexity to the integration process.
Recommendations for digital health enterprises
As digital health enterprises work to create an integration strategy for FHIR-based exchange, they should consider the actual state of FHIR adoption in healthcare organizations. Ideally, their comprehensive integration strategy should:
Recognize and compensate for health systems without resources for immediate FHIR investments;
Account for the unique workflow and EHR configurations of each site; and
Support data exchange between multiple standards and technologies.
If one thing is constant in healthcare, it is the evolving standards and technologies used for data exchange. In light of this continual advancement, it’s important to design integration solutions that can adapt to these changes. Flexibility enables digital health enterprises of all sizes to pivot, align with new requirements, and ensure that their investments remain relevant in the long term.
Equally important is the scalability of such integration solutions. As data volumes increase and exchange needs expand, it will be critical for digital health enterprises to deploy integrations that can maintain uninterrupted data flow, quality, fidelity, and efficiency. This becomes more challenging when data flows across multiple systems that adhere to different data standards—a situation that requires data transformation and normalization. In addition, integration solutions must adhere to regulations, such as HIPAA, while also incorporating robust security measures to safeguard patient data during transit and storage.
Digital health enterprises with robust integration strategies are more likely to partner with experts in the integration space to execute their vision. They realize that strategic partnerships are not just about solving data exchange complexities; they are about empowering their innovators to direct their valuable time and resources to other critical efforts, secure in the knowledge that integration is in expert hands.
Want to learn more?
Get the information you need to implement FHIR successfully and avoid the risks of falling behind
