Stream: fmg
Topic: For this week's call
Josh Mandel (Aug 26 2019 at 15:15):
Discuss organization for FHIR connectathon intro webinars (i.e., can we consolidate the basic intro stuff into a single call / video, so track-specific orientations can be more targeted)?
Lloyd McKenzie (Aug 28 2019 at 20:01):
Call on now
Lloyd McKenzie (Sep 04 2019 at 20:01):
Call on now
Josh Mandel (Jan 24 2022 at 20:48):
Lloyd McKenzie (Jan 25 2022 at 23:11):
DeviceDefinition productShelfLife changes in R4B because the ProductShelfLife datatype was changed by the med governance folks. I think we should look at splitting the datatype in R4B into ProductShelfLife (remains unchanged) and ProductShelfLife2 (has med governance changes). For discussion tomorrow.
Josh Mandel (Jan 25 2022 at 23:25):
Also from #implementers > R4B compatibilty I noted:
R4B has added new options to the choice type for ActivityDefinition.subject[x] (subjectCanonical is new). Is this a known/desired change within our versioning rules?
Josh Mandel (Jan 25 2022 at 23:26):
Also would like to discuss the broader point from that thread: do we think R4B is consistent with our current versioning rules, given what we expect to be included in the release? For the reasons I listed there, I think the answer is "no, R4B counts as a breaking change as currently defined."
Lloyd McKenzie (Jan 25 2022 at 23:47):
R4B is technically a breaking change. There's no question about that. However, most systems will be able to treat it as a technical correction - because they don't use the parts that are breaking. That has always been the objective.
Josh Mandel (Jan 26 2022 at 00:00):
If we agree it is a breaking change, why do we not apply our typical normatively documented versioning rules from http://hl7.org/fhir/versions.html so that everybody understands this? I don't see how this would make R4B less useful for implementers; to the contrary. Still: if we want to break our existing versioning rules, why don't we amend them?
Lloyd McKenzie (Jan 26 2022 at 00:11):
It's NOT a breaking change for the vast majority of the community and we want everyone who can to treat it as a technical correction. We carefully scoped the specification to ensure this could occur. I don't understand why we would suddenly decide to change a direction that was agreed on over 2 years ago when we're perhaps a month from publishing.
Josh Mandel (Jan 26 2022 at 00:17):
I don't understand why we would suddenly decide to change a direction
My position is that we might change now there's a clear picture of what's on the table, and it's clear how this contradicts our published process. Or maybe we just need to change our process.
(It has also taken us a lot longer to get to the point of this publication than we thought, and as a result we also have a much better sense of what is in scope for future versions. Just saying we have been surprised by the process as it has unfolded already, and we might change our minds because of this.)
Josh Mandel (Jan 26 2022 at 00:18):
It's NOT a breaking change for the vast majority of the community
(I'll stop repeating myself right after this, I promise -- just want to make sure this thread reflects our back-and-forth up to now, since it has been split across FHIR-I and Zulip.) Our current rules do not incorporate this kind of consideration into the definition of a breaking change.
Lloyd McKenzie (Jan 26 2022 at 04:02):
We're not changing our definition of breaking change. We're clear that there are pieces of what's happened in R4B that are absolutely breaking. However, they've been isolated in such a manner that for most implementers, there is no breaking change at all. And many of the intended implementers of the breaking pieces of R4B have not implemented R4 - and thus there's nothing to "break". The end result is a release that, for most implementers, should be no different than 4.0.1 was.
Lloyd McKenzie (Jan 26 2022 at 04:03):
And we really want the 4.0.1 implementers to transition to R4B because it makes a number of technical corrections that address issues that were broken in 4.0.1
Josh Mandel (Jan 26 2022 at 04:22):
Ok -- I think that's a good recap of the discussion up to this point.
Josh Mandel (Jan 26 2022 at 22:46):
(For the record: Grahame settled this neatly by pointing out that 4.3.0 is a major version update over 4.0.1, since the versioning scheme is "[publication].[major].[minor]" (with an optional ".[patch]" as a fourth component) and therefore breaking changes are allowed.
John Moehrke (Jan 27 2022 at 13:53):
Exactly what breaking changes? We need to be able to be very clear to all of the IG authors, toolkit implementers, applications, servers, etc... WHAT should they lookout for? It seems our message today is vastly different than originally, as originally R4B was only going to change the medicine product stuff that few care about. If someone is fully focused on US-Core, or IPA, or IPS... should they have worries with R4B? Meaning I feel that there has been some "breaking changes" float into R4B that are not as transparent as the FHIR-core members feel they have been transparent about.
Josh Mandel (Jan 27 2022 at 15:34):
If someone is fully focused on US-Core, or IPA, or IPS... should they have worries with R4B? M
I still think the answer is "no worries" here. consistent with our original messaging. The concern I expressed this week is more about clients that are interacting with wider "FHIR native" server capabilities like /_history that can return diverse resource types
John Moehrke (Jan 27 2022 at 15:59):
well, that is what I am asking.. WHAT are these breaking changes. I only know about the medication products new resources that did not exist before.
John Moehrke (Jan 27 2022 at 15:59):
so there is some breaking change in _history? WHY!?!?!?!
Lloyd McKenzie (Jan 27 2022 at 18:24):
The breaking changes are things like "the enumeration of resources have increased", a bunch of medication governance changes. R4B will provide a complete list of the breaking changes.
Josh Mandel (Jan 27 2022 at 20:46):
so there is some breaking change in _history? WHY!?!?!?!
Just the fact that History could now return new resource types that a 4.0.1 client may not understand. The history API still works just the same way.
Lloyd McKenzie (Jan 27 2022 at 21:29):
Right. If a server starts hosting SubscriptionTopic, for example and a 4.0.1 retrieves a history dump of everything (the latter being exceptionally uncommon in real production systems, and even less common where the versions of source and target aren't carefully coordinated), the Bundle would contain resources that the 4.0.1 parser wouldn't handle. From a practical perspective, low risk because anyone who's doing a full data dump is generally going to have a tight business relationship with the source. But technically, still a possible failure mode.
John Moehrke (Jan 27 2022 at 21:34):
documenting clear guard-rails for the common FHIR audience would be helpful to everyone. Many people that use FHIR would have no idea these problems exist, or have any clue how to evaluate them.
Josh Mandel (Jan 27 2022 at 22:35):
retrieves a history dump of everything (the latter being exceptionally uncommon in real production systems
This really depends on your production system. Major cloud-hosted servers support this functionality as a way to make data available for analytics and it's not uncommon at all.
Lloyd McKenzie (Jan 27 2022 at 23:39):
Right, but wouldn't the clients accessing that server for analytics have a deep and specific association with the server - particularly if they're grabbing an unfiltered set of "everything", not limiting to only patient data or some specific subset (whether defined by the request or policy). That should be pretty rare...
Notification Bot (Feb 07 2022 at 21:12):
This topic was moved by Lloyd McKenzie to #fhir/infrastructure-wg > For this week's call
Riki Merrick (Feb 14 2022 at 20:00):
Dear FMG Co-Chairs,OO is requesting time on this week's FMG call to review the following FHIR IG proposal: https://confluence.hl7.org/pages/viewpage.action?pageId=90349274
We also want to verify the time of the call - it is listed as 4-5 PM ET, but also says 90 minutes?
Please let us know, if you can accommodate this request - this project (https://confluence.hl7.org/pages/viewpage.action?pageId=97476801) is trying to go to May ballot
Thank you!!Riki
Lloyd McKenzie (Feb 14 2022 at 21:37):
The call runs 4-5:30, and yes we can take this on.
John Moehrke (Feb 15 2022 at 19:28):
Regrets this week due to conflict with IHE workgroup meeting.
Last updated: Apr 12 2022 at 19:14 UTC
