Canadian FHIR Baseline Profiles - Governance Stream Meeting - June 12th, 2-3pm EST

No.

I am saying:

For 100% of our Canadian use cases, the CA baseline is usable as-is, but it does not provide all of the information required to fulfill the use cases.

I think you are looking at this from the wrong direction. CA-Core is not about driving what implementers need to do but rather what Canadian Implementation Guide authors need to do. The CA-Core needs to be the set of requirements that all Canadian Implementation Guides need to incorporate into their guides.

I would not expect any implementer to claim conformance to CA-Core but rather to claim conformance to specific Canadian Implementation Guides. "Our product is conformant with the BC Ministry of Health Provider Registry Implementation Guide and will allow you to add, update, and search for providers in BC." The fact that the BC MOH PR Guide is conformance with CA-Core means that this implementer is conformance with CA-Core as it applies to the BC MOH PR but that really isn't relevant.

Jean

Just to give some idea from Alberta perspective...

I think it would be highly unlikely that CA-Core would be usable anywhere without customization. There are just too many differences between jurisdictions - and many of these are rooted in legislation. Given that healthcare is the domain of the jurisdictions, it would take a fundamental change to get a mandate that all jurisdictions use the same rules. Good luck getting all the provinces to agree - I've seen the troubles of just trying this within Alberta when we had several regions, and even today while we have 1 "region" - there are still issues.

The only way to get CA-Core be useful would federal legislation to change this and force all jurisdictions to do the same way.

Thus an 80% goal is really the objective, and some regional customization will always be required.

Jean and Lloyd -- is this an accurate description of what you're advocating re: the Canadian FHIR baseline?

We expect that for 0% of our use cases, the CA baseline is usable as-is... but most of the time it gets us 80% of the way there and we always need customizations for the last 20%.

If yes... would it also be accurate to say that -- as you see it -- if a vendor were to be conformant to the CA baseline it would NOT give them the ability to deploy their COTS product in Canada, without first customizing it?

Lastly... Lloyd, when you say that "the objective isn't use-case driven" and that "the objective of the baseline is to define something that is easily achievable by as many systems as possible but is still 'useful'" -- whose objective is it, exactly, that we are referring to? Who decided that this was the objective... and how was it decided... and why is 'useful' in air-quotes?

Derek,

CA-Core should be a limited set of constraints on the FHIR base specification that govern cross-Canadian requirements. As an example, I would expect the only requirements in the Medication space is that we use specific Canadian terminology. No other requirements make sense in a cross-Canadian set of constraints.

I would not expect that an implementer would build an application purely against CA-Core. They should be building their software against jurisdiction or project-specific Implementation Guides. It should be our expectation that all Implementation Guides built in Canada should be using the CA-Core profiles, similar to how all US IGuides now require compliance to US-Core profiles.

If you want a national patient drug list standard, the answer is not to get those requirements into CA-Core, but rather to create a National Drug List Standard Guide that builds off of CA-Core and has buy-in from everyone across the nation. See HL7 v3 on how successful that was! We should definitely encourage harmonization across jurisdictional guides. We should also encourage jurisdictions to share and try to re-use existing guides. But I'm sure we all have enough experience to know that what seems like it should be easy to standardize across the country rarely is. I have experience with Drug systems in AB and SK and know the differences that exist there - both in the infrastructure and in the actual data requirements that each province exposes - and I am discovering similar differences in the Provider space between AB and BC.

Thanks,

Jean Duteau

The objective isn't use-case driven. The objective is to standardize the exposure of elements we can count on most existing systems supporting. It is *likely* that that set will satisfy quite a few cases. It's pretty much guaranteed to satisfy some. That common definition of "what's the minimum we can count on?" then becomes the 'baseline' from which we can define incremental requirements to support additional use-cases. The value proposition of establishing the baseline is threefold:
* it allows existing implementations to expose what they've already got in a FHIR-compliant manner that will then work with general purpose SMART-on-FHIR apps, CDS Hooks, and other solutions
* It allows other IGs to build on that baseline such that those IGs will be consistent in how they represent the 'common' stuff, reducing divergence (and the implementer and interoperability costs that come from that)
* It makes it easy to evaluate when defining new IGs that are founded on the baseline what the incremental 'ask' is for the implementation community

The objective of the baseline is to define something that is easily achievable by as many systems as possible but is still 'useful'. So, we don't create an allergy profile that doesn't include the allergen or a drug profile that doesn't include the drug. And, as much as we can get away with, we set expectations for using consistent terminologies (drawing on the standardization agreements we've already achieved).

The baseline itself does not (and never will) give us interoperability on everything. Coordinating on derived IGs still matters. It's absolutely possible for BC, ON and NB to define e-Referral IGs based on the baseline that are fully conformant with the baseline but still don't interoperate with each other. The solution there isn't "lets push e-referral requirements into the baseline", but instead "lets coordinate jurisdictional e-referral implementation guides so that they're consistent" or even "lets create a national e-referral IG that jurisdictions can implement".

Also note that just because things aren't must-support in the baseline, that doesn't mean that all new requirements are a wild west. The resource elements that are defined in FHIR core are still part of core. It may be that that the baseline for allergy doesn't include reaction onset date as "mustSupport". However, if a jurisdiction needs that in their own implementation, they're still expected to use AllergyIntolerance.reaction.onset. They can't go forth and make up an extension for it. Similarly, if there's a standard extension defined for something by HL7 or Infoway or IHE, then the expectation is you use that in preference to making up your own. (And if you have an issue with how the existing extension is defined, you take that up with the owner and community before contemplating defining your own.)

FHIR absolutely creates an environment where different implementations might solve the same problem differently *around the edges*, but the combination of registries, chat.fhir.org and forums like this as well as standardized tools for defining, publishing and comparing extension definitions, profiles and implementation guides significantly reduces the risk. In the end, we'll get interoperability in those spaces where the community comes together and works to define interoperability. FHIR doesn't make that magically happen. However, we shouldn't look at the baseline as our mechanism to drive all Canadian interoperability expectations. The baseline is just the lowest common denominator which we use as the foundation for building up our expectations in those domains where we commit to working together to achieve better interoperability.

Hi all -- I would like to garner discussion around a question that has been gnawing at me for a while now... and especially after the threaded discussion that followed the last Governance call. When we talk about our CA FHIR baseline... what do expect from it?

1. Do we expect that for 80% of our use cases, the FHIR CA baseline is usable as is... and 20% of the time we need to extend it?
2. Do we expect that for 0% of our use cases, the baseline is usable as is... but most of the time it gets us 80% of the way there and we always need customizations for the last 20%?

If it is #1 -- then we will have a "market" for COTS digital health products in Canada. Because, given our burden of disease in Canada, likely +98% of our care activities are related to the 80% of our use cases that represent our most common day to day workflows.

If it is #2, however, then what are the compelling advantages for a COTS product to be conformant to our baseline? Unless the customization is the same, everywhere, the Canadian market will continue to balkanized and silo'd across as many different approaches as exist for addressing that last 20% not covered by the baseline.

The role of our standards adoption effort is to get interoperability. That's what's important. That's what will positively impact health outcomes for Canadians. If we lower the bar so low that every digital health product gets to claim it is FHIR CA baseline-conformant, so what? Who cares? If they aren't interoperable with each other... then we tick the box for broad adoption of FHIR... but we didn't achieve our interoperability or population health mandates.

I sincerely hope that there's some aspect about FHIR that I don't understand but which directly addresses this issue... because this is really worrying me, lately. As Lorraine pointed out on today's Governance call... if we all profile and extend the baseline differently, for the same use cases, then we run the risk of finding we have the same non-interoperable outcome as we had when we did that under v3 (or v2... except this time we have a registry of z-segments).

Can others shed some light on this for me, please?
Thanks and warmest regards,
Derek