FHIR R5 ballot: What it means for your implementation
FHIR R5 is heading to ballot. Do you need to migrate now? Here's when a version shift makes sense — and when it doesn't.
By Sandra Ottens, Interoplab
FHIR R5 is heading to ballot. For many organizations, that immediately raises the question: do we need to migrate? The short answer: probably not immediately. The longer answer requires some context.
When should you migrate?
If your current STU3 implementation does what it’s supposed to do — deliver the right information in the right place for good care — why switch? Migration makes sense only if the new version solves something that’s actually a problem now, or if external pressure exists (regulation, cooperation partners, national programs).
Backward compatibility: blessing and curse
FHIR tries to maintain backward compatibility, but a new version always brings changes. Those changes reflect valuable feedback from practice. Normative resource definitions offer more protection in R5, but the jump from STU3 to R4 proved substantial for some implementations.
Multiple versions side by side
HL7 v2 shows that multiple versions can coexist just fine. In the Netherlands, versions 2.2, 2.4, and 2.5 all still work — depending on context. The critical point isn’t the version itself, but the agreements you make about which version you use and with whom.
The real risk
The challenge emerges only when two versions become mandatory simultaneously — when party A supports only R4 and party B only R5. That requires coordination at organizational and national level, not a technical solution per organization.
Recommendation
- Wait for clarity from Nictiz and VWS on the national roadmap
- Follow the R5 ballot, but don’t start implementing yet
- Make agreements with your cooperation partners about which version is leading
- Future standards like BgZ require joint decision-making — align with those conversations
Questions about FHIR versions and what they mean for your implementation? Get in touch →