Modification of pan-Canadian Specification

Sometimes, implementors uncover constraints in a pan-Canadian specification that make it difficult for them to use the pan-Canadian profiles directly or through re-profiling. Examples are outlined in Conformance Rules for iGuide Authors and Identifying Gaps in iGuides . These typically result in a need for a change request.

Issuing a Change Request

Pan-Canadian Initiative working groups exist to help identify and resolve these requests for change in a predictable and transparent manner. Working groups are made aware of requests for change through two channels: 1) showing up to a working group call and requesting that time be put on the agenda to discuss your request, 2) submitting a change request via Jira using the process described here.

The Jira issue should be ticketed against the Project of the target specification (e.g., Patient Summaries, CA:FeX, eReferral - eConsult, etc.) and supply a minimal set of information to allow the working group to assess your request and timeline for application.

Example Jira Change Request:

  • Project: Patient Summaries (PS)
  • Summary: Relax minimum cardinality on Patient.Gender
  • Raised in Version: CI Build
  • Description: My jurisdiction has legislation that provides citizens the right to convey administrative gender codes not captured under the Patient.Gender required valueSet. Maintaining this constraint adds burden on vendors that are already conveying these details using the Sex and Gender Harmony extensions. My jurisdiction requires the change to remove the minimum cardinality constraint on Patient.Gender to be made in the next 3 months to support our asset development timeline.

Criteria for Assessing Change Requests:

Some specifications may have additional criteria, but the criteria below will be used as a starting point for the working groups to assess the request for change:

  1. Applicability across implementations: Level of uniqueness of the request to the requesting party (whether the request is localized to the requesting party or is expected to be shared by other implementors in the future),
  2. Permanence: The duration of the changes being requested
    • Limitations in place temporarily due to the nature of the technology (i.e. pilot launch or initial technical limitations), or
    • Reflection of true differences in use/practice that are expected to be sustained
  3. Maturity of the pan-Canadian specification: Impact of modifications on the established pool of implementors.

Variance Request

When the misalignment cannot be resolved through implementor change management or changes to the pan-Canadian specification – a variance request can be initiated via email to interoperability@infoway-inforoute.ca.

Requesters are expected to provide a list of the variances with indications of known timelines and/or efforts to resolve the misalignment as a page in their implementation guides.

In order to minimize disruption of these variances, direct derivation of profiles is recommended but may require temporary suspension of errors.

Note: Process for requesting variance expected to support temporary variances initially – but as specifications are used more broadly may have to grow to support valid sustained variances