Stream: implementers
Topic: Extension with multiple versions
Mitul Adhia (Mar 01 2022 at 08:18):
Hello All ,
Have some basic questions of profiling with extensions ..
Say I have an extension with its canonical property : URL : http://xyz.com/fhir/test-extension Version: 1.0 with data type valueInt .
Set of questions
- When I introduce new version of above extension say 2.0 is it allowed to change data type from "int" to "string" ? Or should be with same data type only i.e int.
- What are the guidance provided only specific to the extension w.r.t the data type and cardinalities ..
Best Regards,
Mitul
Lloyd McKenzie (Mar 01 2022 at 15:02):
There are no hard & fast rules for extensions defined outside HL7. For extensions published by HL7, we're driven by the 'standards status'. While the extension is still STU, we reserve the right to make breaking changes between releases. Once an extension goes normative (none have yet), then we couldn't make breaking changes any longer.
For those outside the HL7 publication process, they need to define their own policy.
Lee Surprenant (Mar 02 2022 at 14:58):
I think its worth noting that, other than claiming conformance to a given version of a profile, resource instances have no way to indicate which version of a given extension they are using. So I wouldn't recommend breaking changes to extensions.
Lee Surprenant (Mar 02 2022 at 15:00):
this because Extension.url is a uri, not a canonical reference (which I still think is maybe a mistake)
Josh Mandel (Mar 02 2022 at 15:10):
So I wouldn't recommend breaking changes to extensions.
+1 -- best to deprecate and introduce new ones under the current rules, if your extension is used in the wild
Mike Lohmeier (Mar 02 2022 at 16:20):
We've tried our best to leverage the Business version as an overall version of all our extensions for the whole of our FHIR API. So, a client can at least have a pointer to what semantic version all extensions the current FHIR API is using and line up the documentation/tooling. In addition, we've also done everything we can to make our extensions as loosely defined as possible to help prevent reverse/forward compatibility woes. For example: using CodeableConcept instead of ValueSets , defining References to any as opposed to specific resources and creating new extensions and fields when we hit breaking changes that don't merit the time/$ of a full extension major version. This generally works to funnel changes to minor versions but pushes a lot of the complexity of versioning to the clients and doesn't allow for clients to pin to a specific version for both the interface and behavior. Which despite this versioning scheme being technically correct and us providing documentation/tooling that account for the loosely defined nature of our extension versioning, will undoubtedly lead to failures in production in clients.
For major version changes to our extensions, we're looking at having to run different infrastructures for each major business version to separate by base API URL the breaking changes for clients. Luckily, we have been able to address most change to extensions via the loosely defined definitions and have avoided breaking changes to our extensions that merit a new major business version like the plague.
Last updated: Apr 12 2022 at 19:14 UTC
