FHIR® R5 has been officially released at hl7.org/fhir. This is the fifth major version of FHIR, and the culmination of years of work by talented HL7 volunteers. As a very programmable specification, FHIR can generate a list of all the differences from R4. The previous major version release (R4) was in 2019, with a “minor version” type release called R4B being released in 2022. 

What is in R5?

• 55 new resources – covering a ton of new areas. Not all of these are immediately relevant to most use cases. 

• A number of resources promoted to maturity level 5 – essentially the highest before being locked down for backwards compatibility. This is exciting as it means FHIR is closer to becoming very stable. 

• Loads of property changes and new data types, making things more streamlined, expressive and/or efficient. These types of changes help builders solve problems, and are always welcome, even if they mean backwards compatibility changes. 

What is backwards compatibility?

Backwards compatibility is a software term that refers to whether or not two components can interoperate across versions. For example, Windows applications from the 90’s still run, but it does take a fair amount of thought and effort from Microsoft. FHIR is more less the “operating system” for healthcare interoperability, so compatibility guarantees are critical. In FHIR terms, backward compatibility means that apps written against R4 still work with R5, and that an R5 app can work with an R4 server. Because resources change independently in FHIR, compatibility is a hard problem to pin down. Some apps may be compatible with versions going back as far as DSTU2 (circa 2014), whereas others apps will break across R4/R5, all depending on which underlying FHIR resources they need. 

What does the future of FHIR versioning look like? 

Versioning in FHIR has been a topic of discussion for the last year or so. FHIR’s Product Director Grahame Grieve outlined in a post last year some of the options for how FHIR should approach R5. In short, FHIR R5 positions the FHIR standard on a path to being mostly normative in R6 – in a solid place where we can start to have conversations about what kind of breaking changes are allowed. This will likely mean a new paradigm will follow R6. 

Will we see R5 in the wild anytime soon?

Probably not. You may or not have read about a substantial amount of federal rulemaking around FHIR in the past few years. All of those rules are pegged to FHIR version R4. However, along with that rulemaking ONC released a new process called the Standards Version Advancement Process (SVAP). SVAP gives ONC the ability to say “it’s ok to use R5” and have adoption be voluntary. To actually force an upgrade would still require rulemaking. 

Does Redox support R5?

Redox’s FHIR support is deliberately de-coupled from FHIR versions, outside of a version that goes into the URL. We realized early on that the future of FHIR would be the post-R6 world, and in general we don’t hard-code any assumptions about the existence of resources or properties into our tools. We are enthusiastic to hear any use cases that can only be achieved with R5, as well as automating converting older versions of FHIR to R5.

Check out our developer docs to learn more about Redox FHIR API.