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!

Attendees Michael Savage Igor Sirkovich Derek Ritz Joanie Harper Rita Pyle Fariba Behzadi Kenneth Sinn Matthew Herbert Mukesh Kashyap Shamil Nizamov Sisira De Silva Thomas Zhou • Mike updated the group on the progress of the Due Diligence Review: currently in progress on comparing Immunization resource as profiled in CA Baseline and International Patient Summary • Matt Herbert walked the group through his progress on creating a Pitch Deck for the CA Baseline Profiles, which can be leveraged for surfacing the CA Baseline Profiles to senior stakeholders in the New Year in an effort to secure a group to provide governance of the CA Baseline Profiles • Framing the ‘ask’ being put toward senior stakeholders • Emphasis on articulating the desired sustaining / operating model that a governing organization should be supporting for the CA Baseline • Interoperability is not a technical problem; it’s more so a governance problem • Solution being put forward is the CA Baseline, and the ask is for governance of it • Will be good to leverage real-world stories of digital health investments at a national level; e.g. Netherlands’ very robust digital health governance allowed for cross-system COVID data sharing in a very short amount of time • One way to frame the solution in combination with the ask: CA Baseline = a conformance testable Spec that will go into procurement processes for digital health solutions in Canada • Will continue to build content for the deck and discuss with Governance stream for input

FHIR North 2020 Key Takeaways • Mike provided a recap of the conference, and some of the broad feedback received • Overall very positive response • Virtual format afforded ability to engage far beyond Ontario and Canada in terms of both attendees and speakers • Networking is still the experience that everyone in the virtual event space is working on improving • Large benefit to FHIR North being very topic-focused and concrete, keeps audiences more engaged Community Shout-outs – FHIR Implementations for the Community’s Radar • Denis / Trisotech working on integrating FHIR into BPM+ health (check out his plenary session from FHIR North 2020 if you attended!) • Integrating FHIR into healthcare business processes • Clients are more and more frequently looking for integration with FHIR in their services • iGuide for OneAccess Gateway and Viewlets – leverages FHIRcast for context management part of the spec • Ocean / CognisantMD will be working to implement based on the eReferral spec in new year • Will be implementing the SMART on FHIR client Community Shout-outs – Thoughts on New Opportunities for FHIR Implementers Community • Would be great to build or get connected to a Canadian SMART on FHIR ‘community of practice’ / learning group for Canadian SoF app developers • Also would be a big step to have a formal tool in place for validation and conformance testing; should be something that is accessible to everyone in the FHIR Community; something that could validate that an implementer had implemented the Spec properly Updates – eReferral • Currently on v0.1 of eReferral Spec • Ocean will be implementing the eReferral Spec in the new year • Working toward a HealthcareService API • Folks can look at the current HealthCareService profile work here: https://docs.google.com/document/d/1YRlghtBx9Pwi6o13lvX26esKaR2S8OLRdc-MIIVeM5s/edit Updates – Canadian FHIR Baseline Profiles • Good progress and momentum on the profiles continues • 3 main work efforts right now • Clinical Profiles Reviews: meeting weekly on Mondays to review the more clinical profiles, currently the remaining profiles for review in this group are the lab-related profiles • Due Diligence Reviews: meeting every other Friday, comparing the draft CA Baseline Profiles to their counterparts in existing Canadian FHIR iGuides, to determine if the CA Baseline profiles’ constraints are too strong, or if there are common constraints in the other iGuides that the CA Baseline profiles should inherit • Governance: meeting every other Friday (alternate to the above meetings), working on how to best surface the Profiles to the larger community for review, and how to best get the CA Baseline adopted by a national group who can mandate its use for any net-new FHIR implementations in Canada