General Canadian FHIR Baseline Feedback

Maybe Ontario could use FHIR as a face-saving excuse to drop the version code and expiring health cards, altogether.

The is an issue with merging the version number. In Ontario the Health Card Expires every 5 years and when a new card is issued you get a new Version Code. There is a need to track the expiration date of the Health Number as well.

Why not just merge version code in with the base number IF you want to use the number for the PURPOSE of an identifier (e.g., 3344 342 342 HA).

The Ontario "version code" is a simple billing validation check and has nothing at all to do with identifying the client. The identifier is the numeric health card number; the version code is changed every time a new health card is issued (Ontario has expiry dates on its health cards, now).

So, including the version code in the identifier would break systems as the code changes many times over a client's lifetime.

Agree that the use of extensions should be minimized and that systems should be expected to support the core address elements. (If they want discrete components too, that's ok, but that shouldn't be part of pan-Canadian core and doesn't replace the need to send the base components.)

It's my hope that we'll end up with something that's a close mirror of the US Core and AU Core profiles with only small divergences for differences in terminology and perhaps one or two distinct extensions. (As an example, the US race and ethnicity extensions aren't appropriate/useful in the Canadian context.)

I think a reasonable expectation is that all servers in Canada should allow at least *read* access in a way that's conformant with these profiles. Allowing write access will be harder as additional business rules may exist that will require certain elements or extensions. However, we could make "write" access a nice-to-have.

A few thoughts:

1. eReferrals can be a really big application for base profiles, both for direct transmission and for SMART on FHIR methods.

2. Ontario version code seems to cause all manner of discussions and headaches. Why not just merge version code in with the base number IF you want to use the number for the PURPOSE of an identifier (e.g., 3344 342 342 HA). This way it stays a bit more pure to the concept of an identifier, and avoids the need for an extension. Conceptually, identifiers usually don't have multiple fields to them, so this approach would be aligned with the general concept of identifiers. However, if you want to use health card number for the purpose of coverage (i.e., we're not going to treat you without a HCN), then use (or also use) the Coverage resource (which sounds like it has space for version code as per the earlier comment).

3. For the purpose of eReferral, i'm not too worried about there not being many "mandatory" elements. Either the sending system has it or doesn't (which is where SMART on FHIR comes in).

4. Although extensions are supposed to be first class citizens, I would encourage using them in the base profile only when absolutely necessary. For example, in some profiles i've seen some Canada Post extensions used for address rather than the FHIR structures, while I believe the FHIR structures to be completely satisfactory for address. Also, the Ontario version code in patient identifier is annoying to deal with (as per item 2 above).

5. I haven't reviewed any proposed base profiles yet, but when i reviewed the Ontario patient registry profiles, it was clear that the FHIR profile was designed AROUND the nuanced (and sometimes quirky) structure of the Patient Registry itself. This is fine for the purpose of the Ontario Patient Registry itself on its own, but i would hope that the design philosophy around base profiles would be a bit more conceptually pure.

That's true when the PHN is sent for coverage purposes, but not when it's sent as a general purpose identifier - as is often the case. An extension on identifier (possibly one that's also used for credit card verification numbers) would be fully appropriate here.