Stream: implementers
Topic: Versioning of extensions
Sadiq Saleh (Feb 23 2017 at 14:16):
What the standard practice for versioning extensions should be? Should versions of extensions be incremented along with the profiles that refer them? Or should they be versioned independently?
Currently we are adding version info to the StructureDefinition files for extensions manually, but I was not sure how to deal with this.
Thanks for any feedback.
Lloyd McKenzie (Feb 23 2017 at 14:40):
The IGPublisher now has an option that lets you version *everything* in the IG to a specific business version - so extensions, profiles, value sets, capability statements, etc. That's significantly less maintenance effort and may be easier for your implementers to wrap their heads around too.
Sadiq Saleh (Feb 23 2017 at 16:39):
Thanks @Lloyd McKenzie . We discussed this internally and were debating about whether versions should be incremented for all the fragements of the IG simultaneously.
In our view the only challenge with this is that when exchanging an updated IG with another party, it would help to know which fragments have changed and which are the same as this would allow them to know what needs to be updated on their end to comply with the new IG.
Lloyd McKenzie (Feb 23 2017 at 17:17):
Business versions don't necessarily change just because an artifact has been updated, so even if the version is the same, that doesn't mean a comparison isn't necessary
Sadiq Saleh (Feb 23 2017 at 18:24):
Could you clarify on that statement? What would prompt a business version to change that is unrelated to changes in the underlying artifacts? Just so I am sure I understand properly.
Lloyd McKenzie (Feb 23 2017 at 19:03):
Multiple changes could happen before a business version changes. And you could release a new business version even if the artifact hasn't changed. E.g. Publishing the 2015 version of a code system which happens to be identical to the 2016 version of the code system.
Sadiq Saleh (Feb 23 2017 at 19:49):
So from what I understand, the reasoning is that with a business version increment, the receiving system can not assume that any of the artifacts are the same and thus is required to verify the integrity of each artifact individually?
This is the understanding that we came to as well, which was why we thought to version each artifact individually to take some of the burden away from the receiving system: i.e. for the receiving system, if the version of the artifact is the same you can assume no changes. If there is a versoin change you should identify the discrepancies.
Lloyd McKenzie (Feb 23 2017 at 19:53):
Well, if the business version is the same and the artifact is marked as "active" then there shouldn't be any substantive changes, but right now that's a "should", not a "shall"
Sadiq Saleh (Feb 23 2017 at 22:37):
Ah I see. So therefore if I go from version 1 to 2 of a business version, all resources should be marked as "draft" status to be changeable, and it is only when everything is maked as "active" that the IG is considered a complete version and frozen. Is this correct?
Lloyd McKenzie (Feb 23 2017 at 23:13):
Right. If you're using version control, the typical process would be you'd have an IG in version control and once you're ready to take it from "draft" to "active", you'd create a branch for that version and then make the change to "active" on that branch. The mainline could continue to evolve until you're ready to do your next IG release and you could make technical corrections or other tweaks to the "released" IG version by updating the branch if need-be.
Patrick Ryan (Feb 15 2022 at 00:14):
Hi - I'm using FSH to create a codesystem. I explicitly set the version with * ^version = "2.7".
When I run sushi, the fsh-gnerated json has the correct version.
However when I run the IG Publisher, the xml and json it generates revert to the version specified in sushiConfig.yaml
-- here is my FSH file
CodeSystem: Hpi_address_use
Id: Hpi_address_use_2_0
Title: "OrgFac Address Use"
Description: "A coded type for organisation/facility address purpose (qualifier)."
- ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablecodesystem"
- ^url = "https://standards.digital.health.nz/ns/hpi-address-use"
- ^version = "2.7"
- ^status = #active
- ^experimental = false
- ^date = "2020-04-20T00:00:00+13:00"
- ^publisher = "New Zealand Ministry of Health"
- ^purpose = "A coded type for organisation/facility address purpose (qualifier)."
- ^caseSensitive = false
- ^versionNeeded = true
- ^content = #complete
- ^count = 3
- #legal "Legal Address" "An address of the legal registered office (active)."
- #work "Work Address" "An office address. First choice for business related contacts during business hours."
- #old "This address is no longer in use (or was never correct but retained for records)."
Elliot Silver (Feb 15 2022 at 00:25):
There is an IG parameter "apply-version" that is supposedly usually helpful, but gets in the way from time to time. See https://confluence.hl7.org/display/FHIR/Implementation+Guide+Parameters. You'll want to specify it as false or use the new default-version parameter in your sushi-config.yaml.
Patrick Ryan (Feb 15 2022 at 21:40):
thanks
- do I need to create a custom template to apply these parameters?
Patrick Ryan (Feb 16 2022 at 00:08):
I tried putting the parameter in sushi-config.yaml:
parameters:
.
.
.
apply-version: false
but it had no impact-
I needed to edit the generated file
fsh-generated\resources\ImplementationGuide<xxx>.json
and that had the desired effect
Chris Moesel (Feb 16 2022 at 00:10):
@Patrick Ryan -- if you put parameters into the sushi-config.yaml file, they should be properly reflected in the fsh-generate\resources\ImplementationGuide<xxx>.json file. If they're not, then it sounds like the formatting in sushi-config.yaml is probably not quite right.
Patrick Ryan (Feb 16 2022 at 00:40):
thanks - yes I was missing an indent
Last updated: Apr 12 2022 at 19:14 UTC
