Pan-Canadian eReferral-eConsult (CA:eReC)

DFT - The specification is currently in development and subject to change. For a full list of available versions, see the Directory of published versions

Technical Foundation

Prerequisites

Before reading this formal specification, implementers are encouraged to first familiarize themselves with other key portions of this IG, specifically:

The Business Context for information about what this IG aims to accomplish including an overview of the business solution and process flow this specification will enable.
The Technical Background for information about the underlying specifications this IG builds upon including references to sections that implementers should read to establish a necessary foundation to understand the constraints and usage guidance described here.

Technical Background

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 behaviors that are strongly recommended (and which could result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
MAY: describes optional behaviors that implementers are free to consider but where there is no recommendation for or against adoption.

Must Support Definition

Sender:
- Elements marked with the "MustSupport" flag SHALL be populated as specified within the profile they belong to if available and appropriate (Conformant systems SHALL be able to show that they can obtain and send all fields that are marked as "MustSupport").
- Elements without the "MustSupport" flag SHOULD still be populated, however carry no expectations in the Implementation Guide.
Receiver:
- Receivers SHALL be capable of receiving resource instances containing data elements populated with the “MustSupport” flag' without generating an error or causing the application to fail.
- Elements without a “MustSupport” flag in a FHIR response SHOULD still be received without generating an error or causing the application to fail.
- The Receiver SHOULD be capable of displaying “MustSupport” data elements for human use or processing (including, storing them) for multiple events.

Notes:

To maximize interoperability, this Implementation Guide uses the "MustSupport" flag to identify elements that implementers must understand in order to properly submit, process, and/or view electronic referrals. Fields that are important for clinical use and clinical safety will also be marked as Must Support.
For Message Support, In Focus Resources, and Supporting Information, these essential elements will be the ones that provide the key information for all use cases.
For Administrative Resources, these essential elements will be the ones that allow systems to uniquely identify the people and organizations involved in the request.

Use Case Specific Guidance on MustSupport

Elements that are needed for all use cases are marked as "MustSupport".
Elements that are conditionally "MustSupport" for specific use cases have been marked as "Use Case Support"

Exchanging with Messaging

This implementation SHALL follow synchronous Message Request and Response paradigms. Messages SHALL include only the MessageHeader resource, and any resources directly or indirectly referenced from it. For more information about FHIR messaging, please refer to FHIR Messaging Overview page.

Exchange Paradigms

The current version of this guide is focused on the exchange of the electronic referral/consult payload using the FHIR Messaging Exchange Paradigm.

Messaging Exchange Paradigm

Transmission of eReferral and eConsult service requests, status updates, appointments and communications is provided by FHIR messaging. Details about messaging and the events used in this iGuide are detailed on the Messaging page.

Exchanging with RESTful API (out-of-scope)

This implementation MAY follow the Single and Multiple Resource exchange framework. Of the CRUD capabilities, the functionality MAY be used to retrieve Patient and Practitioner context information about ServiceRequest being received.

In future iterations of this guide it MAY also be used to retrieve information from a FHIR Server as part of a SMART integration.

Languages supported

JSON (SHALL) and XML (SHOULD).

FHIR Artifacts

This specification makes significant use of FHIR Artifacts to describe the structure and content of the messages to be exchanged as well as the behaviour of the participating systems.

Artifact Type	Use	Notes
StructureDefinitions	Specify use case specific constraints and extensions on the FHIR Resources used within messages.	A list of StructureDefinitions can be found on the Resource Profiles page
ValueSets	Specify the appropriate values to use within a given coded element within a FHIR Resource (Profile or Extension).	A list of ValueSets can be found on the Command 'pagelink' could not render: Page not found. page
MessageDefinitions	Specify the message payloads (i.e. the appropriate FHIR Resources) to use to transmit information for a given Event as well as the expected responses.	A list of MessageDefinitions can be found on the Messaging Events page
CapabilityStatements	Specify the minimum conformance requirements (i.e. Message Definitions and Operations) for the eReC Source and the eReC Target participating in a Direct Messaging integration.	A list of CapabilityStatements can be found on the Capability Statements page

Further refinement/validation of the CapabilityStatements is expected alongside the MessageDefinitions as the use cases and business requirements are finalized.

Underlying technologies

The integration methods and patterns in this IG are based on the HL7 FHIR standard. As a result, this IG uses terminology, notations and design principles that are specific to FHIR. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the specifications for using the Messaging.

Implementers who are anticipating leveraging the future specifications for using SMART-on-FHIR and FHIR RESTful APIs to exchange eReferral/eConsult content should familiarize themselves with: