FHIR versioning: the latest news from the Working Group Meeting

Welcome back to Baltimore!

There’s no doubt that interoperability flourishes best when we meet in person and build trust and relationships. It was amazing to be together again last month for the FHIR Annual Plenary and Working Group in Baltimore: more than 600 people showed up for the main Working Group Meeting and the Connectathon had about 200 participants.

As co-creators of the FHIR standard, and a committed contributor to its core values and ongoing development, we’re keen to attend these gatherings and perhaps provide some ‘thought leadership’ and technical input. Team Firely on this occasion comprised Ward Weistra, Alexander Zautke, and me. Rob Mulders and Rene Spronk represented HL7 Netherlands.

Maybe it was the feeling of relief at returning after COVID, but the Baltimore harbour area looked better than ever, and gave us an inspiring background for our morning run. Over at the Connectathon the number of new faces proved that our community hasn’t been slowed down by the social distance of the online editions. There were so many tracks to discover that a map was provided, and there were plenty of takers for our ever-popular cheat sheets. 

The hot topic: how to deal with versions

Many of our most inspiring conversations at DevDays this summer were around versioning, and Baltimore turned out to be the same. There was intense interest in forward and backward compatibility. How many versions will there be and how do we deal with releases? Are they compatible and should you migrate? How easy is it to work with someone using a different version? 

It’s a big subject and an aspect of FHIR that always gets us thinking. Does my app work with tools that were developed ten years ago? Will it still work with tools that are developed and launched in ten years’ time? For a long time, developers like me thought we could answer ‘yes’ to both questions, if only we tried hard enough to find a smart set of rules to stick to. That might still be true in theory, but I’m now convinced the solution would be too complex for practical purposes. 

Theoretically, we could try to achieve forward and backward compatibility. But in reality, that solution would be far too complex to work with.

For me, the main insight from two evenings of discussions in Baltimore is that we can’t ‘have our cake and eat it’. We need to move on from looking at the problem of compatibility from a purely theoretical perspective. Once we accept this shift in mindset we can focus our energy on real-life issues and stop trying to solve the unsolvable.

Bridging the gap

FHIR has many stakeholders, and it’s fair to say that versioning has got us where we are today. But things can get challenging when the target group that benefits from a change doesn’t have to bear the costs associated with implementing it. This is extra difficult when data modellers and software developers don’t agree on what counts as a breaking change – which was clearly the situation during the lead up to the publication of R4B.

R4B was intended as an in-between version to deal with a high volume of recent changes to specialized medication-related portions of the specification, and to bridge the gap before the expected release of HL7 FHIR R5 in May 2023. According to HL7’s modelling standards, it’s no more than an “in-place” upgrade to R4, but for software developers the changes ran deep enough for them to consider it a new, incompatible release that was effectively R5. The target audience for R4B is small, but for vendors it’s yet another version of FHIR to maintain, ship and support for years to come. 

Looking forward to HL7 FHIR R5 – and beyond

With FHIR R5 now on the horizon, how many “breaking” versions of the standard should we expect in the future? 

Grahame Grieve, the well-respected FHIR Product Director, is an advocate for converging to a mostly normative release in R6, and believes that R5 will be the last true ‘standard for trial use’ (STU). After this, we’re still likely to see incremental updates several times a year, and we spent some time in the working group discussing the versioning rules those updates will require. Should an older client always be able to communicate with a newer server and vice versa? What kind of flexibility would that older client need – such as accepting new values or elements – and can SDKs like ours provide enough flexibility without getting over-complicated? 

R5 will be the last true STU. There’s strong consensus that R6 should be mostly normative.

A practical approach might be to contain the consequences of breaking changes by agreeing that older software versions won’t need to work with newer versions of a FHIR server, and at the same time assuming that most organizations deploying FHIR servers will run new and older versions alongside each other.

It’s all about the community

As a co-creator of FHIR, Firely actively contributes to the development of the standard. We make a point of being prepared for new versions and keeping our tools and products up to date with the latest releases.

As always, the FHIR community has a key role to play in discussing and resolving issues around versioning. We’re active participants, but we certainly don’t have the last word, and we didn’t come away from Baltimore with neat solutions. But there are practical fixes, operational solutions, and work-arounds that can be used to keep everything running smoothly. 

As implementers we can help keep things flexible by ensuring we always support an older version of FHIR. The compromise for HL7 could be to accept that the “end result” for FHIR is not achieving a spotless R6 version, but accepting that once in use it will start to acquire blemishes even in non-normative parts.  

A neat example is renaming elements in resources that are not yet normative but already in heavy use. Take Encounter’s “hospitalization” for example. Is “admission” a better name? Maybe. Can we do it, since Encounter is not yet normative? Yes. Should we do it, at the cost of changes to existing code? Probably not.  

Here, community discussions between those responsible for delivering the best and cleanest “normative” R6 version possible, and those who need to implement its changes, should carry more weight than finding a set of compatibility rules that would not  deliver significant cost savings.

Getting stuff done

HL7 and the health IT industry have always engaged in productive dialogue. Our Baltimore discussions highlighted the difference in focus between a healthcare IT industry that wants to ‘get stuff done’ with FHIR for everyday use cases, and a development organization that wants to create and maintain a perfect standard. 

We now need to strike a balance between what really does need to change in the standard – which the industry will need to accept – and what’s not perfect but works well for implementers. Rather than a technical debate about what’s possible, this is a pragmatic discussion about real-life use cases.

We need to strike a balance between a perfect standard and a pragmatic solution from an implementer’s perspective.

It’s exciting to see that FHIR is moving into this new mature phase, and I’m looking forward to further community insights and discussions on the topic at DevDays 2023.

---

If you’d like to discuss how our software, training, and services can help your FHIR implementation, feel free to get in touch.