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

I'm a bit nervous about the direction of this conversation. The baseline profiles are intended to be (and MUST be) use-case independent. They will be the common foundation for a wide variety of use-case-specific profiles in use-case-specific IGs. They will also serve as the foundation for query capabilities by SMART apps, CDS Hook services and other systems for a huge variety of purposes.

Our objective is to establish a lowest common denominator that we believe (based on implementer consultation and - hopefully soon - connectathon testing) is achievable by most, if not all, clinical data repositories in Canada. We're not trying to solve any particular problem and we're not trying to raise the bar beyond asking for exposing supported data via a FHIR RESTful API.

If we were to review a "Life of the Lamberts's" use-case and determine that the baseline profiles exclude a needed element, that wouldn't necessarily tell us something useful. If it's not something we would expect most clinical data repositories to currently support, then it shouldn't be in the baseline profiles. Instead it would be something that could be negotiated as part of a use-case-specific IG that would build on the baseline profiles (as a baseline :>).

It will be challenging enough to move the Canadian EHR, HIS and other communities to support FHIR RESTful interfaces at all. Every 'nice-to-have' element we add to the spec because it will help with use-case X, Y or Z but that is not yet widely implemented will act as a barrier to adoption.

The value of getting systems to support the new baseline is not that we'll suddenly see oodles more data than we did in v2, v3 or CDA. It's entirely likely we'll see less. The benefit is that that data we *do* get will be accessible over a generic API - one that runs the same here in Canada as it does in the U.S, Australia and elsewhere and that that API is *not* use-case specific - meaning that you can grab medication data or allergy data or care plan data or whatever for whatever purpose you need it and in combination with any other combination of data without needing to wait months (or more typically years) for a specific tuned interface to be rolled out jurisdiction by jurisdiction - often with each one being just a wee bit different.

The baseline should represent the data that app developers can count on being there. Standardizing the other stuff comes later. (And should, as much as possible, also be informed by what's happening internationally and in other jurisdictions.)

I thought that the Life of the Lamberts was a well-thought-out set of use cases then, and I still do.

So, I agree that the collection would be a good starting point from which to prepare uses cases to vet FHIR CA-core.

Hi all -- I'm very sorry to have missed Friday's call. Sadly... my calendar was very much not my friend on Friday ...

I'm especially sorry to have missed the call because I had committed to preparing a work item (that our IHE colleagues could perhaps help progress) regarding "use case" vetting of our FHIR CA-core draft work products. I did make some progress on this, including having a few calls with Kristina Garrels who will, I hope, be assisting in some of this work.

My suggestion for vetting our FHIR CA-core draft is to leverage some of the early Infoway work to prepare a cohesive set of use-case stories: The Life of the Lamberts. A consolidated set of these stories if found, here: Consolidated "Life of the Lamberts" Use Case Stories . I also have found in my PC's backup history -- and have been able to "resurrect" -- the original Enterprise Architect (EA) artefacts that map these story lines to UML models (concept diagrams and sequence diagrams, etc.). I've uploaded this linked HTML set to a website, here: www.ecgroupinc.com/lamberts/EHRS%20Blueprint%20v2%20ERA%20Report/index.html.

These artefacts are obviously from our HL7v3 days... but the stories and the workflows still hold (generally) true, even after 14 years. I suggest that a useful premise for vetting our FHIR artefacts would be to ask: "could our CA-core artefacts be employed to operationalize the workflows described in the Life of the Lamberts?" I believe the answer to this will be "yes"... but if we find any gaps -- I think it will point us to areas we should explore as part of our internal due diligence.

I look forward to hearing what others think of this approach.
Warmest regards,
Derek

Attendees

Michael Savage
Sheridan Cook
Andrea MacLean
Igor Sirkovich
Lorraine Constable
Raman Dhanoa
Alex Goel
Harsh Sharma
Joel Francis
Ken Sinn
Mukesh Kashyap
Randy Nonay
Rita Pyle
Scott Prior
Shamil Nizamov
Shweta Munshi
Elliot Silver

Discussion:
• The group discussed and provided input on the parameters for the internal Due Diligence Review of the first draft of Canadian Core Profile set (soon to be completed)
• Sheridan and Mike to compile the input from the meeting and release out to Community for review and further input

Scope
• Scope should be focused on the domains we want to cover, not just a # of implementations we want to look at
• Registries
• Labs
• Pharmacies
• Patients Summaries
• Patient Admin
• Immunization
• COVID-19
• eReferral
• Focusing on live implementations give us more credibility and the capability to use them as technical references for comparison

Depth
• Start with the profiling decisions that we’ve made in our core profiles (the ones relevant to the implementation we’re examining) and see if those decisions we’ve made are problematic in relation to the implementation’s decisions
• Does HL7 have any tools to validate that an IG is a valid derivation of FHIR resources / our core profiles?
• Start with the elements that we’ve changed: must support, changed cardinalities, changed terminology, changed data types
• Spot checks down to the element level for initial pass through

Success Criteria
• Recommendation to have a terminology lens to the success criteria statement, such as “CA Core terminology bindings do not challenge the structure of the ___ implementation’s approach”

Step-by-Step Process
• Should not use the governance calls for the review; keep the governance call for higher level discussions
• Could possibly use the Profile Review timeslot once the Clinical Stream is done
• Common request is to not set expectation for folks to work outside of the scheduled calls

Summary / Next Steps
• Sheridan and Mike to compile input on the above parameters and provide a draft framework for the group to react to

Hi all,

For the upcoming Canadian Core Governance Call on Friday May 29th, 2-3pm EST (reminder: see FHIR Solution Architecture in the InfoCentral calendar events), our agenda is the following:

1.Framework for Due Diligence Review / Use Case Gap Analyses: Mike will introduce the kinds of principles that will need to be in place for the group to conduct these CA Core <> Use Case / IG comparisons in a consistent and time-efficient way (e.g. comparing CA Core & COVID IG profiles). Once Mike sets the context, we will look to establishing the following principles for the reviews:

1. Purpose (why are we conducting these reviews, i.e. how does this positively impact the quality of our Canadian Core Profiles)
2. Scope (# of use cases to be examined)
3. Depth (how deep into each iGuide/use case do we go)
4. Success Criteria (how do we know we’ve accurately determined alignment or lack thereof)
5. Review Process (what is the repeatable, step by step process for going through the various cases)

Thank you!

-Mike