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

I think Jean nailed it there - the best way to get close to what Llyod is suggesting (which is really the ultimate goal) is to start with the terminology to use. I think national definitions would go a long way towards helping cross-jurisdictional implementations.

Alberta is presently working on eReferral through FHIR, and we are starting with the Ontario spec. Some of the most significant issues are the various code sets in use on a number of topics. Even something as simple as the referral status...
Other issues result from the scope of the Ontario project as compared to where we are trying to go. Even so, it looks like its 80%+ compatible so far.

The challenge is we have so many applications using the current workflow that we couldn't just witch to match Ontario's (and vise versa I'm sure).

But once we get done, looking at the similarities between the two would give a good idea of where the CA-Core version of these profiles should be.

Randy -- I take your comments to heart. They are an accurate and faithful reflection of where we are today.
But our status quo isn't where we WANT to be, is it? When AHS talks about trying to achieve interoperability... what exactly does it mean by that? That a digital health solution will need to be stick-built to work in Alberta? And that another one will be stick-built to work in Saskatchewan... cuz that care delivery network is so fundamentally different from Alberta's? (I used to live in Lloydminster... how screwed up is it going to be for those guys?!?)

I'm motivated by the opportunity we have to do things better. We can't possibly have, as our burning inspiration, that we're going to spend person-years of effort and millions of dollars to be just as dysfunctional as we were before... but on FHIR, this time. That'd be heartbreaking...

I expect you'll see that solutions like Apple will expect conformance to a Canadian core. They'll have as much interest in accommodating jurisdictional variations here as they do from state to state (or hospital to hospital) in the U.S. Similarly, the app market will typically focus on the CA Core capabilities. Few app developers will have the resources to pursue customizations for specific jurisdictions - and most of the variations by jurisdictions will be around administrative stuff that few apps care about anyhow.

EHRs will build single interfaces that meet the requirements of the jurisdictions they care to implement in. If *any* jurisdictions develop a certification process, then so long as the jurisdiction profiles comply with CA core, they'll intrinsically certify the EHR to CA core too. (And if they're *not* conformant to CA core, then we really haven't learned anything )

Not necessarily. The CA baseline will likely coincidentally be sufficient for at least some use-cases. The bare minimum elements that are needed/likely to be supported regardless of use-case will be there. (E.g. patient, type, value, time for Observation.) Whether it gets us 100% of the way or 80% or 50% or 15% will depend on the use-case.

An implementer exposing their data in a way that complies with CA-Core would, at minimum, have to translate codes to any mandated terminologies and expose any mustSupport elements they have data for. However, they can (and in most cases will) expose whatever other core data elements they happen to support. They could also choose to expose other elements covered by standard extensions. That represents a huge leap - because clients would then have at minimum *read* access to 'most' of the data in those applications. They can and should deploy their FHIR interface without worrying about any specific use-cases. It would mean that SMART, CDS-hooks and other apps would then have access to the data. And it would be a foundation for them to negotiate about enhancements to the interface to meet specific project needs.

The objective is the common objective for the various jurisdictional 'core' IGs - US, AU, and others. It comes from the HL7 community. We're inheriting it from others who have gone before. It fits with the base FHIR methodology of the central specifications *not* being use-case specific - and other IGs being created to solve specific use-cases.

Having use-case independent access to data is one of the base principles behind RESTful interfaces. You're not retrieving data "for a use case", you're just "retrieving what data exists". Even when you start supporting IGs, the target is that you still only expose one endpoint for a resource - that exposes the union of whatever each IG happens to need (and that you happen to support). Certainly the objective is that no implementation should end up exposing different interfaces to different jurisdictions. You simply support the combination of whatever jurisdictions you want to comply with. If other use-cases come along that are able to use that same set of data, they can take advantage of it right away. No need for negotiation/specification.

I was on a ONC presentation at FHIR Dev Days and they clarified that the rules around US Core only applied to vendors who voluntarily submitted their products for certification. To that end, they do have payments for certified vendors and there is a push to only purchase certified products, so there is a desire to certify. Because of that certification and the desire to set a minimum bar for behaviour as well as data elements, US-Core has more than we do in CA-Core.

Unless the jurisdictions are willing to get together and mandate a national requirement like the US ONC has done, I don't see how CA-Core can be anything than the lowest common denominator of data elements across the country. I can certainly see Alberta (or any other jurisdiction) coming out with an AB-Core that would be more comprehensive and have the force of certification/law that US-Core does. Given that healthcare is a provincial matter, that would be the equivalent to the US ONC.

Thus CA-Core seems like it should start with terminology requirements - use Canadian Clinical Drug Database for medicinal product codes, use province health care identifiers for patient identifiers, etc. And then as jurisdictions publish their Implementation Guides, we can mine those for additional cross-jurisdictional requirements.

Jean

+1 to Randy's comments.