Stream: CARIN IG for Blue Button®
Topic: CARIN BB STU1.1 Published
Corey Spears (Jul 07 2021 at 20:22):
New Publication: STU Update Release 1.1 of HL7 FHIR® Implementation Guide: Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®), Release 1 - US Realm: http://www.hl7.org/fhir/us/carin-bb/STU1.1
Ryan Conley (Jul 13 2021 at 14:11):
Can someone explain why there are breaking changes in a minor update? For instance, the way profiles are represented in the meta field for all resources is one such example. Is this intended? Can we not rely on minor version updates of the IG to be backwards compatible in the future?
Ryan Conley (Jul 13 2021 at 15:27):
Also, do you have a response as to how requiring the profile may be considered bad design due to the burden it puts on the consumers?
Corey Spears (Jul 13 2021 at 16:35):
Thanks for the inquiry.
While we attempt to minimize the number of breaking changes in an STU Update, there is no requirement that STU Updates not contain breaking changes. There were a number of issues with the 1.0.0 version of the IG that made it not possible to implement for several uses that were intended to be supported. It was determined that it was important to make an update available as soon as possible to implementers.
All of these changes where subject to the STU Update peer review process and have been reviewed and approved by the sponsoring WG, co-sponsoring WGs, FMG, and TSC.
There was extensive conversation in particular regarding requiring meta.profile. In general, it is not a best practice to require meta.profile unless there is a significant business need to do so. It was ultimately determined that this was necessary in order to enable servers to handle the scale of transactions and management of the resources over time (including handling potential changes to the IG over time).
Josh Mandel (Jul 13 2021 at 17:48):
Regarding:
It was ultimately determined that this was necessary in order to enable servers to handle the scale of transactions and management of the resources over time
Is there documentation of rationale / other considerations from discussion on this point? It's not clear to me how this relates to "scale of transactions" (if anything, I'd expect applying a rigid system of fixed profile tags might lead to fragility that prevents scaling, e.g., scaling servers up to support multiple uses of data with the same core data set.)
Corey Spears (Jul 13 2021 at 20:54):
There is not a collected documentation of rationale. There have been several meetings on the topic (One can find a number of them by searching for the ticket number 30375 on Confluence). As I understand it, this is a concern driven by payer focused organizations.
I am an imperfect messenger for detailing the need that drove this decision, so maybe one of the main proponents can provide a more solid explanation. Otherwise we could possibly arrange some time in the Financial Management WG to review.
Last updated: Apr 12 2022 at 19:14 UTC
