Stream: terminology
Topic: Composition by canonical
Ewout Kramer (May 02 2018 at 16:06):
Hi all, I was talking to @Robert McClure, discussing the consequences of the new canonical datatype, when I noticed that ValueSet.compose.include uses system and version to refer to a code system, but at the same time uses a canonical to refer to a valueset. Now, I can imagine how this came about, but changing that reference to canonical would not only make it more consistent, it would also add the capability of managing resolution of unqualified canonicals (so canonicals without a version) in much the same way as resolution of ValueSets.
Ewout Kramer (May 02 2018 at 16:08):
There is actually much more to say about this, since this refers back to discussions we have been having during the last WGM, where we're investigating how to deal with a world where references to valuesets and codesystems and profiles are mostly not versioned, while we live in a versioned world. For those not there (and a bit technically inclined), you can read more about a possible solution here: https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/)
Ewout Kramer (May 02 2018 at 16:09):
It would be nice if the solution for version resolution of ValueSets would be the same for CodeSystems, and it looks like it's not currently the case.
Rob Hausam (May 02 2018 at 16:38):
I think I agree with you that making that change to canonical for code systems should be able to meet the need (unless there's an aspect that I'm forgetting). In many cases code systems that are referenced may not actually have a CodeSystem resource instance that is being referred to, but I don't think that should be an issue. And I agree that it makes sense to use a consistent approach in both cases. But it's also a quite significant change to a resource which is a normative candidate (of course it would have been good if we had done it at the same time with all of the other updates to move to canonical). So I'm not sure what my conclusion is on it yet.
Lloyd McKenzie (May 02 2018 at 18:32):
We don't want code system to be canonical. We're not allowed to use "|version" there - unless we wanted to move to Coding using canonical - which would be a rather huge shift at this point.
Rob Hausam (May 02 2018 at 19:15):
I agree, that is precisely the issue. It would be a rather huge change - and I don't know if the benefit of having improved consistency would be sufficient for us to do it.
Yunwei Wang (May 02 2018 at 19:48):
According to Using SNOMED on FHIR page: http://build.fhir.org/snomedct.html#4.2.1.0.2, the version number should be embeded in URL.
http://snomed.info/sct/[sctid]/version/[YYYYMMDD]
Yunwei Wang (May 02 2018 at 19:49):
In this case, still need to fill version element?
Peter Jordan (May 02 2018 at 21:02):
This was discussed at yesterday's SNOMED on FHIR call. The general consensus was that the CodeSystem.url for SNOMED CT should be http://snomed.info/sct - i.e. a URI that is immutable across editions/modules and versions. The CodeSystem.version for SNOMED CT carries the SCTID for the module/edition and version.
Robert McClure (May 02 2018 at 21:08):
I don't see an issue with using |version as a part of a switch to the code system uri being canonical. Yes, it's a shift but this way we can consistently reference identifier and version for things that need to be versioned and resolve canonical identifiers in the same way. I am very opposed to making code system, or any terminology component, a one-off variant of the approach we finalize on for determining the correct version of things to be used for an implementation. I also don't see a problem with supporting sct needs within canonical.
Rob Hausam (May 02 2018 at 21:19):
@Yunwei Wang The intent of that documentation on the "Using SNOMED CT with FHIR" page is for what to use for the 'version' parameter, not for 'url' - the url is always intended to be http://snomed.info/sct (as noted in the Summary table, and as Peter said).
Michael Lawley (May 02 2018 at 23:07):
Just to be clear, this: http://snomed.info/sct/[sctid]/version/[YYYYMMDD] is the format of a SNOMED CT version "number". It is not a valid URI for the SNOMED CT CodeSystem.
Ewout Kramer (May 03 2018 at 06:06):
We don't want code system to be canonical. We're not allowed to use "|version" there - unless we wanted to move to Coding using canonical - which would be a rather huge shift at this point.
I see how we switch here between referring to a CodeSystem as the Resource (even if unavailable) and codesystem as part of a codesystem+code pair referring to a concept from a codesystem. If we could say Coding does the latter, while compose does the former, it looks like we could still do it. But I agree it feels like a big change, and I don't want to redo any discussions you might already have had about this. The consequence though is that version management for ValueSets /CodeSystems is treated differently from other conformance resources, while I have the feeling the versioning problems we try to solve with canonical are basically the same...
Peter Jordan (May 03 2018 at 06:35):
One reason for this distinction is that Code System and Value Set uri and version formats are often specified by external organisations.
Lloyd McKenzie (May 03 2018 at 12:23):
That's not technically an issue. While the canonical URL should resolve to the resource, it doesn't have to. For example, the canonical URLs for LOINC-defined value sets don't currently resolve.
Rob Hausam (May 03 2018 at 14:19):
Right - there isn't a technical issue with using canonical for this.
Robert McClure (May 03 2018 at 18:53):
If there is no technical barrier, then I think there are good reasons to align and use canonical. Just because SCT will be long and convoluted doesn't ruin the approach. And I don't think we need to make everything fit the old way just to satisfy the SCT crowd.
Peter Jordan (May 03 2018 at 21:11):
It would be useful to understand the benefits of making this change from both server implementation and client perspectives. SCT requirements are critical for us (and others I suspect) without that, we'd have no business case for using a FHIR Terminology Services API.
Lloyd McKenzie (May 04 2018 at 04:20):
@Grahame Grieve Do you have opinions on this - moving system to be a true canonical, including using the canonical approach to version in Coding? (And thinking too about the possibility of canonical becoming a complex type.)
Grahame Grieve (May 05 2018 at 04:34):
so @Ewout Kramer says about that value set canonicals are different to everything else, but I don't believe that's true. Value set references work just like everything else (and Ewout is balloting on my behalf that they should be more strongly aligned than they are in binding)
Grahame Grieve (May 05 2018 at 04:35):
code system references are different to everything else. There's a reason for that, because we do not handle code systems like everything else. We've deliberately chosen not to take on part of the code system scope, and we've recognised that most important code systems will not be distributed using the code system resource. And we've got the tie between Coding.system/version and the code system URL.
Grahame Grieve (May 05 2018 at 04:36):
so I think that changing valueset.compose.system to a canonical is a mistake, and I am very strongly opposed to considering changing the way Coding.system works. That would be a procedural disaster as well as wrong
Rob Hausam (May 05 2018 at 12:19):
As @Grahame Grieve has stated, code systems are different - we have chosen not to take on part of the code system scope and most important code systems will not be distributed using the CodeSystem resource. With that in mind it doesn't entirely follow for me that CodeSystem references must be handled differently from everything else and could not use canonical. But unless there's a further argument that I haven't heard or grasped it doesn't seem to me that changing to canonical for CodeSystem references would buy us anything other than a small bit more consistency and no additional actual functionality. And it may be useful to highlight that CodeSystem is different in this way, as Grahame suggests. So unless there is a further argument or explanation of why it's needed, I'm not in favor of making the change.
Robert McClure (May 05 2018 at 18:00):
Look folks @Grahame Grieve , @Rob Hausam, just because you say "code systems (standard HL7 refrain here) are out of scope for FHIR" doesn't allow you to keep pretending you don't actually do it. FHIR terminology is gaining a HUGE footprint and there are MANY MANY FHIR code systems that can only be obtained from a FHIR server. So enough with the pretend fantasy that you can do things because "FHIR doesn't manage code systems" - I call BS. It took HL7 3 decades to admit they actually need to manage terminology and you all are a big reason "we" can now do it, so let's be honest a bit sooner here. Second, What do you mean @Grahame Grieve that we already treat value sets the same when we clearly do not unless you can clarify how we can manage value sets (and code systems) using npm without making this change. And @Peter Jordan, You are going to have to help me understand why using canonical breaks SCT references. So far I can tell that is not true.
Peter Jordan (May 05 2018 at 20:21):
@Robert McClure Looking at the FHIR definition of canonical urls at http://hl7.org/fhir/2018May/references.html#canonical - do you think that the url property of a CodeSystem resource representing SNOMED CT - http://snomed.info/sct - conforms with that definition? Or try testing that url using this...
https://seositecheckup.com/tools/url-canonicalization-test
Grahame Grieve (May 06 2018 at 03:23):
I didn't say that code systems are out of scope for FHIR. What I said was 'we decided that some aspects of code systems are out of scope' for FHIR. I said that we treat value set urls as canonicals, the same as we do for other conformance resources
Grahame Grieve (May 06 2018 at 03:23):
but we do treat code system references as slightly different, for several reasons that I think are valid
Robert McClure (May 06 2018 at 15:57):
@Peter Jordan Yes, I've looked at the definition. Yes I think no matter how this ends up working it's going to be a mess for all of FHIR, not just terminology, hence my support for an npm-like solution and absolute need for a central registry. Yes, it seems that SNOMED did not read this when they selected http://snomed.info/sct as canonical, and it fails miserably on the test site. But so what? They can fix that. And my concern is more about using versioning via canonical and I still think while the approach SCT has chosen does not work well in this scheme, if FHIR agrees to make all of this canonical things can be fixed so it works. So I don't see an issue.
Peter Jordan (May 06 2018 at 21:28):
Perhaps we should discuss this further at a Connectathon breakout session?
Rob Hausam (May 06 2018 at 22:27):
Yes. I don't think that all of what is being said is coming from a common base of understanding. And we need to be together on that before we decide on solutions for problems that we've identified (once we agree on what they are).
Michael Lawley (May 07 2018 at 22:34):
@Robert McClure I don't follow your point re http://snomed.info/sct and that google link. These are URIs not URLs (Identifies, not Locations). Resolving them is irrelevant wrt FHIR or their intended use.
Note, I can understand why you may be confused -- the FHIR documentation does not make a clear distinction in its use of "url" and "uri" - witness this statement from http://hl7.org/fhir/2018May/references.html#canonical
2.3.0.5 Canonical URLs
Many resource types have a defined element "url" which is the canonical URI that always identifies the resource.
Robert McClure (May 08 2018 at 19:47):
@Michael Lawley I was just responding to Peter's comments about testing the uri as a url. I agree, that uri for the system is a uri even though the datatype is url. As for the rest of it - let's discuss next week. To keep from swallowing an entire Q, perhaps we need to meet at a separate time @Rob Hausam ?
Last updated: Apr 12 2022 at 19:14 UTC
