Canadian FHIR Baseline Profiles - Governance Stream Meeting - May 29th, 2-3pm EST

lmckenzie wrote: My primary concern is that the profiles reflect what systems can currently do - not what we might wish they could do.

That provides the argument for not including in the early versions of "core" requirements elements that we know to be actually core to an interoperable electronic health record infrastructure. It still makes sense to me to document that we were aware of the shortcomings from the outset.

I agree that it should be easy for vendors and implementers to add a FHIR interface if it only requires exposing what is already available through other interfaces in a RESTful way, but I am not convinced of the benefit of yet another z-segment specification using the latest technologies.

Is it possible to compromise by saying that a compliant system has to understand everything "core" that is thrown at it even if it has no use for some of the elements? (That is, if the analysis exposes a truly core element across the Canadian tested use cases that a vendor cannot support, the vendor should still be able to send and receive records using FHIR.) I might be repeating points that have already been hashed out in more detail, elsewhere, I acknowledge, but it seems to be the crux of this discussion.

My primary concern is that the profiles reflect what systems can currently do - not what we might wish they could do. If we find a requirement that's common across multiple use-cases, but most systems don't support that requirement, then it should NOT end up in the first release of the Canadian Baseline. If the purpose of the use-case analysis is to make sure we haven't missed any commonly supported elements, that's fine, but the driver needs to remain the data capabilities of existing systems, not the desires of the stakeholders. Enhancement of implementer capabilities comes later once you've actually got most systems migrating to having a FHIR interface at all. (And, in general, enhancement of implementer capabilities will be driven by IGs and only reflected in baseline when the underlying reality of "what's commonly supported?" has shifted.)

The bar the baseline sets needs to be "expose what you have using FHIR". In general, none of the systems converting to support the baseline interface should have to make a single change to their internal databases because we're not expecting them to capture any data elements they're not already capable of capturing, nor expecting any elements to be present that aren't already always present.

I expect the output of this exercise to be documentation illustrating that the "core" has elements that are valuable to all the use cases. I expect that each use case would require some additional elements to fulfil its needs; if any of those additional elements are common to most of the use cases, that would argue for their inclusion in the "core" specification.

If we were to find an element in the "core" that none of the use cases uses, that might indicate that it is not actually core to anyone's requirements. At this point in the game, I would be surprised by a revelation like that, but I would want to know about it before arguing that every vendor should seriously consider our version of the "core" for inclusion in its software.

Hey all.

Lloyd, I don't think we are suggesting we make use-case specific baseline profiles. I think what is being suggested is that we apply the baseline to use cases to common use cases that we have to make sure that we have the coverage that we need, and are indeed fit-for-purpose in the Canadian context.

While many assertions have been made that FHIR has been designed to address 80% of the potential "typical" uses, I am pretty sure that assertion has not been actually tested authoritatively yet. Yes, there is a LOT going on with FHIR, but I am skeptical that anybody has cataloged the coverage. In the Canadian context, it is (as Derek has stated) a "most Canadian thing to do" to make that assessment (as much as we possibly can) before asserting to the Canadian interoperability community that the Canadian baseline specs are "good".

Nothing incompatible here between your goals as a primary proponent of FHIR and the goals of the Canadian HL7 community for working interoperability.

Ron P.

All of the problems with US Core to date have been situations where use-cases were presumed - and as a result, the baseline doesn't work as a baseline. If we push the baseline to become something it's not intended to be, then we risk it not working for its *primary* purpose. Our primary purpose with this IG is to provide a base for CDS Hooks, SMART on FHIR and for other Canadian IGs. Those other IGs can go wild and crazy with any use-cases they like. But if we embed use-case-specific requirements that *should* be in other IGs here, we're going to create a problem.

FHIR design is different from the way we're used to creating specs. We're used to doing everything on a use-case specific basis. However, the FHIR core spec (and jurisdictional baseline specs) are specifically intended to be agnostic to use-cases. More specifically, the baselines are tuned to specific countries, human-specific (rather than veterinary) and to identified patient scenarios focusing on the resources commonly supported (and needed) for clinical care.

The other thing we've learned with FHIR is that it generally works best to start small and grow over time. FHIR methodology is the *opposite* of v3's "design by constraint" methodology. The base specs are the common things that everyone supports. Downstream specs add new stuff. So we need to wear a different engineering hat when working with FHIR specifications than the one we might be used to wearing.

Don't be nervous, Lloyd. I think you should think of this as a positive... rather than as a negative.

Our FHIR CA baseline doesn't need to be useless to be use-case independent. I'm optimistic; I actually think that the engineering that has been done to date is excellent and it is likely to be very capable of handling the use cases defined in the Life of the Lamberts. These aren't weird or idiosyncratic use cases... they are the bread-and-butter workflows being executed in our Canadian healthcare system... all day, every day, everywhere. These user stories epitomize the 80/20 rule. (And for OECD countries, the Life of the Lamberts represents their bread-and-butter workflows, too).

If we do find there are gaps... then we'll decide what to do about them (including doing nothing... if that ends up being the consensus position). But to be nervous about even finding out... well... now that makes me nervous. I definitely want to know! I actually feel it would be professionally embarrassing to not have evaluated whether the baseline were fit-for-purpose before inviting non-engineer stakeholders to start to collaborate with us.

Also... I don't at all agree that having our baseline able to do useful things will be a barrier to adoption. I think having it not able to do useful things will be a barrier to adoption. Or that's been my implementation experience, anyway.