Stream: implementers
Topic: FHIR Normative Breaking Changes
Cooper Thompson (Sep 07 2021 at 19:01):
I feel like there have been several Jira tickets for R5 that we've been rejecting because the relevant part of the spec is normative (Patient, Observation, Conformance). This seems like an approach that can't last. Not being able to improve (or fix) FHIR just because something is labeled as "normative" seems like a problem with the standards process. I believe HL7v2 had a process of adding new content, deprecating old, waiting a few versions then removing the old. Should we be designing such a process for FHIR?
Cooper Thompson (Sep 07 2021 at 19:03):
Or should we just start working on a new standard (WATER - Web APIs To Exchange Resources)
Lloyd McKenzie (Sep 07 2021 at 19:41):
We absolutely have the option of deprecating and introducing new data elements, codes, operations, etc. However, there's a cost to doing that - so the size of the benefit needs to be sufficient to justify that cost. Also, some types of changes where deprecating and adding a replacement aren't very viable. E.g. messing around with JSON syntax. In some cases, we could look at deprecating and replacing an entire resource or an entire mime type, but the amount of value from the change would have to be enormous to justify the expense for the whole community.
During the early STU phase, 'better' generally automatically wins. We ditch whatever exists and replace it, no questions asked.
Once we hit FMM 4 and 5, we do a temperature check with the community and generally only make breaking changes if the community is on board.
Once we hit normative, breaking changes need to be introduced over a set of multiple releases - and the community still needs to feel they're worth the cost.
In short, once you get to a certain level of adoption, 'slightly better' no longer becomes a sufficient reason for change. At some point, there may well be something that's sufficiently 'better' to justify a radical re-think of how FHIR does things - but that new thing is likely to need to be "significantly better than REST".
All that said, if you have proposals that are being shut down "because normative" in a way you feel is detrimental to the standard and the community, please come chat with the FHIR Management Group. Depending on the desired changes, there may be avenues that can be pursued within the standards process.
Gino Canessa (Sep 07 2021 at 19:53):
Is there some cumulative measure tracked? E.g., the benefit of a single breaking change may not be large, but a 'pass' of breaking changes in one version may be. (no idea if that's the case anywhere, just a historical perspective from something else)
Lloyd McKenzie (Sep 07 2021 at 20:17):
Not something we've really talked about. I suppose we could group certain changes in a "won't do it for now, but will re-visit 'if we're going to break it anyway...'". Those would be candidates to re-evaluate if there ever was an agreed change, and if we ever accumulated a large volume of them, we could poll the community as to whether a particular conglomeration of them would be worth the cost.
Last updated: Apr 12 2022 at 19:14 UTC
