Stream: implementers
Topic: Definition pattern
John Timm (Sep 16 2019 at 15:23):
@Lloyd McKenzie
Is there a particular reason why NamingSystem doesn't have a url or version like all of the other resources that map to the definition pattern:
http://hl7.org/fhir/definition.html
Lloyd McKenzie (Sep 16 2019 at 15:58):
Yes. NamingSystem can have multiple URLs and uses the 'preferred' flag to indicate which is the appropriate one for use. It's also not something one can bind to or declare conformance to, so 'version' isn't really necessary. (We do have 'period' on each identifier to indicate when they were valid.) The purpose of having a canonical is that it's a single reliable identifier that can't change. With naming systems, sometimes it could change. (We don't like it when that happens, but sometimes business processes make it unavoidable - e.g. when two systems independently define different URLs for the same system and then later one of them needs to migrate.) Also, having a distinct canonical URL that's independent from the actual URLs to use in the instances would have been confusing.
Grahame Grieve (Sep 16 2019 at 16:12):
please make a task. It's reasonable for NamingSystem to be consistent, and to have a url for tracking the registration
Lloyd McKenzie (Sep 16 2019 at 20:23):
We've had a task. And rejected that task. If we're going to revisit, we need considerations not covered by the previously submitted request and would need to vote to re-open the discussion.
Grahame Grieve (Sep 16 2019 at 23:22):
the canonical would be the URL of the registration not the actual system. that apparently is not a consideration from the previous request.
Grahame Grieve (Sep 16 2019 at 23:23):
I do not understand why NamingSystem is somehow different in terms of it's own handling and publishing and why we refuse to acknowledge the frequent requests to normalise these
Lloyd McKenzie (Sep 16 2019 at 23:35):
NamingSystem's whole purpose is to manage URLs - and the one that's "preferred" is dynamic. Creating yet another URL for the system purely for consistency's sake is invariably going to create confusion and mis-use. If we give guidance that that canonical URL should be the preferred URL, what happens if the preferred URL changes? How do you merge two NamingSystems when you realize that they're talking about the same thing? If we give guidance that the canonical URL for the naming system should be distinct from the preferred URL, how do we prevent people from using it by accident? What happens if people want to use the [base]/NamingSystem/id as their canonical URL? (Which I consider best practice in many cases)
Lloyd McKenzie (Sep 16 2019 at 23:36):
Adding NamingSystem.url is going to cause pain for the users in order to save pain for tool-smiths. I'd much rather cause pain to tool-smiths and save pain for those who are using NamingSystem to manage systems.
Grahame Grieve (Sep 16 2019 at 23:37):
Creating yet another URL for the system
That's exactly what I didn't say.
Lloyd McKenzie (Sep 16 2019 at 23:52):
If the NamingSystem.url is the "preferred" URL, what happens when the preferred URL changes? It's the same NamingSystem. We don't allow that to happen for anything else that has a canonical URL. Also, what sense does "version" make for a NamingSystem?
Grahame Grieve (Sep 16 2019 at 23:53):
NamingSystem.url would be the url of the naming system record, not the system. And version makes sense, so that you can talk about which version of the registration you have - which is most recent
Lloyd McKenzie (Sep 16 2019 at 23:56):
Can the NamingSystem.url be one of the NamingSystem.identifier.values?
John Timm (Sep 17 2019 at 15:10):
Just as a follow-up, this section of the spec:
http://hl7.org/fhir/references.html#canonical
mentions NamingSystem as something that has a "defined url element"
Grahame Grieve (Sep 17 2019 at 15:13):
Can the NamingSystem.url be one of the NamingSystem.identifier.values?
I think it shouldn't be. It isn't the system that it identifies, it's the registration record. So it shouldn't be the same identifier
Lloyd McKenzie (Sep 17 2019 at 20:46):
Ideally, you want the canonical URL to resolve to something - and you want it to resolve stably and reliably. Having the url be the instance URL for the NamingSystem registry ensures that.
Ewout Kramer (Sep 18 2019 at 02:18):
But that would prevent you from having several repos with distributed copies of the NamingSystem artifacts. That's why you resolve these by searching on url in a repo - and you would not be able to do so if NamingSystem did not have an url.
Ewout Kramer (Sep 18 2019 at 02:20):
"Lloyd McKenzie 19:52
If the NamingSystem.url is the "preferred" URL, what happens when the preferred URL changes? It's the same NamingSystem."
That's the perfect argument for having a canonical and NOT using the preferred URL for it. The real key of a NamingSystem is an independent canonical, not one of the (possibly changing) uniqueIdentifiers.
Lloyd McKenzie (Sep 18 2019 at 02:51):
If the preferred URL of a NamingSystem is the url of the NamingSystem on the registry where it lives, you don't have to worry about it changing - because it's not subject to the organizational changes and/or website redesign of the system owner. It's a stable FHIR-specific URL.
Lloyd McKenzie (Sep 18 2019 at 02:52):
You can search for the NamingSystem by URL now - it would match on the URLs that are 'identifiers' for that NamingSystem
Ewout Kramer (Sep 18 2019 at 13:47):
No, I mean that it's almost never the url of the registry. I would not want a namingsystem to have "simplifier" in its canonical for example. We are looking for a stable canonical that can remain the same across registries for the same NamingSystem, and that does not change when the list of identifiers or the preferred identifier changes, since this canonical might be used in other artifacts to refer to the NamingSystem.
Lloyd McKenzie (Sep 18 2019 at 14:09):
In Canada, most of our entries have "http://infoway-inforoute.ca/fhir/NamingSystem" as the root of their canonical URLs - for provincial licensing bodies, etc. Not all (if someone has a URL and are confident it'll be consistent, we'll use that instead), but that's the default.
Last updated: Apr 12 2022 at 19:14 UTC
