Stream: implementers
Topic: Canonical URL with FHIR version?
Ardon Toonstra (Jan 25 2021 at 14:17):
Perhaps this is already been discussed a couple of times, but I am still wondering about the pro's and con's of adding a FHIR version inside the canonical URL, for example, https://example.org/R4/StructureDefinition/myPatient or https://example.org/4.0/StructureDefinition/myPatient.
My take on it: the FHIR spec doesn't do it. Neither a lot of other big projects such as us-core. However, there are also examples of projects or organization who do add it.
It may be helpful for a human to see in the instance if a meta.profile is used to which FHIR version it conforms. On the other hand, implementers need to update the meta.profile tags and the profile author may have more maintenance as it will introduce another version element to the already existing places for version e.g. the npm package / SD.version / SD.fhirVersion.
I am I missing things? What do you think?
Lee Surprenant (Jan 25 2021 at 14:38):
What are the examples where canonical urls like these are including the version?
I would think that poor form because FHIR explicitly includes a datatype for combining the "canonical url" and "version" into a single field: https://www.hl7.org/fhir/datatypes.html#canonical
Lee Surprenant (Jan 25 2021 at 14:39):
you'd use a url like https://example.org/StructureDefinition/myPatient and instances can claim they conform to version 4.0 of that by including the following profile value: https://example.org/StructureDefinition/myPatient|4.0
Ardon Toonstra (Jan 25 2021 at 14:56):
I believe the version behind the | is about the SD business version and not the FHIR version.
Lee Surprenant (Jan 25 2021 at 14:59):
oh, i see, i thought you were referring to the SD version. my bad
Lloyd McKenzie (Jan 25 2021 at 15:42):
Traditionally, a version number in your base meant that that endpoint was the one that served up that particular version. As we move to using http content negotiation for that, that's less necessary. Also, you might want to retrieve STU3 or DSTU2 structure definitions from an R4 endpoint, so having a version in the endpoint name is going to be somewhat confusing.
Vadim Peretokin (Jan 25 2021 at 15:53):
FHIR doesn't include the version in instances to make them more interoperable - by including it in the profile of the instance you'd be defeating that point, so I'd say no, don't include - unless you intend to support 2 versions of FHIR at the same time.
Vadim Peretokin (Jan 25 2021 at 15:54):
That said would be interested to know what is people's experience working with US core, which like you say has exactly the same canonicals yet different profiles for STU3 and R4, see <http://hl7.org/fhir/us/core/StructureDefinition-us-core-allergyintolerance.html> and <http://hl7.org/fhir/us/core/STU2/StructureDefinition-us-core-allergyintolerance.html>
Gino Canessa (Jan 25 2021 at 19:29):
There's an important distinction between FHIR version and business version of the resource. To continue with the example, if you need to change myPatient|4.0, you also need to increment the version (e.g., 4.1, 4.0.1, etc.). This is not related to the FHIR version. Conversely, technical corrections change the FHIR version number (e.g., 4.0.0 to 4.0.1), and those do not generate a new version of anything defined in IGs.
So, if you want to use a FHIR version in the URL, I'd recommend using the name (e.g., R4) over the version number, since those ARE going to change over time (and I assume you don't intend to publish a new version for every technical correction). It also helps a bit with confusion, so you don't have urls like http://example.org/4.0/StructureDefinition/myPatient|3.2.
Last updated: Apr 12 2022 at 19:14 UTC
