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

Just a side-note that US Core is loosening their terminology expectations to be more use-case independent. Specifically, allowing ICD-10 in addition to SNOMED-CT and also adding language loosening terminology expectations around 'historical' records (where there might not be a 'standard' coding or a reasonable way to translate to one).

Perfect. If that's the focus, then I apologize for jumping in without full context and causing churn.

lmckenzie écrit: ...what's meant by a "z-segment specification".

I was referring to the bad old days of v2 when every system was "HL7 compliant" but a lot of them just threw proprietary or non-standard data into the Z segment. My concern with a "core" FHIR specification that contains only what vendors can do, today, is that FHIR's selling point is that its supposed ease of use will increase interoperability, not that it will entrench existing bad (system level) design.

lmckenzie écrit: Implementation of this will provide a use-case-independent way of accessing (and in some cases manipulating) data on a wide variety of systems.

I am concerned that accessing some data via FHIR when the "core" elements do not provide enough constraints to standardise elements that are the same across most or all use cases will lead to essentially incompatible implementations from jurisdiction to jurisdiction and even from institution to institution.

I think that Sheridan's explanation of the goal (not to accidentally constrain ourselves out of utility) is aligned with my previous comments. I apologise if my effort to communicate that was too far off the mark to be useful.

Sorry I'm late to the party. I'll level set on some things we've discussed on the last round of governance calls and that should clear up concerns on both sides.

Now that we're finishing up the first pass of profiles from each of the sub streams (Entities, Medications, and Clinical), we're ready to start doing QA and an internal "due diligence" review to make sure we don't have any glaring issues or areas where the constraints laid out in the profiles and implementation guide would cause issues with the ability for implementors to use the baseline AND participate in use case specific implementations.

This internal due diligence review isn't intended as a "superset" exercise (to add in elements that are present in other implementation guides), instead it seeks to identify areas where we might've over constrained to the point of precluding implementors of participating in other major projects. We are identifying use cases and IGuides to be able to do this litmus test.

We've proposed the following success criteria for the internal review: “Ca Core supports (Existing Implementation - X)”= the CA Core does not have any constraints that preclude the implementation capability & profiling decisions made by the (Existing Implementation - X)". While this criteria went over well in the last governance call, we're asking members of the community to provide their feedback on ways we can make it more clear.

If the CA-Baseline Core is not bound to Terminology that is harmonized across Canada then it makes it no different that the base HL7 Core FHIR Specification that is use-case agnostic. In order to use Terminology, we need to be domain specific which goes back to the need for a usecase. I think we need to start thinking in terms of data quality and that true semantic interoperability comes from harmonization of vocabulary. FHIR and any other HL7 specifications are just a wrapper that move quality clinician vetted data from point A to B.

hl7.org/fhir/uv/ips/ - "The IPS dataset is minimal and non-exhaustive; specialty-agnostic and condition-independent; but still clinically relevant. "

Is the CA-Core supposed to be the Canadian version of this? then we need to think about Terminology bindings.

Systems should not "blow up" if they receive a FHIR-compliant instance. They should not reject an instance merely because it contains unsupported elements or extensions (unless they're modifier extensions, in which case rejection might be the only safe course of action). We *can't* reasonably require that unrecognized extensions be processed in any way. It's completely acceptable for a receiver to throw them away (not persist, not display, not process) if the element is not marked as "must support". However, if the element is marked as "mustSupport", then the system must be capable of doing whatever the specification says they must do. Therefore, we should not be marking any elements as "must support" that we're not confident that most systems *do* support.

I'm not clear on what's meant by a "z-segment specification". The baseline profiles will define a clear API that is to be supported - and almost all of the elements in the profiles will be core elements. Implementation of this will provide a use-case-independent way of accessing (and in some cases manipulating) data on a wide variety of systems. That's huge, even if the set of data elements exposed isn't enormous/exhaustive.