Alignment to Standards

The Alberta eReferral-eConsult Messaging Standard (AB:eReC) is scoped for eReferrals and eConsults generated, stored, and transmitted within Alberta. This contrasts with the Pan-Canadian eReferral-eConsult Messaging Standard (CA:eReC), which is intended to support intra-jurisdictional use, cross-jurisdictional use, and cross-border use. This difference in scope is the root of most of the variances between CA:eReC and AB:eReC. The AB:eReC attempts to profile in a way that allows the eReferral and eConsult instances to be conformant to CA:eReC, and CA-Baseline without having to formally derive from the profiles in these specifications. Alberta Health will continue to work with Canada Health Infoway to maintain alignment where applicable between CA:eReC and AB:eReC.

A few notable variances include:

Variance	Additional Description and Examples
Single integration pattern supported	AB:eReC is scoped based on Alberta needs and constraints. Consequently, it supports the Single Entry Model Integration only, specifically the Central Access & Triage (CAT) model.
Tighter MustSupport constraints	AB:eReC MustSupport elements are a superset of CA:eRec MustSupport elements; AB:eReC includes some additional MustSupport elements on top of those specified by CA:eReC (e.g. Patient.name.text and Practitioner.identifier.assigner are MustSupport elements in AB:eReC).
Tighter cardinality constraints	AB:eReC applies additional cardinality constraints on some elements to support business requirements including integration with provincial digital health assets in Alberta (e.g. Practitioner.name has 1..* cardinality in AB:eReC vs. 0..m in CA:eReC and Service.code has 1..1 cardinality in AB:eReC vs. 0..1 in CA:eReC).
Tighter constraints on optional data elements through use of invariants	AB:eReC uses invariants or constraints in the Bundle to ensure that data not permitted to be sent/received for privacy and/or clinical reasons are not included in an instance of Alberta eReferral-eConsult message (e.g. Practitioner.birthDate. Location.managingOrganization, ServiceRequest.encounter are restricted in AB:eReC). Additionally, AB:eReC uses invariants or constraints in the Bundle to ensure that optional data are present in an instance of a resource (e.g. Patient.telecom:Phone and Location.telecom:Phone must be present)
Tighter constraints on options for reference elements	AB:eReC places tighter constraints on some options for references (e.g. ServiceRequest.supportingInformation allows only Communication and DocumentReferece resources). Additionally AB:eReC uses Alberta profiles for reference elements whenever an Alberta profile is available (e.g. PatientABeReC is used in ServiceRequest.subject rather than the base FHIR Patient resource)
Use/addition of extensions	AB:eReC uses extension (e.g. Patient.extension.individual-recordedSexOrGender rather than Patient.gender to support additional gender such as "X"); extensions to support business requirements (e.g. ServiceRequest.extension.referralTimestamp to capture key timestamps in referral process).
Terminology	In some instances, AB:eRec uses a subset of CA:eReC bound value set/code system (e.g SecurityLabel) or uses an Alberta-specific value set (e.g. SpecialtyCode) instead of the CA:eReC bound value set.