Canadian FHIR Baseline Profiles - Profiling Updates + DDR - September 25th, 2-3pm EST

Hi all!

Here are the notes from the Due Diligence Review earlier today. A huge thank-you to Sheridan and much appreciation for her having managed the meeting and all the note-taking solo:

DDR Findings from the review of R4 immunization profiles in Ontario DHIR Point of Care Systems IGuide.

The DHIR IGuide uses tables to communicate profiling choices, things like must support, slicing, and binding strength aren’t readily available in this format. We confirmed three assumptions to aide in the review that were based on the scope of the DHIR guide as a prescriptive implementation guide:

1. Any element mentioned in the DHIR profile is expected to be supported by implementors, therefore if present we’re considering it flagged as MS for the purposes of the Due Diligence Review
2. Any value set provided in the DHIR profile is expected to be utilized by implementors to be conformant, therefore we’re assuming the binding strengths are equivalent to “Required” Value Set
3. Any element that is noted as an array (1..1*) with multiple value sets is comparable to a slice

CA Baseline Immunization Profile – Discrepancy Findings
- statusReason is must support in the baseline but not MS/included in the DHIR submission or retrieval profiles due to their current scope (DHIR is constrained to completed immunizations)
o Resolution: This is a critical element for implementations that include statuses of not-completed, completed-in-error. Relaxation of the MS flag is likely needed and will be explored. A usage note (and potentially invariant) is needed in the baseline to detail that it should be supported in Iguides that support statuses other than completed.
- vaccineCode has the same slicing and value sets for Generic and Tradename, but notably the binding strength for the value sets in the baseline is preferred (required in DHIR).
- occuranceDateTime is flagged as MS in both, in DHIR the cardinality is more constrained in the baseline (1..1). This is not an issue.
- primarySource cardinality (1..1), MS flag and binding match up to DHIR, but the baseline profile has a short description that is changed from base resource and does not line up with the DHIR short description
o Resolution: The rationale for this change will need to be reviewed in the CA Baseline profile
o Though it causes no DDR issues, this change in cardinality to 1..1 should also be noted as something to check in other Iguides/in connectathon feedback
- reportOrigin is flagged as MS in the baseline and DHIR submission profile, but is not present in the DHIR retrieval profile
o Resolution: It will need to be relaxed in the base resource to be reflective of our 80/20 rule and to avoid downstream conformance issues for existing implementation guides that would inherit MS flags if derived off of the baseline
- lotNumber and expirationDate were being considered for MS in the baseline but will likely not be added into the baseline profile given they are not present in the DHIR retrieval profile (and may not be MS in other IGuides)
- site and route are MS in the baseline and DHIR submission profile, but are not included in the DHIR retrieval profile
o Resolution: these will likely need to be relaxed until a decision is made on how to handle MS expectations for Iguide Authors (see note below)
- reasonReference is MS in the baseline but not found in DHIR submission or retrieval profiles
o Resolution: this will likely need to be relaxed until a decision is made on how to handle MS expectations for Iguide Authors (see note below)




Today’s DDR pointed out the importance of deciding how we will define and communicate Must Support (MS) expectations for implementation guide authors that will derive profiles from the CA Baseline profiles.
- Our guide currently defines MS in the context of what clients and servers should do.
- Because HL7 requires derived profiles to inherit must support, cardinality (and in some cases binding if the strength is required/extensible).
- As an artifact for implementation guide authors to derive from, we will need to make a decision to either 1) communicate different expectations to IGuide authors for what MS means for their purposes, or 2) relax the baseline profiles to remove MS flags that are not anticipated to be inherited into the vast majority of Canadian IGuides.
- If #2 is chosen, then we also may consider taking a similar approach that the entity profiles did (create general + more specific baseline profiles) if there is reasonable confidence that all Immunization Registries share a more prescriptive set of constraints in common with each other that other Imms implementors do not share (example: always having site/route).