Stream: implementers
Topic: R4 diff.html version-specific ValueSet URIs
Ken Sinn (Jan 17 2019 at 19:29):
Reviewing the R4 changes, we noticed many of the ValueSet bindings are now version-specific. Is there an expectation that all R4 and later profiles and resource instances use version-specific ValueSet and CodeSystem and StructureDefinition URIs now? What was the reasoning for adding version-specificity to the diff.html, and what are the potential implications of this?
For example, "Address.use: Change value set from http://hl7.org/fhir/ValueSet/address-use to http://hl7.org/fhir/ValueSet/address-use|4.0.0". Will all future release notes/diffs need to reflect the new release version then, e.g. http://hl7.org/fhir/ValueSet/address-use|5.0.0 or even http://hl7.org/fhir/ValueSet/address-use|4.1.0, etc?
Thanks for any insight you can provide!
Grahame Grieve (Jan 17 2019 at 19:45):
required bindings to code elements were all updated to be version specific. That this appear in the R3 diffs was an oversight, and unfortunate. I will ensure that this doesn't happen for R5
Ken Sinn (Jan 17 2019 at 19:53):
Thanks Grahame. So for most practical implementations, we shouldn't need to include version-specific URIs for bindings, correct? (unless there was a specific business need)
Grahame Grieve (Jan 17 2019 at 19:54):
I'm not exactly sure what you mean by your question. Do you mean, in your profiles on the resources? do you mean, in your own profiles on other elements?
Ken Sinn (Jan 17 2019 at 19:59):
In our profiles of FHIR R4 resources, will we need to specify version-specific url for ValueSet bindings? Or is the canonical url sufficient for the ValueSet bindings?
We weren't sure if there were some new expectations to be explicitly version-specific, due to the diff notes.
Grahame Grieve (Jan 17 2019 at 20:03):
well, it depends on what you want to achieve. If you want updates to the value set to apply to the profile, so that later use of the profile picks up later value sets, then you don't want versioned value set references
Lloyd McKenzie (Jan 17 2019 at 20:13):
That change is intended to reflect the fact that the codes are "locked" for R4. If you claim to be R4 conformant, you can't use codes other than those in that version, even if new codes get added to the code system in the future. (On the other hand, if the value set binding isn't locked down, it means that if the value set or code system evolves in the code system, that new codes are available.)
Ken Sinn (Jan 17 2019 at 20:21):
Right, but that's always been the case for STU3 and DSTU2. That is, a system conformant to STU3 could only use codes from the STU3 code system and value set, but we never called out the version explicitly before, the way they've been called out this time around.
I just wanted to confirm that there are no new rules/expectations around version-specific urls, in light of what was generated in the diff notes.
Lloyd McKenzie (Jan 17 2019 at 20:51):
That's true. We're just using appropriate formal mechanisms to make that obvious programaticly
Lloyd McKenzie (Jan 17 2019 at 20:51):
I believe all of the version-specific locations are for bindings with 'code' elements - which means there should be no URLs at all
Lloyd McKenzie (Jan 17 2019 at 20:52):
In any event, version doesn't show up in the Coding.system element - that's always just the canonical URL. If you care about version, that appears in Coding.version
Grahame Grieve (Jan 17 2019 at 21:58):
it had always been the case for past versions, but we didn't actually explicitly say it was the case
Ryan Cassano (Jan 30 2019 at 14:42):
@Ken Sinn Can you advise where you found the R4 changes? I was hoping to find somewhere to compare FHIR versions and maturity levels? Thanks!
Ken Sinn (Jan 30 2019 at 15:06):
@Ryan Cassano The change log between STU3->R4 is here: http://www.hl7.org/fhir/diff.html
For maturity level changes, you may have to compare http://www.hl7.org/fhir/resourcelist.html vs https://www.hl7.org/fhir/stu3/resourcelist.html (use the Alphabetical listing view)
Ryan Cassano (Jan 30 2019 at 19:28):
@Ken Sinn Excellent, thanks so much!
Last updated: Apr 12 2022 at 19:14 UTC
