Taming the FHIR Frontier: Navigating a World of Variations

HL7’s Fast Healthcare Interoperability Resources (FHIR) standard was developed with the goal of simplifying healthcare data access from electronic health record systems for third-party applications. The paradox, however, is that despite this objective, FHIR itself isn’t a single standard, but a family of standards with multiple versions, variations, and implementations. This creates a complex landscape that requires a sophisticated approach to ensure true interoperability.

The Many Faces of FHIR

The variations in FHIR can be broken down into a few key areas:

• Different Versions: Just like any standard, FHIR evolves. We have to contend with different versions such as DSTU2, R3, and R4. Each version introduces new features, changes to existing resources, and sometimes breaks with previous versions.
• Implementation Differences: No two FHIR APIs are exactly alike. They vary in the resources that can be queried, in the query parameters supported, and in the elements included in the responses. A query that works perfectly on one server might not be supported on another.
• Implementation Guides (IGs): These are like blueprints for how to use FHIR for a specific purpose, such as a particular clinical workflow or region. IGs can introduce custom profiles, extensions, and constraints on the core FHIR specification. For example, the US Core Implementation Guide provides additional details on how FHIR can be used by healthcare providers to share patient data, such as using LOINC codes for labs and RxNorm codes for medications.
• “Off-Label” Uses: Sometimes, FHIR resources are used in ways they weren’t originally designed for. An example is using a set of Observation resources by some FHIR servers to exchange patient-reported outcomes data such as a PHQ-9, instead of a QuestionnaireResponse resource. Such an off-label use requires the third-party application to query for completely different resources.

Our Experience with FHIR’s Variations

We’ve been at the forefront of this challenge, building several applications that integrate with multiple FHIR implementations across different versions. We’ve successfully built solutions that handle DSTU2, R3, and R4 servers. Our first application, for postoperative opioid management, integrated with Cerner’s DSTU2 API, went live in February 2020. Since then, we have developed applications integrating with other EHRs and with various versions of FHIR for our clients and for our own Sapphire products.

This hands-on experience has given us a deep understanding of the complexities and nuances of navigating a diverse FHIR ecosystem.

Overcoming the Challenges

Dealing with these variations presents serious hurdles. The most significant challenge is optimizing performance. In our case, we develop SMART on FHIR apps we call Facets that integrate data in real-time from EHRs and our patient engagement apps. To provide a great user experience, we optimize the query to obtain exactly the data it needs — such as only the last 12 months of lab results.

The difficulty is that different EHR FHIR APIs support different query parameters. Writing a single efficient query that works across all EHRs is nearly impossible, and sending unsupported parameters can not only result in suboptimal performance, it may also return cryptic errors from the EHR.

Over the years, we’ve developed a multi-pronged approach to overcome these issues:

• Intelligent Query Library: We built an internal query library that intelligently generates the correct query parameters based on the specific FHIR server we’re interacting with. It understands the server’s capabilities and dynamically generates a query specific to that EHR.
• Internal Data Model: We’ve created an internal, unified data model that abstracts away version and implementation differences, giving applications a consistent structure to work with.
• Data Conversion and Normalization: We’ve developed robust data conversion processes to handle “off-label” uses, such as converting proprietary Observations into a normalized QuestionnaireResponse format (and adding LOINC codes).
• Local Data Caching: To boost performance and reduce reliance on external servers, we often store a local copy of the data. This allows us to perform complex queries and calculations locally, significantly improving user experience.
• Rigorous Testing: We have a comprehensive testing suite that validates our applications against a variety of real-world FHIR server implementations, ensuring our code is resilient to variations.

FHIR in Context

To be clear, FHIR is still a significant leap forward compared to the previous state of healthcare interoperability. Before FHIR, application developers often had to work with a patchwork of proprietary APIs: interfaces unique to each vendor, with different data formats, authentication methods, and query languages. This made it nearly impossible to build an application that could integrate with more than one system without a massive amount of custom, one-off development work.

FHIR, even with its variations, provides a single, foundational standard that we can build upon, offering a far more efficient and scalable solution than dealing with dozens of unique vendor-specific APIs.

The Road Ahead

The good news is that the FHIR ecosystem is maturing, and the amount of variation is actively decreasing. Since the release of FHIR R4, certain key resources and the core API have achieved “normative” status. This means they are stable and guaranteed not to change in a backward-incompatible way in future releases, providing a solid foundation for applications.

Furthermore, in the United States, the aforementioned US Core IG is driving even greater standardization. This guide builds on the R4 standard and defines a minimum set of constraints and resources that must be supported by all certified health IT systems. By requiring adherence to US Core, the U.S. government is ensuring that a common set of resources can be retrieved from any system, further reducing the variations we have to manage and paving the way for a more truly interoperable healthcare ecosystem. Because of the support for US Core IG in the EHRs our applications are integrated with, we recently turned off support for DSTU2 and STU3 in our applications.

By combining technical strategies with evolving standards, we’ve successfully built applications that seamlessly integrate across diverse healthcare systems — proving that with the right approach, it’s possible to achieve true interoperability, even in a world of variations. At least, for retrieving patient data from EHRs. Writing data to EHRs using FHIR will have to be the topic for a future blog post.