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

In this case, we'd want the primary drivers to be the EHR vendors rather than the clinicians - as what matters most is what data the systems can easily currently expose, not what a particular group of end users might wish could be exposed.

Something else to add to the discussion. Grahame Grieve is working on (and gave me permission to share) an IG that he's working on that's intended to become an international baseline that US Core, AU Core and other national baseline specifications realize in their own particular jurisdiction. It's not done yet - or approved. But it's certainly something to look at aligning with (and/or providing feedback on)
build.fhir.org/ig/grahamegrieve/ipa-candidate/

Hi Francis,

I believe that what you are proposing is a similar approach to the PRBS in the UK. theprsb.org/standards/

This is awesome work that has actually been implemented.

They started with a base that was general and required by all domains and then went from there.

Clinician led and engaged work. The list of who has not been involved in the work is likely shorter than who was involved. (grin)

Joel mentioned it in an earlier post as well.

Andrea

They wouldn't necessarily be 'extensions' in the FHIR sense. For example, the MedicationRequest resource supports quite a number of elements to capture discrete dosage. Few of those are "mustSupport" in the US Core profiles. The might be mustSupport in an e-prescribing profile built on top of the US Core profiles. No new extensions would be introduced, just flagging additional elements as part of conformance expectations.

If the intention is to vet the CA core against the intersection of those three areas, that's a reasonable check, though I don't know that it's a given that elements not falling into the intersection *can't* be in CA core, nor does it mean that elements that are in the intersection *must* be in CA core. It's totally appropriate to ask serious questions in either of those cases though.

HI all,

I agree it is unrealistic to expect the core profiles to cover all aspects of healthcare. After all, they are "base profiles" so extensions are to be expected for specific scenarios. But even knowing what these profiles can and cannot do in these three domains will help us better understand the extra work needed for specific applications, the implications and their significance. By anchoring our review on the three domains, they can also help guide our discussions and focus on key areas requiring attention.

For example, we can plot the three domains (medications, summaries and referrals) as overlapping circles. The union of three circles will represent ALL (?) the data elements needed to support the three domains. The intersect will represent data elements that are common to all three domains. If certain data elements in this intersect are NOT in the core profiles then we can discuss whether they should be (or not). For elements that are in two overlapping areas, they are more likely to be extensions unless there is strong rationale to include them as part of the core profiles. Would that approach work? -Francis

As I committed to doing on the Governance call last week, I have raised the profile of this request internally and we are certainly looking into what we may be able to do.

As a key lesson learned, I do believe that we need more than one jurisdiction willing to commit to work on the clinical use case(s) and implementing the resulting specification.

Andrea

I do not want to interrupt this discussion either, just want to point your attention that only every second meeting is dedicated to profiling followed by governance. Since we have these meetings bi-weekly, we actually spend only 1 hour per month discussing profiles.

Proposed is to divide profiles into streams, let streams to meet as many times as they need, streams’ leaders to report results on monthly profiling meetings.

Michael may provide more insight what streams are if you like (or I can do that as well).