FHIR TL;DW
4 Min Read

FHIR TL;DW: Deploying FHIR at Scale

Subscribe to our newsletter

Subscribe

In our FHIR TL;DW (Too Long; Didn’t Watch) series, we share bite-sized summaries and insights from key HL7 FHIR DevDays presentations.

With 10,000 FHIR interfaces and 74 billion API calls last year, Epic operates at a significant scale. What are the main stumbling blocks when interfacing with that many client applications? 

In his talk “Building, Deploying, and Maintaining FHIR Implementations at Scale,” Epic’s Cooper Thompson shared lessons learned from deploying and supporting FHIR in high volume production environments worldwide and the key factors to consider when scaling FHIR. 

I’ve outlined key insights from the talk below.  

When managing FHIR interfaces at scale, the scope of responses to client queries and the diversity of FHIR specifications across implementations can create unexpected stumbling blocks. Epic’s experience highlights two major areas of complexity:

1. The EHR deployment model 

Many assume the EHR includes all workflows and data, but this isn’t always the case. For example, laboratory systems, billing applications, or scheduling tools may exist alongside the EHR. This means the EHR’s responses to FHIR queries are highly dependent on its deployment model. 

For example, a query for USCDI data may return incomplete results if certain data, such as coverage or billing, isn’t part of the EHR’s scope. This mismatch can lead to unexpected issues on the client side, particularly if they expect comprehensive data.

2. Diversity in FHIR specifications 

Even when organizations have the same FHIR use case, there may be big differences in how organizations choose to implement them. 

Organizations are using slightly different profiles or exchange methods, such as operations, REST push, subscriptions, search and update, and messaging, often in unique combinations. Authentication flows can also vary significantly, creating an additional layer of inconsistency. 

In the past we heard a lot about apps struggling with server-side variance, however servers are now also starting to face challenges with variants across FHIR implementation guides. 

To address these challenges, Cooper Thompson emphasized the importance of standardized patterns and leveraging international FHIR implementation guides (IGs). The International Patient Summary (IPS) and International Patient Access (IPA) serve as strong examples of global patterns. 

While countries may have slight variations, adhering to a single pattern simplifies scaling across jurisdictions. Finding other areas where a single pattern can be established, even with profile variations, will be key to mitigating complexity and improving interoperability. 

Epic’s experience highlights that alignment on patterns, rather than expecting perfect uniformity, is the most pragmatic way forward for scaling FHIR implementations.

At Firely, we’re committed to sharing best practices and insights for everything FHIR. Explore our FHIR TL;DW YouTube playlist and FHIR training courses for more in-depth discussions on navigating FHIR challenges. 

For the full length video of Cooper Thompson’s talk, you can find that here. For all videos from FHIR DevDays 2024, head over to the Devdays 2024 playlist on Youtube

By René Spronk

René Spronk is a trainer and educator specializing in healthcare interoperability standards. He focuses on FHIR, as well as related standards such as HL7 v2 and IHE, helping organizations understand how health information can be shared effectively across systems. At Firely René works with healthcare providers, vendors, and other stakeholders, delivering training and guidance that makes complex interoperability topics accessible and practical. His work primarily focuses on Europe, where he supports organizations in understanding the European interoperability landscape and EU legislation, including the European Health Data Space (EHDS).

Recommendations for you

Explore more topics

Post a comment

Your email address will not be published. Required fields are marked *