Stream: implementers
Topic: R4B technical corrections
Lee Surprenant (Jan 12 2022 at 01:51):
R4B is going out the door with a number of technical corrections to the published R4 (4.0.1) version of the specification, but its bumping the version number to 4.3.0.
When we went 4.0.0 to 4.0.1 it was clear to me that all servers are expected to go to 4.0.1 and the transition was mostly invisible to clients because the fhirVersion for both releases was "4.0" (the advantage of omitting that last release digit at https://hl7.org/fhir/R4/versioning.html#mt-version).
Now that we have the technical corrections going out in a "minor" release (or whatever hl7 calls that second number), the expectations are less clear to me.
For example, for some of the fhirpath constraint updates, would a server that enforces the (technically incorrect) 4.0.1 version of those constraints continue to be deemed conformant after 4.3.0 is published?
Would a 4.0.1 implementation that uses the fixed/corrected 4.3.0 version of those constraints (while claiming it support version 4.0.1) be conformant?
Is one more "right" than the other?
Lloyd McKenzie (Jan 12 2022 at 03:56):
Because there are some 'breaking' changes to certain resources and some internal architecture changes that impact servers, it's a more significant resources than just a 4.0.2. We'd like everyone just just move to it like they did to 4.0.1, but no guarantees that will actually happen.
Lee Surprenant (Jan 12 2022 at 12:33):
Yeah, I was surprised by the limited number of systems (and test tools) at connectathon for R4B given that its so close to publication.
We have a project where the new medication stuff is needed. Our current thinking is to update whole-sale (moving all 4.0.1 users to 4.3.0) and serving it from the same endpoints we had the 4.0.1 impl on (minus the resource types that got removed).
However, since so many clients are using 4.0.1, I want to continue supporting requests that use a fhirVersion mime type attribute of 4.0 ...but still validate those against 4.3.0 instead of 4.0.1 so that we have consistency in the data.
Lee Surprenant (Jan 12 2022 at 12:33):
Its mostly backwards compatible, so this seems reasonable to me. The only resource type where I think it could pose a major issue is Substance. That was maturity level 2 in 4.0.1 but got reworked for 4.3.0.
Lee Surprenant (Jan 12 2022 at 12:36):
I found it interesting that Grahame took a different approach on his server and gave r4b its own separate endpoint.
Lee Surprenant (Jan 12 2022 at 12:39):
personally, I feel like we should maybe do more to encourage servers to at least backport the technical corrections to their R4 impls if they aren't planning to upgrade to R4B... although I think it would be easier if folks just moved to 4.3.0
Grahame Grieve (Jan 12 2022 at 17:51):
I have no choice but to put it on a separate end-point since some resources have changed. but it's useful for me to do so, since people can take an R4 client and point it at R4B and see that it works
Josh Mandel (Jan 12 2022 at 20:14):
Back-porting R4B technical corrections to R4 is likely to cause a lot of pain though! This is where the "promise" of R4B is turning out not to quite fit reality; for most developers they'll need to treat it like a major release, in practice.
Josh Mandel (Jan 12 2022 at 20:14):
(I wonder if we shouldn't just call it R5 given what we know today ;-))
Peter Jordan (Jan 12 2022 at 20:31):
Josh Mandel said:
(I wonder if we shouldn't just call it R5 given what we know today ;-))
I'm intrigued by that comment - any further details?
Josh Mandel (Jan 12 2022 at 21:12):
Just from the perspective of deployed server and client infrastructure, library availability, etc. We're talking about changes that may not be formally "breaking" from an HL7 perspective but that will nevertheless cause developers to have to rewrite code.
Peter Jordan (Jan 12 2022 at 21:16):
Thanks. It will be interesting to see how many errors my IDE reports when I switch to the R4B version of the C# reference library!
Lee Surprenant (Jan 12 2022 at 21:16):
it might be one of those things that seems worse in principal than in reality. the reason i want to support R4B in-place is to avoid all the pains of a major update (e.g. data migration and the like). its so close to backwards compatible, that I'm hoping none of our existing users would even notice.
Lee Surprenant (Jan 12 2022 at 21:16):
the big question for me is "is anyone using Substance" :-)
Lee Surprenant (Jan 12 2022 at 21:18):
right now, one of the biggest issues to this "in practice" (at least in my mind) is that our CapabilityStatement won't even be parsable to R4 clients if we say we're supporting 4.3.0
Lee Surprenant (Jan 12 2022 at 21:18):
so i'm worried they won't even try (even though it would work if they did)
Lee Surprenant (Jan 12 2022 at 21:18):
this is what i hit with the touchstone tool for example
Lee Surprenant (Jan 12 2022 at 21:20):
so what I'm playing with now is returning an R4 flavor of the CapabilityStatement that we can return for clients that pass a hint that they're using R4 (e.g. by passing the mime type parametert fhirVersion=4.0.1). in this flavor, i omit any of the new resource types (and Substance) and we just advertise the capability that we have that is almost exactly equal to R4 behavior (aside from technical corrections)
Lee Surprenant (Jan 12 2022 at 21:20):
or, if we find this issue prevents R4 clients from working with us, maybe we'll serve that one UNLESS they indicate fhirVersion=4.3.0
Lloyd McKenzie (Jan 12 2022 at 21:26):
It really depends on what the system does. If it's "generic", there's enough changes under the covers, it matters. If you're an EHR, then it probably doesn't matter at all.
Rik Smithies (Jan 12 2022 at 21:28):
Substance was changed based on a misunderstanding, and has been reverted in the build version on R4B.
Lee Surprenant (Jan 12 2022 at 21:32):
Substance was changed based on a misunderstanding, and has been reverted in the build version on R4B.
oh, thats very interesting...i definitely didn't know that. is that recent?
Rik Smithies (Jan 12 2022 at 21:33):
Not really no. Shortly after the ballot ended I think
Lee Surprenant (Jan 12 2022 at 21:34):
ok, great. i thought i was basing that analysis off our model diff, but i guess that incorrect mental model i had was actually from the ballot overview then. great.
Rik Smithies (Jan 12 2022 at 21:40):
Other than that and the Medication Definition stuff that all got renamed I wonder what breaking changes there are at a "it won't accept my resource" level. I've seen some internal changes to base types and so on that would cause libraries to change.
Lee Surprenant (Jan 12 2022 at 21:41):
see my CapabilityStatement one above for my connectathon takeaway
Lee Surprenant (Jan 12 2022 at 21:43):
I'm not sure how big the issue will be in practice (so far i only tested with touchstone), but my theory is that the required bindings for CapabilityStatement.fhirVersion and CapabilityStatement.rest.resource.type will result in other clients with similar issues
Lee Surprenant (Jan 12 2022 at 21:43):
does anyone know if we ever considered reducing those to Extensible?
Lee Surprenant (Jan 12 2022 at 21:52):
I wonder what breaking changes there are at a "it won't accept my resource" level
Also, if interested, my notes from my first pass of looking for "subtly breaking changes" is at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/R4B.20questions.20.2F.20issues
For example, I called out the changes to these two valuesets there but hadn't yet pieced together this it might prevent R4 clients from parsing our CapabilityStatement.
I also referenced the two constraint updates that caused breakage in our system tests (but not sure the chances of breakage for "real" resources).
René Spronk (Jan 13 2022 at 07:30):
Outsider tongue in cheek comment: given that the US requires R4, I expect us to go from R4B all the way up to R4Z before we call something R5. But it's effectively still a major release for most implementers.
Josh Mandel (Jan 13 2022 at 19:27):
I recognize that your comment was tongue in cheek, but to be clear, the US certification program is pegged to FHIR 4.0.1 and updates need to go through the standards version advancement process, as far as I understand. There is no particular reason that changing a minor versus a major number would impact that process (again as far as I understand)
https://www.law.cornell.edu/cfr/text/45/170.215
Last updated: Apr 12 2022 at 19:14 UTC
