Canadian FHIR Baseline Profiles - Profiling Updates + DDR – December 4th, 2-3pm EST

Hi all! As always, thanks so much Sheridan for the very detailed notes on the reviews and the changes discussed. All - please see the second half of the notes for a list of discussion items deemed by the group to require further input from the Community. Any thoughts on those items, please reply in this thread.

Attendees

Michael Savage
Sheridan Cook
Joanie Harper
Thomas Zhou
Daniel Zivkovic
Fang Cao
Fariba Behzadi
Rita Pyle
Shamil Nizamov

Clinical Stream Updates

• Likely not making changes to the existing observation profiles for now – lab panels use cases likely require separate iGuides to be made to support their needs
• 2 device profiles drafted, just need to add narrative content

CA Baseline <> IPS Comparison: Immunization Profiles

.site
• Looking to remove MS flag; rationale: MS for .site is too use-case specific

.route
• Will also remove the flag here, as it’s the same kind of information as .site; the level of constraint for these 2 elements should be consistent

.performer.function
• MS flag and 1..1 cardinality are not reflected in IPS
• Suggest to hold off on any decisions on changes to constraints in CA Baseline for this element for now; need more investigation of more use cases

.reasonReference
• MS flag not defined in IPS
• Would like to see more use cases if we’re to keep this as MS in the CA Baseline
• Plan to relax MS constraint

Please see below for existing items from this comparison which we feel require additional input from the FHIR Community. Please reply in this thread with any comments you may have on these proposed changes / issues:

StatusReason (MS in baseline)
• Not must support in IPS
• Candidate for potential relaxation but needs more input on it if this is something that we expect across 80% of Canadian IGuides/Implementations
• Follow-up findings:
o Not supported in DHIR R4 public retrieval of immunization profile
o May not be used in use cases that constrain status to "completed"
o Need to decide whether we will relax from baseline

Occurance.DateTime (DateTime is MS and String is removed as Data Type
• May be appropriate constraint for a registry focused profile
• Keep MS flag on DateTime
• Strengthen occurrence by putting a MS on it, w/ MS on dateTime
• Decision: Evaluate if CanImmunize, ICON, or other implementors are using dateTime exclusively
• Follow-up findings:
o Open Panorama API uses string for immunization date (of administration) though investigating further
o Need to decide if we should bring String back as data type as other types of use cases (citizen access, entry, etc.) may not be constrained to only use dateTime

primarySource - candidate for relaxation need to consider how/if it's being used by other Iguides/Implementations
• Decision: Evaluate if CanImmunize, ICON, or other implementors are noting primarySource
Follow-up findings:
o OpenPanorama & DHIR capture it
o Canimmunize will capture it, but other repositories participating in citizen based exchanged may not have this in the data model
o Not critical for read citizen access use cases

reportOrigin - fate is tied to primary source
• I would remove. Not in US core, not every guide will need to reportout on reportOrigin particularly when they only allow for primarySource
• Follow-up findings:
o Not in DHIR public retrieval

Question: IPS supports a Data Absent Reason profile for occuranceDateTime to allow for a value to be missing when the base spec requires one be present.
• Are we missing out on anything by not having a means to not provide occurrence - data-absent-reason

Hi all!

For the Friday Dec 4th agenda, we will begin with a review of updates from the Clinical Profiles stream, and then continue with the Due Diligence Review which is comparing the CA Baseline's Immunization Profile to its equivalent Immunization profile as defined in the International Patient Summary (IPS) FHIR iGuide. We began this comparison last session, but we've a few more data elements to work through.

Thank you!