Guidance

Conformance Language

This specification uses the conformance verbs SHALL, SHOULD, and MAY as defined in RFC 2119.
  • SHALL: Indicates requirements that must be met to be conformant with the specification.
  • SHOULD: Indicates requirements that are strongly recommended (and which could result in interoperability issues if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
  • MAY: Describes optional requirements that implementers are free to consider but where there is no recommendation for or against adoption.
An eReferral-eConsult-related message (e.g. ServiceRequest bundle, Task bundle, etc.) SHALL be well-formed and conform with this specification including conformance to business rules and data curation.Participants in eReferral-eConsult process SHALL use a PoS that has passed Alberta Health conformance, and the requesting and service providers SHALL be registered with Alberta Health to participate in this service.

Tested or Conditionally Tested Elements

This specification identifies the elements that will be tested during conformance validation to ensure vendors are able to support them. These elements are noted with "TESTED" or "CONDITIONALLY TESTED" element. To note, these tested elements may or may not have the MS (Must Support) indicator.

Unused if submitted

This specification identifies elements that will not be used eventhough submitted or present in a message . These include elements that may be used in other jurisdictions but are not used in Alberta and/or not used in Alberta in the present time but may be used in the future. These elements will not be tested and will not be used in the referral workflow process. These elements are placed in the section "Unused if submitted".

Identifier Policy

The AB:eReC uses URIs whenever Object Identifiers are required. URIs (Uniform Resource Identifiers) are globally unique identifiers for individual objects, as well as for value sets, code systems, profiles, namespaces, and more. URIs are the preferred object identifiers for FHIR objects, and are usually represented as URLs.For more information, or to obtain the proper URLs for use in this project, contact Alberta Health at hisca@gov.ab.caThe base namespace for global identifier such as the system identifier for Alberta Personal Health Number will be referred to as "[id-system-global-base]" throughout the specification.The base namespace for a local identifier such as a ServiceRequest.identifier Assigning Authority will be referred to as "[id-system-local-base]" throughout the specification.The base namespace for local code systems and value sets will be referred to as "[code-system-local-base]" and “[value-set-base]” throughout the specification.Due to the evolving FHIR standard and its developing framework and governance, implementers should recognize that these identifiers may change if identifier registration becomes governed nationally or internationally. Implementers are recommended to implement URIs using configurable variables.

Identifier Variables

Variable Value
[base-structure] "https://www.alberta.ca/fhir/StructureDefinition"
[id-system-global-base] "https://fhir.infoway-inforoute.ca/NamingSystem"
[id-system-local-base] "https://www.alberta.ca/fhir/NamingSystem"
[code-system-local-base] "https://www.alberta.ca/fhir/CodeSystem"
[value-set-local-base] "https://www.alberta.ca/fhir/ValueSet"

Data Formatting

Letter Case

Information in eReferral-eConsult message is stored as mixed case and information is preserved in the format provided by the source (e.g. ALL UPPER CASE, Mixed Case, lower case). eReferral-eConsult message consumers MAY apply data formatting rules where there is a local requirement to standardize information to a consistent format.

Extended Character Set

Information within eReferral-eConsult message SHALL be in UTF-8 to support extended characters beyond standard ASCII/ANSI character set including French characters.

Date/Time

In this specification, date/time SHALL be in UTC format. Date SHALL be "YYYY-MM-DD" or partial date formats “YYYY-MM” or “YYYY” . If this format is not provided, or an invalid date is provided in the defined format, the message will be rejected. Below are the formats supported:
  • 2015-01-07T13:28:17-05:00
  • 2015-01-07T18:28:17Z
  • 2015-01
  • 2015

Telecom

In this specification, the telecom SHALL be "+[country code]-[area code]-[exchange]-[subscriber number] ext."[extension]". Note that if country code is not used, the "+" prefix is skipped. Example: "+1-555-555-5555 ext. 123456"

URI/UUID

In this specificaiton, Uniform Resource Identifiers (URIs) leveraged are case sensitive. URIs MAY be absolute or relative, and MAY have an optional fragment identifier.Universally Unique IDs (UUIDs) SHALL be in lower case format (e.g. “urn:uuid:53fefa32-fcbb-4ff8-8a92-55ee120877b7”). It is recommended that UUID version 4 be used. When URI/UUID is used in indentifier.value the identifier.system SHALL be "urn:ietf:rfc:3986".

Referencing FHIR Resources

The following approach is used in AB:eReC for referencing resources in the Bundle:
  1. Referenced resource is included in the message as a Bundle.entry. When this approach is used, the following SHALL be expected:
    • The Bundle.entry.fullURL SHALL use urn:uuid
    • The UUID used in fullURL SHALL be used in Reference.reference to reference the corresponding FHIR resource in the Bundle
    • The UUID used in fullURL SHOULD also be assigned as the Resource.id
OR
  1. Use of Reference.identifier for identifier previously known to both systems. When this approach is used, the following SHALL be expected:
    • both .system and .value elements SHALL always be populated
Unless otherwise specified, the first approach is generally used in this specification.

Constructing Messages

Transmission of information between two systems using FHIR messaging involves the exchange of a message payload that consists of several parts:

  • A Message Bundle: A Bundle resource (.type = "message") is used to package together a collection of FHIR resource instances that will be sent from one system to another. The Bundle SHALL have an entry for each of the FHIR resources required to convey information about the business event, starting with the MessageHeader which SHALL always be first.

  • A Message Header: A MessageHeader resource with .eventCoding identifying the trigger event and other message related metadata including an .id, .source.endpoint, .destination.endpoint, .reason is used to convey the purpose of the message and to support message routing.

  • The Focus of the Message: MessageHeader.focus SHALL point to the ServiceRequest, Task, Appointment or Communication resource that is being acted upon.

  • Other referenced entities and supporting information: When there is an update to other resources in the notify-update-process-request, notify-update-service-request and notify-update-service-record events, the MessageHeader.focus SHALL reference other resources to convey information about the Patient who is the subject of the referral request (ServiceRequest.subject), the PractitionerRole of the requester (ServiceRequest.requester, MessageHeader.author), supporting information (ServiceRequest.supportingInfo), etc.

  • Identifiers & Timestamps: Bundles and MessageHeaders SHALL have appropriate identifiers & timestamps as defined in the FHIR messaging requirements. Each Bundle.entry element SHALL have a unique .fullUrl and resource so systems that receive messages can resolve references within the Bundle.

The event (MessageHeader.event) and focus of the message (MessageHeader.focus) determines the content and structure of the Bundle of information (FHIR Resources) exchanged between participants.

Reducing Message Size

References between resources within a Bundle (illustrated as relationships in the diagram above) are managed using using the Reference element, specified below.The structure supports references in either of two formats:
  • a reference to a FHIR resource including within a Bundle.entry, or
  • a shared business identifier for a resource known to both systems
AB:eReC Messaging requires that:
  • when sending Send new service request [ eReCm-1 ] transaction, all resources referenced within the message SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
  • when sending messages for other transactions:
    • any resource(s) referenced in MessageHeader.focus SHALL be included in the message as Bundle entries and referenced from other resources using an absolute URL
    • any resource referenced within the message that does not include a previously shared business identifier SHALL be included in the message as a Bundle entry and referenced from other resources using an absolute URL
    • other resources with a previously shared business identifier MAY be referenced using the reference.identifier element with both the .system and .value elements populated

Relationship Between ServiceRequest and Task Resources

In this specification, the ServiceRequest contains the information related to the request. The Referring Provider uses the ServiceRequest resource when communicating with CAT to send a new service request, to update a service request, and/or to revoke a service request. Similarly, CAT uses the ServiceRequest resource to communicate the service request to the Service Provider, to return an updated copy of the request to the Referring Provider, and to send a copy of the centralized Service Record to interested parties.The Task resource is used to communicate the workflow status of the service request. The Service Provider uses the Task resource to notify the CAT of the status of its service request processing such as when the Service Provider has accepted, rejected, or completed the service request. In turn, the CAT uses the Task resource to relay the status of the service request processing to the Referring Provider.The following diagram shows the general flow of ServiceRequest and Task resources as described above. See Sequence Diagrams pages for further details. servicerequest-task

Transactions Received by the Source System

As the request moves through its workflow, the Source System receives two kinds of notification messages:

  • Messages with the request's processing status. The initial response message from the Central RMS is a notification that a task has been created to perform the request (notify-add-process-request event [eReCm-6]). Later processing status messages notify the Source System when the request's processing status has been updated (notify-update-process-request event [eReCm-7]).

  • The Source System uses these processing status events to maintain its record of the status of the request. Depending on the Source System and its capabilities and configuration, and depending on the nature of the status update, these updates might trigger a notification within the Source System for the Referring Provider, or might only be captured as background information (e.g., recorded with the Source System's referral record, or noted on the patient chart).

  • Messages with the complete and up-to-date Service Record for the request. The initial message is a notification from the central RMS that a new Service Record has been created for the request (notify-add-service-record event [eReCm-2]), followed by notifications of updates to the Service Record (notify-update-service-record event [eReCm-11]).

  • The Source System uses these Service Record events as a reference for the definitive set of information for the referral. As the referral moves through its workflow, other participants (such as a Central Access and Triage team or Service Provider) will update the referral and add new information (for example, appointment details). The Source System uses the Service Record events to obtain this new information and to keep its record of the referral aligned with the Central RMS.

CAT, ServiceRequest, and Task Status Map

The following table shows the Central Access & Triage (CAT) referral status map to Task.status, Task.businessStatus and ServiceRequest.status.NOTE: The status of the referral record in CAT does not mirror the ServiceRequest and Task statuses required for messaging. E.g., CAT could update the Referral Reason or Priority of a newly submitted referral while the referral is at various statuses in CAT (most likely Clerical Triage in Progress). When there is a requirement to send the updated referral record to the Requester HCP (Referring Provider), the following table provides the status to be used for ServiceRequest and Task based on the status of referral in CAT.
CAT Status Task.status Task.businessStatus ServiceRequest.status Note
Accepted "accepted" "ACC" (Accepted) "active"
Appointment Booked "in-progress" "BOK" (Booked) "active
Cancelled "cancelled" "CA" (Cancelled) "revoked"
Completed "completed" "CM" (Completed) "completed"
Declined "rejected" "declined" "revoked"
Deferred "on-hold" "deferred" "active"
New Request "received" "NW" (New) "active"
Redirected "received" "redirected" "active"
Waitlisted "in-progress" "waitlisted" "active"
Appointment Missed N/A N/A N/A Internal to CAT only. Will not be shared externally.
Clerical Triage in Progress N/A N/A N/A Internal to CAT only. Will not be shared externally.
Clinical Triage in Progress N/A N/A N/A Internal to CAT only. Will not be shared externally.
Response in Progress N/A N/A N/A Internal to CAT only. Will not be shared externally.
Waiting for Appointment N/A N/A N/A Internal to CAT only. Will not be shared externally.
Waiting for Clinical Triage N/A N/A N/A Internal to CAT only. Will not be shared externally.