FHIR Local URI naming conventions

For non-public identifiers, it shouldn't much matter as only the "creating" system should need to issue them and other systems would be free to treat them generically unless there's special rules associated with them. There will be thousands of these with a wide variety of scopes (every system will have their own ids for MRNs, lab order numbers, prescription numbers, employee numbers, etc.). I think it's unlikely we can drive consistency across these. Web resolution would be nice, but it's certainly not expected.

At Ontario Health Digital Services (formerly eHealth Ontario), we have assigned MRNs at the jurisdictional level (ehealthontario.on.ca/fhir/NamingSystem/...). Things like provincial health card numbers that have a possibility of use across jurisdictions have been registered with Infoway.

Due to the preference for URIs to be resolvable, I would caution against mandating a "fhir.<jurisdiction>.ca" nomenclature -- we have no way to host a resolvable endpoint "fhir.ontario.ca", and other jurisdictions may have similar challenges. Many jurisdictional electronic health authorities may be separate from the provincial government body. For those are the same organization, there's also no guarantee they can expose a domain space that way.

Using the "ca-ab" ("ca-on" in our case) prefix is probably on a case-by-case basis. Don't think it's always necessary. We're using ca-on prefixes on our profile names at the moment, chiefly to align them with the respective project uri that they belong to on Simplifier.

The pMrn would be in the Local Public identifiers group, and the patient would likely never know its value. These (as well as private identifiers and local code systems) are the ones I would not want to have on Canada URI registry default root.

In the discussion 2(or was it more?0 years ago, I raised the same issue and it was not resolved then...

So... what is the suggested route for the concepts not falling under the common public identifiers umbrella? How should we do these so that there is consistency for them across the country? (To help reduce the issues for implementers)

Best to get this right before we start creating a bunch of URIs...

And thanks for your help and feedback

All identifiers have the potential for appearing anywhere - because all data could be shared across jurisdictions (and we're not going to strip identifiers as it's shared). There's no intrinsic 'usage' constraints on identifiers. It may be that certain identifiers are only issued to current residents while others are also issued to non-residents, but *all* of those identifiers could manifest in any system in the country. E.g. I could show up in Ontario and give them my Alberta provincial health number.

We had this discussion about how best to manage identifier systems 2 years ago with representation from most jurisdictions and came to the conclusion that for "common public identifiers" (those that could be captured in a variety of different systems), we would consolidate on a single registry and a single naming approach. That ensured greater consistency for implementers, one place to look and significantly reduced the risk of URL changes. It also minimized the amount of effort and infrastructure needed by the jurisdictions (both now and into the future). It's a bit late to start revisiting the discussion.

If the pmrn is an identifier that the patient 'knows', then it should be handled using the Infoway root approach. If the pmrn is an internal registry identifier that can only be learned by contacting the registry, then it's fine for that to be an alberta-rooted URL

Maybe theres something I'm missing here. What would be the issue with having a separate endpoint for each jurisdiction?

As I understand URIs, they work like OIDs to uniquely identify a domain of values, and that no processing happens with the specific URI other than to use it to determine the type of identifier supplied. Trying to wrap my head around this because intuitively, I don't see a problem for different endpoints - and you do so I have to assume I'm missing something...

Without having this, how can you tell which of these is national in scope (meaning intended for use both in the juisdiction and outside of it) and which is jurisdictional?

fhir.infoway-inforoute.ca/NamingSystem/ca-ab-patient-healthcare-id
vs
fhir.infoway-inforoute.ca/NamingSystem/ca-ab-patient-healthcare-id-pmrn

What if they were:

fhir.infoway-inforoute.ca/NamingSystem/ca-ab-patient-healthcare-id
vs
fhir.alberta.ca/NamingSystem/ca-ab-patient-healthcare-id-pmrn
or
fhir.infoway-inforoute.ca/alberta/NamingSystem/ca-ab-patient-healthcare-id-pmrn

The pMrn would never be used outside Alberta, so it would just clutter up the URI registry (along with the hundreds of others from each jurisdiction) in a common namespace. For reference, Alberta currently has almost 400 jurisdictionally registered OIDs (and yes, not all of them would exist using current OID useage - this is for OIDs created since v3 came out, and we learned a lot along the way )

If Infoway ceases to exist, I would hope that whatever body takes over responsibility for the HL7 Canada affiliate would take over responsibility for the domain name and set up redirects. If not, then we lose resolution ability. However, ability to resolve is only priority #4. #1 is "don't change the URL", so I'd expect the URL to remain the same even 20 years after Infoway has ceased to exist and few people even remember what it was.

Infoway does have the ability to request corrections to the content in their registry and the process for doing that isn't too onerous. If there are two different concepts, then the identifier needs to be distinct. The Infoway URL convention is a guideline. If it presumes there's only one but you have two, then you'll need to decide if one of them should follow the Infoway URL convention and the other should be something else or if both should be something else.

I'm not saying an OID can't exist, merely that it shouldn't appear in FHIR instances - when converting between v3 or CDA (or sometimes v2) and FHIR, if the source has an OID, that should be mapped to a human-readable URI for use in FHIR.

Absolutely agree that #4 isn't mandatory. It's just desirable.

The jursidiction is part of the ID in the Infoway scheme, so you can still figure out the jurisdiction by looking at the URL. (Software should never be trying to parse the URL - you should always be resolving it or looking it up in a registry and using the metadata. The content in the URL string is for human readability only.) Partitioning the Infoway into registries would mean you'd need a separate FHIR endpoint for every jurisdiction. Moving where the jurisdiction appears in the URL isn't of a big enough benefit to justify that.