FHIR R5 is finally ‘on the shelves’. But should you implement it?

Ward Weistra

May 26, 2023

Subscribe to our newsletter

FHIR versioning has been a hot topic in the community for some years now. The official release of FHIR R5 takes the standard a step closer to the next big normative release – R6 – with a range of improvements and more than fifty new resources.

But not all of those resources are relevant for everyone – and FHIR infrastructure has been largely settled since R4 launched back in 2019. While some users have been eagerly awaiting specific changes in R5, others are fully committed to implementing R4, see no direct benefit from swapping, and will be sitting out R5 and waiting for R6 to arrive in due course.

As I’ll explain in this article, implementing R5 right now isn’t – or shouldn’t be – an automatic choice, especially for first-time purchasers. On top of cost considerations, there are practical and technical arguments that go right to the heart of healthcare interoperability.

Stick to R4 or change to R5?

The most important consideration after resource content is what your stakeholders are using, and who you need to exchange data with. R4 can be seen as the default option because it’s more widely implemented and supported; and if your organization already uses FHIR you may be tempted to stick with it until further notice. The answer may be different for HealthTech companies, care providers, payers – and countries – that are dipping their toes in the FHIR ocean for the first time.

You probably have a good idea which FHIR version – if any – is already widely implemented in your region: the US, UK, and Germany in particular seem settled on R4 for the foreseeable. And even if you’re working in a country or region where FHIR isn’t yet widely used – potentially becoming the pioneer that sets the agenda – you may still need to consider cross-border exchange, including European legislation.

Sticking to the rules

Implementing an ‘older’ version goes against the grain for many users and developers. We’ve grown up in the belief that new equals best, and we certainly don’t want to start a new project with reduced functionality or have to upgrade sooner than we’d like to.

But large HealthTech players, like big cloud providers and global EHRs, tend to be driven by the demands of the US rather than what’s happening in smaller nations: and the US is likely to use R4 for some time to come. ONC rules have largely been built around FHIR version 4 in recent years, which makes general adoption of R5 far from inevitable.

FHIR infrastructure, such as StructureDefinitions, has been normative since R4, smoothing the transition between FHIR versions. FHIR resources are largely independent of FHIR versions, and many apps written for R4 will still work with R5, and vice versa. So at the end of the day, compatibility is likely to focus on the specific FHIR resources you need to work with.

R5 and resource maturity

R5 is both a major release and an iterative improvement. It brings together the changes first seen in R4B, upgrades the maturity of many resources (based on real-world experience), and introduces some low-maturity resources that explore new areas but are probably too fresh to use in production. It includes a rewritten subscription framework (which will be backported to R4 and R4B) and splits out extensions from the core specification, for faster iteration.

If you’re just starting out with FHIR, R4 may win out by virtue of being the most widely-adopted version of FHIR. But if you’re supporting a specific use case or workflow, you may need to consider R5, or perhaps R4B, if you’re looking for medication definitions and evidence-based medicine resources.

The new resources and capabilities in R5 mainly relate to patient engagement and care coordination. Like R4B before it, it is technically a STU-only release, but as the graphic shows, overall resource maturity levels have increased from R4 to R4B, and from R4B to R5. What’s normative in R4 remains normative in R5: most other resources have gained in maturity, and many are heading towards normative status. By labeling R5 as ‘trial-use’, HL7 can test out these changes in the field before formally declaring them normative in R6.

What about tool support?

Customers have been asking about our plans to evolve the FHIR versions supported in Forge and Simplifier, and how long they should stick with R4 to model resources. From the data modeling perspective life is simple: Forge and Simplifier now support all FHIR versions from DSTU2 all the way up to R5. Firely Server does much the same, but R4B has been left to one side until we know more about take-up.

What’s the timeline for R5 and beyond?

New versions of FHIR have historically been published on an 18–24-month cycle. But the pace has been slowing down: R5 took longer to complete than expected and we can’t be sure how quickly it will be implemented across the healthcare ecosystem. We can be sure that HL7 will be watching the market closely before deciding whether the next step will be a restricted development like R4B, or the caravan will move straight on to R6.

R5 – direct route or detour?

The FHIR version you pick will ultimately depend on your specific requirements. To make an educated decision that works for your organization you must weigh up the pros and cons and consider the FHIR ecosystem you work in, industry support, required resources, and project timeline.

If you have a tight deadline, R4 has the widest commercial and geographical reach and comes with the guarantee of comprehensive tools support. If you have more lead time and specific use cases to consider, you may be drawn to the shiny new resources in R5.

It seems obvious to start with the latest version, rather than risk having to migrate mid-project: but if enough users hold off until R6, R5 may not reach widespread adoption.

Still undecided? Download our detailed resource maturity chart, or feel free to get in touch with our experts