Solution Architecture work stream

The expectation is that registering of common public identifiers would be managed by Infoway in consultation with the jurisdictions in the same manner that OIDs have been managed. Content that is only relevant within a jurisdiction can and should still be managed within the jurisdiction - and almost certainly will use the same process as we have with OIDs.

The only reason to go with bilingual labels in the URIs is if some jurisdictions feel they have to for policy reasons. Keeping the URIs simple is definitely desirable.

The existing ehealthOntario URIs are temporary ones the project used while waiting for official ones to be assigned.

We *could* take an approach where each jursidiction had its own base URL for naming systems managed within that jurisdiction. The challenge there is that not all jurisdictions will necessarily have the capacity to set up a queriable FHIR server to expose their naming systems and to maintain that going forward. Sticking everything in a common Canadian registry is likely to be more practical.

As for camel-case vs. dash-separated, camel-case requires case sensitivity, though we really should have that anyhow. I don't feel terribly strongly one way or the other.

Canada is in the descriptions for the same reason we place it in the OID descriptions - these URIs may be used by people outside of Canada and it makes them easier to find - though given that NamingSystem has an explicit "jurisdiction" element, that may be less essential than it was with OIDs in the OID registry.

The types of physicians won't necessarily be distinguished by the system - the system corresponds to a unique set of identifiers. If identifiers for different types of physicians all come from a single pool, then it's a single system. (The type of physician would be communicated by a code, not by the identifier system.) That said, if the licenses are being assigned by different bodies, they'll definitely be different naming systems. Our starting point will be the initial OIDs that are already registered.

Hi,
Just joining in the conversation here to give an Alberta perspective.

We have a significant amount of OIDs actively in use in our systems, and it would be rather cumbersome to have to maintain both the OID and some new URI (plus mapping between them) to keep our current V3 systems able to communicate with FHIR based systems.

Also, i would be very concerned of having anyone able to "register" AB URIs in the Canada URI registry - this should be allowed only by the designated Alberta representatives, or even better only in the Alberta Registry. We currently have a provincial OID registry, and would expect to have the same for FHIR URIs. Realistically, we could add URIs to our OID registry to allow the mapping to be maintained there.

Looking at the URI Strategy doc, I would recommend against using bilingual identifiers - this simply makes them unnecessarily longer, and substantially more error prone. Those not fluent in one of the two languages will not be able to spot typos in that language, and isn't this the reason for using URI instead of OIDs?

I would also suggest that using camel case still allows them to be readable, yet saves a bit on the limited space available - abUniqueLifetimeIdentifier is preferred over ab-unique-lifetime-identifier.

Looking at the spreadsheet I see some proposed ab codes. First question - why would any of them use an ehealthontario root? They are Alberta identifiers, not Ontarios...

ehealthontario.ca/API/FHIR/NamingSystem/ca-ab-patient-hcn - defined as "Alberta, Canada Personal health Number". This should be defined using an Alberta based root (similarly for all other Alberta identifiers), and the definition should be "Alberta Uniform Lifetime Identifier" - why Canada in the description? And in Alberta, a person could have a ULI, but not have active coverage - thus it would not be an PHN (an example is someone from out of country that seeks medical care). Using the term PHN will lead to confusion (it has in the past...) as it implies the person has provincial health care coverage.

ehealthontario.ca/API/FHIR/NamingSystem/ca-ab-license-physician - I don't think this is descriptive enough. We have multiple types of physicians and use "MD" to represent CPSA licensed physicians (a second example is Podiatric Physicians from CPPA).

ehealthontario.ca/API/FHIR/NamingSystem/ca-ab-license-nurse - we have 3 different types of nurses licensed... LPN, RN, and RPN (3 different colleges)

Randy Nonay, Alberta Health

Hello Everyone,

Below I've copied the initial list of the proposed URI guidelines. These are listed on the last tab of our URIs Google Sheet.

I will appreciate your feedback and suggestions.

1. Base url for common public identifiers: fhir.infoway-inforoute.ca/registry/NamingSystem
2. Ids should be all all-lower-case-hyphen-separated
3. Ids should avoid abbreviations
4. Ids that are scoped by province/territory should be prefixed with the province/territory code - e.g. "ab-some-identifier"
5. Ids that are national in scope should be prefixed with "ca-" - e.g. "ca-some-identifier"
6. Words that make up the identifier should start from the general type and then get more specific. E.g. "on-license-driver" rather than "on-driver-license"
6a. Words should be consistent across identifiers when possible. I.e. Try to use "patient-health-number" if everyone else is using "patient-health-number"
7. Words should be expressed in the primary language of the province/territory that manages them
8. Words should not use accented characters

Thanks you Lloyd for compiling this list and for very helpful reorganization of the NamingSystem tab.

Hello Everyone, a few updates from our last two meetings:

1. We will be having our meetings weekly, every Friday, for the next couple of months. I've updated the meeting details on Infocentral. Please download the updated meeting invite to ensure your calendar is up to date.
2. We discussed two formats of managing URIs in the Google Sheet aligned to the NamingSystem resource and made a decision to stick with the flat format where multiple UniqueIds reside on the same row versus the normalized format where rows repeat for each UniqueId
3. We would like to get an agreement on the naming convention for Canadian URIs. My proposal is to use fully spelled out words separated by hyphens (e.g. patient-health-card-number rather than patient-hcn. Also, it would be helpful if every Canadian URI is lower case and starts with a jurisdiction (here I think codification would be fine to save a few bytes), e.g. ca-on-patient-health-card-number. We also have a jurisdiction element on the NamingSystem resource, which is bound to a Jurisdiction ValueSet (Extensible). This ValueSet includes a code for Canada (CA), but doesn't include codes for Canadian jurisdictions. We had submitted a request to add a CodeSystem for Canadian Jurisdictions defined by Canada Post, but will need to follow up on this
4. NamingSystem.type element is bond to Identifier Type Codes ValueSet (Extensible), but many existing codes are poor matches to our URIs and we will need to extend this ValueSet (potentially, submit to HL7 for inclusion in FHIR) to support all the required type of URI.
5. We would need to investigate how we can/should use namingSystem.useContext element

Please let me know if I missed anything.

See you all on Friday, June 2nd at 2:00 pm.

My apologies for not posting about the decision to cancel the meeting last Friday, May 19, which we made at a meeting on May 12.

Please note that the meeting this week is on. See you all on Friday, May 26 at 2 pm.

Igor

Hello Everyone,

Based on the Doddle pool, we have 6 confirmed attendees for the meeting today.

I look forward to talking to you at 2:00 pm this afternoon.

Regards,
Igor