Stream: implementers
Topic: Canonical identifiers
Alexander Kiel (Jul 31 2019 at 15:01):
Are all data elements with name <ResourceName>.url and datatype uri canonical identifiers which have to be globally unique? Examples are Library.url and Measure.url. In other words, can I enforce uniqueness on every such <ResourceName>.url data element? Or is there an explicit way to detect, with a StructureDefinition at hand, that a data element is such a unique identifier?
Michel Rutten (Jul 31 2019 at 15:11):
Hi @Alexander Kiel, the .url values should uniquely identify the resource:
http://hl7.org/fhir/measure-definitions.html#Measure.url
...also called its canonical identifier. This SHOULD be globally unique... This URL can be the target of a canonical reference. It SHALL remain the same when the measure is stored on different servers.
cf. StructureDefinition.url:
http://hl7.org/fhir/structuredefinition-definitions.html#StructureDefinition.url
Compare canonical url (author-assigned) vs. resource Id (usually server-assigned). Different copies of the same resource will have separate resource ids, however they will all share a common canonical url. The resource Id uniquely identifies a specific instance on a single server. The canonical url uniquely identifies a set of instances (clones) of the same resource (across many different servers).
Michel Rutten (Jul 31 2019 at 15:13):
References to such resources are always based on the canonical url, i.e. refers to any matching instance of this resource (within context), not a single specific instance on a specific server.
Alexander Kiel (Jul 31 2019 at 15:38):
@Michel Rutten Thanks. I have read all that stuff. But is _every_ .url data element, regardless of concrete resource, a canonical identifier? I just generate my database schema from structure definitions and like to know if I can mark such data elements as unique. Oh wait, as I write this, I discover that .url isn't unique, because only the combination of .url and .version would be unique.
Michel Rutten (Jul 31 2019 at 16:01):
StructureDefinition.version is an author-assigned value:
http://hl7.org/fhir/structuredefinition-definitions.html#StructureDefinition.version
FHIR dictates that if an author introduces breaking changes to a profile, then they should also change the canonical url. Because the new profile is no longer compatible with the previous version, they cannot share a common canonical url.
In practice, I don't expect production servers to contain multiple compatible versions of the same profile, as this would be ambiguous. Typically, in a production environment, you install a single, final, definitive version of each profile.
Alexander Kiel (Jul 31 2019 at 16:15):
@Michel Rutten I think we talk about different things. My question was whether I can detect that data elements like Library.url or also StructureDefinition.url actually hold URIs which should be globally unique. Say I like to implement a FHIR server which uses a relational database as storage and I have a table for all my Library resources. Can I mark the URL column as unique?
I discovered by myself, while asking, that I cannot because there can be two instances of say a Library resource with the same Library.url but different Library.version.
On the other hand, the combination of Library.url and Library.version should be unique within one FHIR server. Or do I interpret to much in this and it would be ok for a FHIR server to hold multiple instances of resources with the same .url and .version?
Michel Rutten (Jul 31 2019 at 16:37):
Usually, in a production scenario, canonical url's will be unique. This ensures that a client/server can resolve conformance resources uniquely, which is required for validation.
However there are (advanced) scenario's where this is not the case. For example Simplifier allows different users to upload profiles using the same canonical url; canonical url's are only unique within a user project. This requires a lot of additional complex logic, usually you don't have to deal with this c.q. reject this.
Michel Rutten (Jul 31 2019 at 16:38):
So Simplifier uses a compound database key of the form { ProjectId, CanonicalUrl }
Michel Rutten (Jul 31 2019 at 16:39):
However unless you are planning to implement a profile registry, you shouldn't have to worry about this.
Michel Rutten (Jul 31 2019 at 16:41):
So generally a FHIR db could contain duplicate canonical urls, but usually this will not the case (nor desired).
Lloyd McKenzie (Jul 31 2019 at 16:48):
Even within a project canonical URL is not expected to be unique. You can easily have multiple versions of the same profile or value set (distinguished by different .version elements) in the same project.
Alexander Kiel (Jul 31 2019 at 17:04):
I especially look at Library and Measure which also have .url and .version data elements and are not terminology resources. However Measure references Library through canonical type. In case that reference would be point to multiple libraries, I wouldn't know which one to use for my queries. But then, it's the same with Meta.profile. In case a server has multiple profiles with the same url/version pair, the validation should properly just fail.
So you would not check for duplicate url/version pairs at creation time? You would just fail in case you need to follow a canonical link?
Michel Rutten (Jul 31 2019 at 17:05):
Yes!
Michel Rutten (Jul 31 2019 at 17:08):
Because a single canonical url can be shared by many instances (clones) on different servers, per definition it is not globally unique. However canonical url's are expected to be unique within the limited scope of a (production) environment, for example within a single FHIR database. FHIR does not define how to implement the actual "resolving" of a canonical url to the target conformance resource. In a simple case, this only involves a simple lookup of the key (url) value in a local database or file system. However in advanced scenario's , the resolving process may also involve some contextual information, in addition to the canonical url; e.g. Simplifier also needs the ProjectId. Of course, this is implementation-specific.
Lloyd McKenzie (Jul 31 2019 at 17:10):
@Michel Rutten That's not true. Canonical URLs are NOT expected to be unique in a single production environment. Only the combination of url + version is expected to be unique.
Michel Rutten (Jul 31 2019 at 17:11):
Thanks @Lloyd McKenzie - I sidestepped versioning here, to not further confuse matters
Michel Rutten (Jul 31 2019 at 17:13):
So if you're building a very generic server, then you need to deal with all of this...
Alexander Kiel (Jul 31 2019 at 17:16):
Thank you both. I will move forward without any uniqueness checks upfront. I will just see that such canonical links (combination of uri and version) resolves to one single resource. It's right that the canonical resolution can be very divers.
Grahame Grieve (Jul 31 2019 at 22:02):
generally, operational servers would ensure that the combination of url+version is unique but the scope in which this happens is a business logic question, and there are use cases - general interop servers - where the business rule wouldn't apply
Michel Rutten (Aug 01 2019 at 08:56):
Concerning versioning, also see: http://hl7.org/fhir/resource.html#versions
There is no single best practice here; the correct choice depends on many factors outside the scope of this specification.
Last updated: Apr 12 2022 at 19:14 UTC
