Stream: shorthand
Topic: Support for version instances
Jose Costa Teixeira (Jan 29 2020 at 00:51):
Unless I'm missing something, the assumption that the filename is the same as the resource id is not allowing to use different versions
Jose Costa Teixeira (Jan 29 2020 at 00:52):
I have a careplan-001, where I have
v1: status = draft
v2: status= active
Jose Costa Teixeira (Jan 29 2020 at 00:53):
v1 and v2 are on meta.versionId
Chris Moesel (Jan 29 2020 at 13:57):
I thought that the publisher requires the filename to be ${type}-${id}.{json|xml}... is there room for the version number in that filename algorithm somewhere? I don't think I ever thought about having two versions of the same SD in the same IG. Since you're asking, I'm guessing that this is allowed?
Chris Moesel (Jan 29 2020 at 14:00):
Actually, I see the thread in IG Creation now in which Grahame seems to say you can't have two versions of the same resource in a single IG: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Adding.20versioned.20examples.20to.20an.20IG/near/186857008
Did I interpret that discussion correctly or did I miss the point?
Jose Costa Teixeira (Jan 29 2020 at 16:43):
My question there was whether and how we can allow this for IGs. I'd say we should but only Grahame and Lloyd can determine the impact.
For sushi, I'd suggest we really should support versions. Perhaps sushi should wait for the decision for the IGs, but IMO sushi is not only for making IGs, right?
Chris Moesel (Jan 29 2020 at 17:31):
Well... SUSHI requires you to specify a canonical URL (in package.json), so the assumption is that what you're creating is at least in the same _package_. And I'd assume (but it is an assumption) that any rule regarding uniqueness for IGs would also probably apply to packages. So for now, you'd need different versions to be in different SUSHI projects.
Let's see what Grahame, Lloyd, and the community say. Right now SUSHI makes some assumptions about uniqueness of names/ids, so adding support for definitions that differ only by version will require some rework.
Jose Costa Teixeira (Jan 29 2020 at 17:34):
I imagine it will require some rework. Or perhaps we issue a workaround. But we must somehow support versions, even if the IG publication doesn't (yet/ever).
Jose Costa Teixeira (Jan 29 2020 at 17:37):
If the sushi assumptions did not include versions, now is a good time to change our assumptions. Rework later is going to be more expensive, as will be finding yet another alternative to create instances
Chris Moesel (Jan 29 2020 at 19:34):
SUSHI does support multiple versions, it just assumes a single-version per resource per SUSHI project. To be clear, you're suggesting that a single project should support multiple versions of a resource w/ the same name and id (but different versions), right?
Jose Costa Teixeira (Jan 29 2020 at 19:42):
Yes. Some resources like CarePlan, task are evolving over time. They will have different versions.
Jose Costa Teixeira (Jan 29 2020 at 19:43):
Resource history is core (although optional for servers) but to do some decent workflow it becomes kind of mandatory
Jose Costa Teixeira (Jan 29 2020 at 19:44):
Hence my example - CarePlan draft --> active...
Jose Costa Teixeira (Jan 29 2020 at 19:46):
I think assuming a single version per resource id per project does conflict with this need, what do you think?
Jose Costa Teixeira (Jan 29 2020 at 19:49):
I will ask for the same need on the ig publication side but the current ig limitation should not become legacy/debt for other tools
Last updated: Apr 12 2022 at 19:14 UTC
