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.ca

The 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 service request. The Referring Provider uses the ServiceRequest resource to communicate 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 Service Provider and when CAT sends the centralized referral record to interested parties.

On the other hand, the Task resource is used to communicate the workflow status of 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, completed, etc., 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

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.