Stream: implementers
Topic: CodeSystems – hl7.org/fhir vs. terminology.hl7.org
Pascal Pfiffner (Mar 06 2020 at 07:46):
Is there a pattern behind whether a CodeSystem uses "hl7.org/fhir" as its defining URL (e.g. http://hl7.org/fhir/CodeSystem/medicationrequest-status) or uses "terminology.hl7.org" (e.g. http://terminology.hl7.org/CodeSystem/condition-ver-status)? I notice some have moved away from "terminology.hl7.org" in the build when compared to R4 (like http://build.fhir.org/valueset-medicationdispense-status.html) but this is not universal.
Grahame Grieve (Mar 06 2020 at 07:51):
yes. if the URL appears in the instance, or it's a v2 or v3 code system, it will use terminology.hl7.org. if it's a code the gets converted to an enum in generated code, it's maintained with the fhir spec itself, and lives in hl7.org/fhir.
Grahame Grieve (Mar 06 2020 at 07:53):
note that this means that you should allow for codes in terminology.hl7.org to change - to have a different life cycle from the specification itself, where as the hl7.org/fhir codes are locked in to the release they are defined with
Pascal Pfiffner (Mar 06 2020 at 07:59):
That does indeed make sense, thanks!
Josh Mandel (Mar 06 2020 at 13:12):
Can you say more about lifecycle? Like, for a required binding to a nonversioned "terminology.hl7.org" valueset, is it just "validator should use the latest version available"?
Patrick Werner (Mar 06 2020 at 13:42):
That's a great question. I was wondering the same for profile links without a version. Does this imply latest? How is latest defined as version is just a string. Would latest then be: _lastUpdated?
Lloyd McKenzie (Mar 06 2020 at 15:56):
Update policies (and capabilities) will vary. One system might get an update a few seconds after it happens. It might not propagate to another system for weeks. But yes, _lastUpdated is the best way to determine 'latest'. However, servers are also allowed to host multiple versions simulateously - same canonical URL, different version. However, I don't see any mechanism for an old release to indicate it's an old release. @Rob Hausam @Grahame Grieve ?
Grahame Grieve (Mar 06 2020 at 20:30):
server discretion.
Rob Hausam (Mar 06 2020 at 20:42):
I would slightly modify @Josh Mandel's suggestion for the case of a required binding to a nonversioned "terminology.hl7.org" valueset, to "validator should use the latest version that it is aware of". I think that would be the usual expectation, but, as Grahame said, it is up to server discretion. For determining the latest version, as Lloyd said, updates schedules may differ markedly between various entities/organization. But I'm not seeing why we would need or want to have a mechanism for an old release to indicate that it's an old release? I think that normally _lastUpdated or the versions themselves (which often either are or include the date or a numeric sequence) should be sufficient.
Patrick Werner (Mar 07 2020 at 14:07):
it would be nice to have the guidance that conformance resources should use semver in their version field.
Lloyd McKenzie (Mar 07 2020 at 15:59):
Semantic versioning isn't straight-forward to do comparisons on (neither numeric nor alphabetic comparisons work, which makes searching a pain). Plus, if it's a "SHOULD", that doesn't help for the numerous situations where - based on historical convention or otherwise - artifacts will use something else.
Lloyd McKenzie (Mar 07 2020 at 16:01):
_lastUpdated is useless for determining an old release because old releases can be maintained once a new release is out. I.e. _lastUpdated on the 2016 release could be more recent than _lastUpdated on the 2019 release. And .version isn't computably comparable because .version might be "2016" or "Honeycomb" or "0.5.266.17" or "Beta 2" or any number of other things - each of which would require a different comparison algorithm.
Lloyd McKenzie (Mar 07 2020 at 16:02):
Server discretion doesn't help when the server may not have a clue what the algorithm even is - and when the author of the artifact isn't even required to stick with the same algorithm over time.
Lloyd McKenzie (Mar 07 2020 at 16:04):
The cleanest thing to do, I think, is that if there's a new release, you update the old release to point to the new release. The newest release is the one that doesn't have a pointer. However, if it's too hard to update he old items, you can have the new release point to the old release. To find the newest release, you start with the release you've got and chain through, looking for the release that points to what you've got and continue searching until you can't find a release that replaces the one you have.
Lloyd McKenzie (Mar 07 2020 at 16:05):
That's more processing intensive, but doesn't force updating of historical releases. And at least it's reliably computable...
Rob Hausam (Mar 07 2020 at 16:11):
I agree that there are potential issues with this. It's just that from a practical standpoint I haven't seen people struggling with it much (if at all) for the code systems that are generally of interest to the various communities. The suggestions that you made above (whichever direction the pointers go) would work - as long as someone agrees to and reliably does maintain the pointers. If for whatever reason that doesn't occur, then you're not better off (and may be worse off) than you were without any pointers.
Lloyd McKenzie (Mar 07 2020 at 19:43):
I think that's driven by two things:
- systems aren't exposing multiple versions of a given code system; or
- systems are only exposing systems they know well and have custom logic to support
Patrick Werner (Mar 08 2020 at 12:26):
Lloyd McKenzie said:
Semantic versioning isn't straight-forward to do comparisons on
for releases i think it is pretty straight forward. 3 positive integers with a defined hierarchy. Or am i missing something?
Lloyd McKenzie (Mar 08 2020 at 14:26):
The question is whether it works with a simple database comparison operation. I.e. Can you search for MAX(version) and have it reliably work on all databases. That's going to be driven by how "." compares with "0" in a string compare.
Lloyd McKenzie (Mar 08 2020 at 14:27):
But the other challenge is that semantic versioning isn't required (and can't be), which means that using a generic mechanism for comparing versions can't be done
Michael Lawley (Mar 09 2020 at 01:10):
Several issues here:
_lastUpdatedhas nothing to do with business versions. Version ordering of terminology resources is about business versions.- What are the circumstances where a "terminology.hl7.org" valueset will be unversioned? @Josh Mandel do you mean the ValueSet itself has no version or that the binding does not specify a version?
Michael Lawley (Mar 09 2020 at 01:24):
Lesser thing(s):
- Semver makes sense when you want to convey some kind of compatibility story (hence 1 and 2-digit variants and complexity in comparing them). Without a clear compatibility story there's no criteria for which digit to change; best to use date-stamps since they have a simple comparison story.
Robert McClure (Mar 10 2020 at 17:16):
I have to admit this thread just reinforces my belief that we really don't understand how to do terminology versioning (how should semver work? we've struggle with this) and how use of versioning should apply in use cases where it actually matters. Yes, this has been around long enough that we've got ideas, but we've not really tested this at connectathon. I'd love to hear some ideas on how to get some experience with the need for and a better approach then "server discretion" when that ends up meaning it's a crap-shoot.
Patrick Werner (Mar 11 2020 at 15:34):
I am probably blind and/or ignorant, but why shouldn't semver work?
Robert McClure (Mar 11 2020 at 18:54):
We've had problems clearly determining what kind of change results in an increment in which part of the semver. And even if we figure something out for code system, it will be a bit different for value sets. And then others create this content and we reuse it and they never use semver, so there will be LOTS of inconsistency. That said, the UTG will be using a semver approach with the current plan noted here
Michele Mottini (Mar 11 2020 at 19:20):
(deleted)
Michele Mottini (Mar 11 2020 at 19:20):
(deleted)
Last updated: Apr 12 2022 at 19:14 UTC
