Stream: implementers
Topic: Custom Resources - Future Releases
Mike Hamidi (Sep 15 2021 at 16:36):
In the Vulcan RWD track, a topic that was brought up was around using future resources (e.g. NutritionProduct via R5 see http://hl7.org/fhir/2020Sep/nutritionproduct.html) as part of R4. It was mentioned that the basic resource (see https://www.hl7.org/fhir/basic.html) could be leveraged to do this which requires heavy use of extensions. Has there ever been discussion on using non-release core resources that could be more formalized and accessible to the industry? Otherwise, such resources would be limited in implementation. Thoughts?
Gino Canessa (Sep 15 2021 at 18:55):
I'll preface this post by saying that I do not love the current versioning strategy / upgrade story for FHIR.
That said, there is a story, and it's quite valid.
Generally speaking, a storage server can support arbitrary data, a workflow server may be able to (with a robust language), but more than that.. supporting artifacts you don't know about doesn't work.
For example, if you add support for NutritionProduct to an R4 server, you can CRUD that data. But, what clients can do anything with it? None that support R4. What if it uses new data types that were introduced in R5? Or contains links to other R5+ resources? What could a client application displaying that 'type' of information from R4 do with it? Practically speaking, I'm not aware of a good story here. With a focus on interop, that level of fragmentation is terrifying.
But, I also think that we need a better story around 'stable' resources vs. 'in development' resources. There are a lot of potential ways of doing this (e.g., semver-style: need an appropriate level release change to modify something of that maturity (most stable are a full version release, down to 'new' things added/changed in point releases); independent 'stable' and 'supplemental' packages, etc.). There have been a lot of discussions around the topic on a number of streams, but to my knowledge there hasn't been any 'push' in a direction.
Lloyd McKenzie (Sep 15 2021 at 18:58):
The base challenge is that the reference implementations, schemas, and a whole lot of servers depend on the fact that there's a single FHIR schema in use throughout the world for a single FHIR version. That produces a lot of interoperability wins. The cost is that as the specification grows and as industry's capacity to accept change slows, it's harder to move new content forward. R4B was our first experiment with "moving faster" (and it turned out to not be nearly as fast as we might have hoped). It certainly won't be our last experiment in that direction, as we recognize that 3.5 years between releases is way too long for immature content that needs a chance to iterate. But it's unlikely that the end solution will be to allow mixing and matching whatever versions you like.
Mike Hamidi (Sep 15 2021 at 19:08):
@Gino Canessa You bring up some great points. It is something that should be considered in the confines of the current release. How to mimic a future resource that does not disrupt the current release is another question in itself. What we don't want is for implementers and users of FHIR to wait until they upgrade.
Mike Hamidi (Sep 15 2021 at 19:09):
@Lloyd McKenzie The mixing of releases sounds like an interesting idea. Having an agile way to keep up over time would be a big win as well.
John Moehrke (Sep 15 2021 at 20:46):
I would prefer we get back to a two year cycle... period. we got distracted by the shiny ONC thing. No reason why we couldn't do regular releases on a regular basis
John Moehrke (Sep 15 2021 at 20:46):
workgroups get to add resources using the normal means.
John Moehrke (Sep 15 2021 at 20:47):
this does mean that workgroups likely need to have feature branches where they can work on things that take more than the release cycle window.
Lloyd McKenzie (Sep 16 2021 at 17:22):
I don't think the release timing had anything to do with ONC?? We were driven by three things - reduced community capacity (thanks Covid), a bigger product (which slows everything down), and less desire from the implementer community to have a 'new thing' any time soon - and in fact in some cases a push to defer. If we push out a new release every 2 years, but the community (reference implementations, EHRs, etc.) ignore every second release, all we've bought is broken expectations and less interoperability.
Lloyd McKenzie (Sep 16 2021 at 17:24):
I think a release process where certain 'dynamic' resources (that only a subset of the community cares about or that have maturity of <3) can change but everything else is limited to technical corrections only might be viable. Even there, I expect we'd be looking at "big release", 18 months, "dynamic release", 18 months, "big release".
Last updated: Apr 12 2022 at 19:14 UTC
