Stream: implementers
Topic: FHIR definitions of backward/forward compatibility wrong?
Marc de Graauw (Feb 21 2022 at 09:33):
FHIR says: "Forward compatibility means that content that is conformant in an old release will remain conformant with future versions." and "Backward compatibility means that instances created against future versions of the specification will interoperate with older versions of the specification." This has always seemed the opposite of what is meant by BC/FC elsewhere, see Wikipedia: "Compiler backward compatibility may refer to the ability of a compiler of a newer version of the language to accept programs or data that worked under the previous version." or and older W3C Note: "Backwards compatible evolution of a language means that consumers of texts in a language should be able to consume texts that producers that are based on an older version of the language will produce." And plenty of other sources. Why is this so? Has FHIR got it wrong? Or is some very deep meaning hidden in the FHIR definitions which I don't yet grasp?
Marc de Graauw (Feb 21 2022 at 09:35):
Side note: I found that I gave a similar comment in 2007 to @René Spronk re HL7v3, and apparently (I don't really recall the discussions) HL7 "were aware of the problem" then
René Spronk (Feb 21 2022 at 16:33):
Wikipedia: "Compiler backward compatibility may refer to the ability of a compiler of a newer version of the language to accept programs or data that worked under the previous version." - it's all about perspective: in the above definition a compiler plays the key role, "given a new compiler, it should be able to process the latest as well as old versions of a language". Twist that inside out (as HL7 does) and it would read "a computing language should only be changed in such a way that an existing compiler will be able to deal with it" (which puts the focus on the language, not on the compiler).
FHIR says: "Backward compatibility means that instances created against future versions of the specification will interoperate with older versions of the specification.", or, reworded, "FHIR processing software backward compatibility may refer to the ability of FHIR processing software of a newer release of FHIR to accept FHIR resources defined in a previous FHIR release". - which is the wikipedia definition.
Marc de Graauw (Feb 21 2022 at 17:30):
It still does not make sense to me. After your quote, the FHIR spec says: "Backward compatibility ... is not guaranteed by FHIR" That's like Xbox or Playstation saying you cannot play your old games on a new console. What is defined next (ignore unknowns etc.) is what is usually meant by forward compatibility, like an old HTML browser which ignore unknown markup and still displays the text, thus giving some degree of forward compatibility (displaying 'newer' HTML in an older browser). See https://en.wikipedia.org/wiki/Forward_compatibility. I simply don't see how the rephrasing you do would end up with Wikipedia's (or any other, WP is not authorative here) definition
René Spronk (Feb 21 2022 at 17:40):
We'll only create new games that can also be played on your old console (but they might have additional features if played on a new console). It's not about the Xbox/Playstation being backward compatible , it's about the games being forward compatible. It's not about the Compiler being backward compatible, it's about the language being forward compatible.
The point being (in the full realization I've probably muddled the analogy here and there): it's all about the viewpoint, "am I speaking to you", or "are you listening to me", are these not the same thing that is just phrased differently because they are based on different points of view ?
Peter Jordan (Feb 21 2022 at 21:07):
Interesting discussion. My practical understanding of backwards compatibility is based on the MS .NET Framework ('classic' versions) where software built using one version is guaranteed to work with future releases, i.e. the 'compiler' compatibility referenced by @René Spronk. However, this is implemented at a framework versioning level - something that, for various reasons, FHIR cannot achieve. The best guarantee that FHIR makes is a constrained guarantee that no 'breaking changes' will be made to 'normative' artefacts. Certainly, FHIR doesn't offer 'forwards compatibility' as (certainly using the reference libraries) there is no mechanism for older versions to handle (or ignore) newer schema/types, etc.
Marc de Graauw (Feb 22 2022 at 08:32):
Saying that a newer console is backwards compatible (able to play an older game) is equivalent to stating that the older game is forward compatible with newer consoles is consistent (if unusual, compatibility statements are usually from the processor, not the artefact, viewpoint). But OK, I can follow that. The analogy then is: a FHIR server/client is like a console, a FHIR resource is like a game. Then you state: "We'll only create new games that can also be played on your old console". So, (normative) FHIR R7 resources can be consumed by R6 servers/clients. But the FHIR spec says the opposite: "BC means that ... instances created against future versions of the specification will interoperate with older versions of the specification. This is not guaranteed by FHIR" - this states that R7 resources will not (guaranteedly) interoperate with R6.
What I'd hope and expect would be (for normative resources):
- a R7 client will have no problem handling resources it GETs from a R6 server, and handle them as the R6 spec specifies
- a R6 client can PUT/POST resources to a R7 server, which will handle them as the R6 spec specifies
Seems to me that the rules for compatibility in FHIR facilitate this.
What would be nice is:
- a R6 client would not break on a GETting resources from a R7 server, and could handle all content specified in R6
Looks like the "ignore" rules below the FHIR definition of BC could facilitate this.
I'd be hesitant about:
- a R7 client PUT/POSTing to my R6 server
which seems to be captured by the remark "many implementers are unwilling to consider some of these steps because of concerns about clinical risk".
Is this picture right? If so, I'll submit a ticket asking for some elaboration in the spec on this point, since it is sparse on the FC/BC meaning
Alexander Henket (Feb 22 2022 at 08:41):
Note that all this not only should apply to versions of FHIR but also to versions of profiles. Is opening up a 0..0 element to 0..1 in the next version of the profile a backward or a forward compatibility issue? I can 'play' the old resource in my new server. I cannot 'play' all new resources in my old server.
René Spronk (Feb 22 2022 at 08:51):
a R7 client PUT/POSTing to my R6 server - of resources normative in R6, that'd work. Of resources that have gone normative going from R6 to R7, no.
I do hope your change request will include the full suggested wording, a simple request to elaborate may be put on the bottom of the to do list.. the last time you raised this was in 2007, so you may have to put it into your agenda again for 2037. :-( :-)
Cooper Thompson (Feb 22 2022 at 16:23):
I'll point that most of this discussion is probably pretty hypothetical, and assumes a lot about the implementation details of a specific FHIR server.
Last updated: Apr 12 2022 at 19:14 UTC
