Canadian FHIR Baseline Profiles - Governance Stream Meeting - September 27th, 2-3pm EST

Thanks, all, for such an insightful and interesting discussion.

Joel -- I'm especially happy that you called out the work in the UK by the Professional Record Standards Body ( theprsb.org/standards/ ). Related to Francis' comment (and Ken's prior comment), I think a quick scan of the PRSB's list of standards illustrates an important point: for them to have value, we need to relate our CA-core FHIR profiles to use cases.

It was apparent to me on Friday's call that we will struggle to make the business case that digital health vendors need to adopt FHIR unless we can point to where this specification will be used. I think our MediTECH colleague made that very clear. And when we're looking to build a common jurisdictional consensus about adoption of a CA-core baseline, I think it makes sense that we'd frame that within the context of the adoption of a common set of use cases. When we're choosing one or more use cases to start with, I'm not convinced that a "low hanging fruit" argument points us in the right direction. The PRSB list of standards offers a good smorgasbord of candidates to choose from. I think we'll be best-served by choosing a use case that really matters. In my view, one that has a heavy health impact will be more compelling than one that is a light lift.

It's going to take effort (and money!) to build adoption of our CA-core FHIR baseline... more effort, by quite a bit, than it is going to take to develop the technical spec, itself. It's going to have to matter that we do this... and FHIR for FHIR's sake simply doesn't matter enough (any more than v3 for v3's sake did). We will need folks to have a business case that warrants making the necessary investment. And for that... we'll need to contextualize our spec in terms of an important and impactful use case that patients and clinicians and jurisdictions (and therefore, vendors) see value in.

Of course... in situations where there already are mature health informatics approaches that work... we'll also have to be able to make the case that taking on the risks of breaking something that works is worthwhile. A strategy based on the idea that a FHIR interface can augment (rather than unseat) an existing interface would be smart and would help mitigate risk. It can also (usually) be supported by a good TCO argument.

These are all considerations that I think we'll need to take into account when we want to make a "pitch" to our key stakeholders to start to drive uptake of a CA-core. I believe we should start to turn our minds to crafting that compelling message.

Biological gender (in all of its different aspects) is captured using Observation. Patient is about demographic categorization. Fine-grained tracking of gender identity from a clinical perspective would also be Observation. For those systems that wish to track gender identity for demographic categorization purposes, you would use an extension on Patient. For the to be included in CA core, it would need to be something that is consistently represented across the country (as a demographic characteristic) and if we wanted to make it 'mustSupport' it would also need to be widely supported by existing clinical systems.

In terms of terminology, our objective would be to standardize terminologies on a use-case independent basis as much as possible. Certainly nailing down codes for drugs, allergies, conditions, etc. Presumably we can build on the standardization that already happened in the pan-Canadian standards work - insofar as it actually got adopted.

As Derek mentioned, the medication management use-case is a great step forward and it closes the gap between some of the challenges raised by Ken here - infocentral.infoway-inforoute.ca/en/forum/266-fhir-implementations/2955-canadian-fhir-baseline-profiles-governance-stream-meeting-august-30th-2-3pm-est#5281

I feel working against any use-case will help tie down the scope of the work in terms of completeness and it gives us a benchmark to validate against.

I also strongly feel that the “base-line” work needs to incorporate harmonization of the terminologies that are used for a particular use-case. The FHIR standard really serves as the metadata and wrapper while the terminologies convey the true meaning and context. While we are busy standardizing the structures of these “wrappers” it will be no good if I were to open a letter/wrapper but still not understand the meaning that it is trying to convey.

Francis makes another important point about the status quo and the reality of thigs. - GENDER fields to distinguish biological sex and gender identity as part of the basic demographic information. If I were to work with the current Patient CA-core profile and use it as is - Would it be able to convey biological sex and gender identity?

theprsb.org/ - is another great example of how standards are developed.

Hi Francis,

We should be *extremely* cautious about using the base profiles to up the bar for implementers in any way. The objective is not to drive new behavior, but merely to get systems to expose and consume the data elements they already support in a standardized way. That's the first step along the FHIR path. Asking implementers to go beyond the status quo at the same time we ask them to step up to a completely new syntax is often a step too far. Also, everyone has their particular 'pet' desires (all with good rationale) where they'd like to up the bar. It then becomes extremely difficult to draw the line in terms of what 'new' content is in vs. not.

My personal recommendation is to only introduce new 'mustSupport' elements if we have a strong regulatory foundation - i.e. it's something the implementers are going to have to do whether they adopt FHIR or not. Note that this is *not* because I don't share your concerns about marginalized communities, but more that asking too much too soon may result in us getting nothing at all. Once we have Canadian EHRs using FHIR, it becomes easier to introduce additional elements.

I think our biggest challenge here is that we're going about this process opposite to how US Core was developed - namely that the EHR vendors were driving the process and governmental agencies were just watching. Here we have primarily governmental and academic participants driving the specification. I do agree that capturing rationale would be useful. But we also need to find a way to get the EHR vendors to be more involved in the process. I'm not sure that an alternate presentation is going to be sufficient to drive that. What was the engagement mechanism for those other projects?

Hi all, I am responding to the postings by Derek and Lloyd regarding governance, implementation guide and core profiles. I believe we can find a common ground that can be win-win for most. Here are my comments/suggestions (sorry for the long reply):

(1) The topics of IHE implementation guide and FHIR Canadian core profiles came up when we were discussing governance in terms of finding ways to seek endorsements from the broader health communities (i.e. vendors, clinicians, jurisdictions and SDOs). There was agreement that we need a convincing argument for these communities to "endorse" the Canadian core profiles. This may boil down to having a clear rationale and message that can be packaged and shared with these communities, especially folks who may not know the technical detail of FHIR (or IHE). The rationale/message has to be packaged in a way that make sense to different communities, which will vary depending on whether they are clinicians, administrators, policy makers, vendors, patients or the general public. This means that we will need different levels of detail or emphasis to articulate why/how the FHIR core profiles can add value to their worlds so they will WANT to endorse these profiles.

(2) While our work to define/refine the Canadian core profiles is hugely important, it is very technical in nature and focused mainly on reviewing the detailed specifications of the 20+ core profiles. This makes it difficult for the broader communities to follow and endorse this work as they are not familiar with FHIR profiles, the technical jargon used and the implications of the choices made. This means we need to find a translation layer to package these detailed specifications in a way that non-technical folks can understand.

(3) Here are two examples of published common data elements in specific domains that have broad support of the clinician communities. One is the ACCF/AHA cardiology clinical data standards for EHR - ahajournals.org/doi/full/10.1161/cir.0b013e31821ccf71 ; another is the pan-Canadian asthma and COPD standards for EHR - www.tandfonline.com/doi/full/10.1080/24745332.2018.1517623 (the list of data elements can be found in the supplemental link www.tandfonline.com/doi/suppl/10.1080/24745332.2018.1517623?scroll=top ; If you read these published reports, they describe the rationale for and process of developing the data standards, with the data elements defined in a way that non-technical folks can understand. May be this is the type of packaging we need for our communities to understand the need for the FHIR core profiles so they will WANT to "endorse" these profiles because it is going to improve their day-to-day work/lives?

(4) On the issue of whether the FHIR core profiles should be context-free or context-dependent, I think the answer is somewhere in between. The two published data standard examples are for specific domains, so they show context can help one better understand the need for certain data elements. But we also agree if it is too context-specific then the profiles become limited in their usefulness. My worry with being totally context-free is that it will resort to the lowest common denominators or status quo with minimal specifications that is equally not useful.

(5) I believe working on the Canadian FHIR core profiles gives us a unique opportunity to help advance the health of Canadians through ethical use of health IT. I offer two examples to show how we can contribute to improving health through the core profiles. First is the ADDRESS field to include a must-support code of "no-fixed-address". This will go a long way to document individuals who may be homeless or transient as part of the basic demographics so this info can be routinely collected and updated. Another is the inclusion of SEX and GENDER fields to distinguish biological sex and gender identity as part of the basic demographic information. At the federal level, government agencies have already started to implement ways to collect sex and gender information routinely that we will eventually see in census, passports, etc. Rather than remaining status quo with ADMINISTRATIVE GENDER, we should incorporate SEX and GENDER fields as part of the basic demographics with the new non-binary definitions. By remaining status quo, we are perpetuating health inequity by excluding marginalized populations such as the homeless and LGBTQIA2+ communities from being visible and counted.

I hope these comments will help stimulate further conversations on the path forward with the Governance and Profiling discussions.
Thanks - Francis

Hey Michael -- I just posted a note related to today's call on the IHE forum:
infocentral.infoway-inforoute.ca/en/forum/223-integrating-the-healthcare-enterprise-ihe/3002-governance-the-real-key-to-digital-health-interoperability#5344

Thank you all for such a terrific call today!
Warmest regards,
Derek