Prep Work for Friday's Canadian FHIR Baseline Profiling Workstream Meeting (2-3pm EST)

dritz wrote: Shamil -- I'm not certain I follow all the implications of your example. Are you advocating that our current extensions defined by the Solution Architecture WG be rolled into the Canadian Baseline? If yes... then it seems to support the notion that our <strong>baseline needs to be sufficiently defined to ensure interoperability</strong>. Re: slices... are you thinking that these could become configurations on vendors' standard products that point to where codelists are to be found (e.g. for PHNs, as you suggest)? I'm sorry if I'm misunderstanding... and if I am, please can you clarify?

Baseline needs to be sufficiently defined to ensure interoperability - that's exactly why we need Canadian Core at the first place. Vendors can do and they actually have done it already (I'm thinking about our BC implementations) implementing solutions without following any baseline at all.

I cannot tell it better than Lloyd - The possibility of multiple extensions serving the same purpose is more of a concern - which is one of the reasons why forums like this and chat.fhir.org are so important to drive alignment during the design stage. Having a feedback process for specs during the creation process where misalignment can be addressed is also appropriate.

From our side, Solution Architecture WG put enough effort discussing and aligning URI and extensions. Please reuse that outcome.

Lloyd -- this is very good news. I was not aware that we yet had evidence that the US-Core was successfully achieving health system wide interoperability in that market. I have been worrying that our strategy of following this US approach was as-yet-unproven. To hear that it has worked is very comforting.

What's happening in the U.S. is that implementers largely *are* targeting their interfaces to that 'core' set of functionality. Other IGs then build on that to reflect the needs of specific implementation spaces (genomics, Da Vinci work, etc.) Adoption of the IGs by vendors is influenced both by the market/business drivers as well as how close the alignment is to the US Core spec.

Defining extensions doesn't mean that anyone will implement them. There has to be a convincing reason for the software vendor to bother. It's no different, really, than support for a core element. The possibility of multiple extensions serving the same purpose is more of a concern - which is one of the reasons why forums like this and chat.fhir.org are so important to drive alignment during the design stage. Having a feedback process for specs during the creation process where misalignment can be addressed is also appropriate.

FHIR has tossed out the "design by constraint" process for a few reasons:
- It's really hard to create a spec that covers "everything" - it takes a long time and the specs are inevitably complex and hard to implement - and of course no one's expected to actually implement 'everything', so everyone picks different subsets.
- There's inevitably new stuff that ends up coming up.

Every EHR system *WILL* have variation in what it exposes. And that's ok. Each EHR will adopt features at different speed, have different priorities, will expose new experimental capabilities, etc. So long as there's a common set of behavior that everyone can count on, you can choose whether to take advantage of EHR-specific capabilities or not. It's much the same as coding for browsers. There's a common set of HTML, Javascript, etc. that all browsers implement pretty consistently. There are also variations. If you want to fine-tune your product for Netscape or Edge (or a specific version there-of), you can. In much the same way, you could tune to a particular version of Epic or Cerner. But if you write your app to target the lowest common denominator, you can be confident of working with any EHR (or at least any EHR that agrees to adopt the common core). The *value* of US Core (and hopefully CA Core) is that there's a commitment to implement that common subset - and the commitment is being met.

dritz wrote: Jean -- I'm thinking more of commercial software product developers than I am of one-off solution implementers. Do your comments equally apply to this group (e.g. large EMR product companies like Telus, Epic or Cerner)? You suggest that vendors would start with the Canadian Baseline as the starting point for their implementation guides. Does this imply that every commercial product would have its own (potentially idiosyncratic) FHIR IG? It seems to me that <strong>care delivery network-wide <em>interoperability</em></strong> will rely on (and be limited to) the degree of <strong>overlap</strong> between all of the participating stakeholders' IGs. That would seem to make even more important the degree of coverage of the Canadian Baseline. I'm very sorry if I'm missing something obvious to everyone but me.

If you go look at the Implementation Guides that are being balloted at the HL7 International level, you will see the starting point that I think software product developers should be basing their products on (the Da Vinci guides are something I'm currently working on that are appropriate). In Canada, PrescribeIT is an early example of this. If your product is involved in a specific interoperability space, then you are going to be basing your product on an Implementation Guide that targets that space. If there isn't one for that space, then you will have to create one and circulate it to the other vendors/implementers that are operating in your space to get consensus and thus interoperability.

The Canadian Baseline is not one of those space-specific Guides, but rather a set of guiding principles for all Guides that are operating in the Canadian market space. Just like most (if not all?) Guides in the US base themselves on US-Core, I would hope and expect all Guides in Canada to base themselves on the Canada-Core. Because the Canada-Core is not space-specific, that means that we have to be careful to not over-constrain it. It provides the baseline for all spaces and thus has to be useable in all spaces.

In the US, Project Argonaut's Guides (argonautwiki.hl7.org/index.php?title=Main_Page) have been highly influential on the American EHR market. That Guide has a set of profiles and a set of business operations that arose from a set of decisions that the Project made around the consuming and sharing of Core Data. That Guide used US-Core as its starting point and then went further to provide an interoperable base for Core Data.

I think that it would be a good thing, after or even in parallel to the work on Canada-Core, if vendors in Canada wanted a similar initiative to Project Argonaut, that we developed such a Guide and that would then give the network-wide interoperability that you are searching for.

Jean -- I'm thinking more of commercial software product developers than I am of one-off solution implementers. Do your comments equally apply to this group (e.g. large EMR product companies like Telus, Epic or Cerner)? You suggest that vendors would start with the Canadian Baseline as the starting point for their implementation guides. Does this imply that every commercial product would have its own (potentially idiosyncratic) FHIR IG? It seems to me that care delivery network-wide interoperability will rely on (and be limited to) the degree of overlap between all of the participating stakeholders' IGs. That would seem to make even more important the degree of coverage of the Canadian Baseline. I'm very sorry if I'm missing something obvious to everyone but me.

Shamil -- I'm not certain I follow all the implications of your example. Are you advocating that our current extensions defined by the Solution Architecture WG be rolled into the Canadian Baseline? If yes... then it seems to support the notion that our baseline needs to be sufficiently defined to ensure interoperability. Re: slices... are you thinking that these could become configurations on vendors' standard products that point to where codelists are to be found (e.g. for PHNs, as you suggest)? I'm sorry if I'm misunderstanding... and if I am, please can you clarify?

As a suggestion: there is a number of extensions already defined by the Solution Architecture WG - simplifier.net/canadianbaseline/~resources?category=Extension - let's incorporate those into the Patient resource.

Then slice Patient.identifier and point out to - simplifier.net/canadianuriregistry/~resources?category=NamingSystem - for provincial PHNs.