FHIR Local URI naming conventions

Thanks for the input Lloyd,

Looking at your first point that URIs should never change, I see 2 possible issues.
- How long will infoway persist? Having all URIs as "fhir.infoway-inforoute.ca/..." will be problematic if infoway is shut down. What happens when there is no more Infoway?

- How are errors handled? For example, the current "Alberta, Canada Health Service Delivery Site Identifier" is wrong. The description and value provided for it are those associated with a deprecated concept. How do we go about fixing this? And is the process any different for a URI in Authoring status vs any other status? With the OID, we deprecated the existing one and created 2 replacements that each have their own set of values. So how do we get a new "ca-ab-health-site-id" (to follow Infoway naming convention) when we have 2 distinct identifiers for this value?

The second point is the same principle as OIDs, one namespace = 1 URI.

The third point - generally, any concept for which an URI is created should also have an OID defined to facilitate interactions with non-FHIR applications. Of course, if v3 applications ar enot prevalent in a jurisdiction, this is less of an issue.

Fourth point - descripes the ideal situation. Just doing a random check of current entries in Canada URI registry, none of them resolved. So while this would be nice to have, I don't think it is required, nor is it likely to be true in most cases. I couldn't imagine a lot of namingSystem value sets being publicly posted (Driver licenses numbers anyone?)

A further issue for the infoway registry is the scoping of URIs. Had infoway gone with a format like "fhir.infoway-inforoute.ca/<jurisdiction>/NamingSystem/...", then we would be at a glance be able to tell if a URI was national or jurisdictional in scope. Basing them all on 'fhir.infoway-inforoute.ca/NamingSystem/..." there is no way to distiguish without going to the registry and reading the details.

Can we have the registry partitioned into jurisdictions? Or is there a simplifier constraint artificially driving this?

Also note that there are only 3 Alberta concepts that have even been presented as URIs so far. And one of those is wrong.

The criteria for URIs is, in order of importance:
1. Be stable. Once established, they should not change - ever. Regardless of departmental organizations, organization mergers, organization naming changes, etc. So long as the identifier namespace exists, the URI for it should remain the same. If the URI ever changes, it will impose costs in the hundreds of thousands of dollars or even millions on the implementer community to accomodate the change - and will create risks of non-matching records that could result in serious patient care impacts.

2. Represent the *namespace* of the identifier. I.e. the URI is what is combined with the identifier to establish uniqueness. If three different license types are all drawn from the same identifier pool (such that all identifiers across the three types are unique), that should be *one* URI, not 3. The URI *may* be enough to determine license type/credential type, but that's not guaranteed.

3. Be human-friendly. Developers looking at the URI or seeing it in instances that they're trying to debug should understand what it is and should not confuse it as something representing a similar but distinct namespace. If at all possible, avoid using OIDs which are definitively NOT human-friendly.

4. Should resolve. Developers should be able to take the URL, plop it into a browser and have it resolve to a page that describes the nature of the identifier and, if appropriate, look up specific identifier values

The rationale behind the current Infoway-routed identifier scheme is that we can be relatively confident about #4. The URL willl resolve to a NamingSystem instance in the registry and will render the NamingSystem description. The NamingSystem description can then be updated to point to the relevant provincial or licensing board websites that contain information about the identifier. And the description can be updated to point to new links when jurisdictions and licensing bodies inevitably change website designs, department names, whatever that break the old links.

Having Alberta root their identifiers in their own space only makes sense:
- for identifiers that haven't already been issued URLs that are in use (which is quite a few at this point)
- if they can ensure that the URLs will resolve now and into the future.
- if they're going to put their identifiers in the central Infoway registry for discovery anyhow

Overall, I see little benefit in having the root for the URL be an Alberta-specific website. The description of the NamingSystem can obviously be updated to point to whatever Alberta government or other organization website is appropriate.

Hi all,

At present we don't seem to have much guidance on best practices for naming jurisdictional URIs.

As Alberta is looking to define some URIs we are thining about this issue.

We are currently proposing using the following patterns:
Root - use "fhir.alberta.ca"
This would be adjusted by jurisdiction as appropriate.

Then for URI types, we would have "NamingSystem", "CodeSystem", "ValueSet" and possibly others.
The URI type of "Extension" for the URIs of Resource Extensions - but this could easily go under another type of "Structural". But I would tend to expect structural items to be part of the standard specification, so not sure.

Most code systems I would also expect to be defined at a FHIR wide level (for example the language code set), while specific codes supported in a jurisdiction would fall under the value sets.

Putting these names together we get:
fhir.alberta.ca/NamingSystem/ca-ab-XXX
fhir.alberta.ca/ValueSet/ca-ab-XXX

or in general:
fhir.<jurisdiction>.ca/<URI type>/ca-<yy>-XXX
where yy is the 2 letter abbreviation for the jurisdiction identified in <jurisdiction> and XXX is the name of the URI (following Infoway name guidelines).

Does this make sense? Any other ideas?