Pan-Canadian eReferral-eConsult (CA:eReC)
1.1.0-DFT 
DFT - The specification is currently in development and subject to change. For a full list of available versions, see the Directory of published versions
L3: Advanced Workflows
Where Single Entry Models are in use, a Service Record created on a Central System in response to request sent by a Requester HCP is processed by a Case Assigner who accepts the request, performs designated tasks, that result in the assignment of work to one or more Performer HCPs who may receive and process the request on different Target Systems.
The two messaging patterns apply broadly to Single Entry Models:
- Routing: where a a service request received is passed on to a Performer HCP on a different Target System
- Splitting: where service request containing multiple distinct services (e.g.: an imaging requisition) is split into multiple service requests and each sent to Performer HCP(s) Target System(s).
A third, closely related, pattern is Chaining, where a service request is received, performed and completed by a Performer HCP (e.g.: referral to an assessment centre) resulting in a new service request based on the first being created and assigned to another Peformer HCP.
Routing, Splitting and Chaining related system requirements are described in more detail below.
Related Content:
- For additional details on Routing, Splitting, and Chaining system requirements, see the Business Rules page.
- For details on Routing, Splitting, and Chaining within messaging workflows, see the messaging page.
- For details on Routing, Splitting and Chaining in Central Intake workflows, see the Use Case 3 - Referral to a Central Intake sequence diagram.
Routing & Splitting
A Central System claiming Level 3 compliance SHALL provide the ability for a Case Assigner to assign and route service requests received on to Performer HCP, including the ability to:
- [L2] receive and process a service request from a Source System and transmit status updates back to the Source System as the service request received is performed
- [L3] generate and transmit notifications to the Source System when a shared service record is created on the system for Case Assignment, when child requests1 are created as a result of splitting, and as the record updated with assignment of Performer HCP(s) (routing)
- [L2] generate and transmit a service request(s) to a Target System(s) and receive and process status updates from the Target System as a service request is performed
- [L3] generate and transmit notifications to a Connected/Source System as the shared service record is updated with information received from the Target System as a service request is performed
1 The original referral that was submitted is now considered the parent referral upon creation of the child referral.
A Source System claiming compliance with Level 3 SHALL have the ability to receive and appropriately process valid messages received from a Central System as a service request is (re)assigned to a new Performer HCP and processed.
Note:
- The technical specification defines distinct technical actors corresponding to the L3 requirements above for both the Source System and Central System.
- Part of the intent in separating actors is to make it clear which components are needed for less capable systems to refer to central intake without full visibility into downstream services requested and provided
- Routing is a required functionality of these types of models and is considered a SHALL, in comparison not every Central System will support Splitting so it is considered a SHOULD.
Trigger Events and Interactions
From a messaging standpoint the mechanism to convey that a service request received has been routed is for the Central System to send the Source System a copy of the current Service Record with a focus on the version of the service request sent to the Target System.
Illustration
Sharing Service Requests and State
The table below illustrates real-life trigger events associated with state changes associated with routing of a service request, including the specific event codes within the FHIR message. This list is not exhaustive.
| Party | Action / Trigger | Sending System | Focus of Message | State Change | Event Code | Receiving System | Expected action upon receipt of message |
|---|---|---|---|---|---|---|---|
| Central System | Receives a service request, initiates processing the request | Central System | Task (CA:eReC) (code='process-request') | Task created to track status |
notify-add-process-request (L2) | Source System | Store the status received for access by the user (etc) |
| Central System | Takes 'ownership' of a request received prior to assignment | Central System | ServiceRequest (CA:eReC) | New "Service Record" created MAY add shared identifier to the service record |
notify-add-service-record (L3) | Source System | "Replace" the service request sent to the Case Assigner with the version received (or store a new record and associate with the one sent) |
| Case Assigner | Assigns the service request to a Performer HCP | Central System | ServiceRequest (CA:eReC) | Change to ServiceRequest.performer element |
add-service-request (L1) | Target System | Store the service request received for access and processing by the user (etc) |
| Central System | Informs Requester that the service request as been assigned to Performer HCP | Central System | ServiceRequest (CA:eReC) | Change to ServiceRequest.performer |
notify-update-service-record (L3) | Source System | Store the updated service request received for access by the user (etc) |
| Central System | Receives and stores status update from Target System | Central System | Task (CA:eReC) (code='process-request') | Change in Task.status | notify-update-process-request (L2) | Source System | Store the status received for access by the user (etc) |
Note:
- The notify-add-service-record ServiceRequest.status aligns with the L1: Send, Receive, Revoke state machine diagram.
- The notify-update-service-record will align with either the L1: Send, Receive, Revoke or the L2: Shared Workflow Status state machine diagram. This will vary depending on if the focus is on the ServiceRequest or Task.
Linking Child and Parent Service Requests
Elements in the FHIR ServiceRequest resource associate a service request generated by the Central System with the request it received from the Source System. Difference in how these are populated reflect the different semantics of what is being shared / cardinality.
| Message Element | Routing | Splitting |
|---|---|---|
| ServiceRequest.identifier1 | Populate with the ServiceRequest.identifier received (i.e.: it is a new version of the same service request) | New identifier generated by Central System |
| ServiceRequest.requisition | n/a | Populate with the ServiceRequest.identifier received (i.e.: it is a child of the service request) |
| ServiceRequest.replaces | Populate with a reference to the ServiceRequest received | Populate with a reference to the ServiceRequest received |
Note: 1 ServiceRequest.identifier is a repeating element. In Central Access & Triage Model, the Central System will be required to add an identifier to the record which will be considered the primary identifier for a referral.
Status of a Parent Referral after Routing or Splitting
Where referrals are routed or split the status of the parent referral and the Status of the child referral(s) will not necessarily be the same. In these cases:
- the Central System retains responsibility for managing the status of the initial (parent) referral and communicating status to the Source System using the Requester/Performer P2P Integration
- the Central System MAY also transmit back the status of child referrals back received from the Target System to the Source System using the Informer/Recipient Integration
Business rules that determine the status of the parent referral will vary by referral pathway and therefore are not defined in this guide and must be discussed between vendors at the time of implementation.
Examples:
- for routed referrals, a Central System may keep the parent referral active when a child is created, assigned and declined to allow the referral to be assigned to another provider
- for split referrals, a Central System may consider the parent referral (e.g. medical imaging requisition) to be inactive after the child referrals have been created, assigned and accepted
Copying Supporting Information to Child Request(s)
Where referrals are routed or split, each child referral (ServiceRequest) in MessageHeader.focus must have its own .supportingInfo. Within the message payload, the referenced resources in .supportingInfo SHALL be .basedOn the child referral.
In the case of Routing, .supportingInfo received on a parent request SHALL be transmitted as .supportingInfo with the child. Where needed, additional .supportingInfo MAY also be transmitted.
In the case of Splitting, business rules will vary by use case. Therefore, this specification does not specify that the .supportingInfo a Central System receives on the parent request is to be copied to a child even though this might be a business requirement on some (or possibly all) integrations.
Sharing Appointment Information
Where referrals are routed or split, Central Systems may be required to transmit Appointment information received from Target Systems back to Source Systems.
| Party | Action / Trigger | Sending System | Focus of Message | State Change | Event Code | Receiving System | Expected action upon receipt of message |
|---|---|---|---|---|---|---|---|
| Central System | Receives Appointment from Target | Central System | Appointment (CA:eReC) | Appointment added to service record | notify-update-service-record (L3) | Source System | Store the updated service record with appointment |
| Central System or Case Assigner | Updates referral status if applicable | Central System | Task (CA:eReC) | Referral record status change | notify-update-process-request (L2) | Source System | Update status of the service request |
Note:
- Adding and updating appointments using notify-update-service-record allows appointments to be correctly associated with a service request.
- A separate message can be used to convey associated status updates on the parent referral by a Central System to a L2 Source System.
Chaining
A Target System or Central System claiming Level 3 compliance SHOULD provide the ability for a Performer HCP or Case Assigner to create a new "chained" service request by:
- [L3] allowing a referral request created while (or as a result of) performing a service request to be associated with the service request being performed
- [L3] generating and transmitting a notification to the Source System of the service request being performed of the new referral
- [L2] generating and transmiting the referral request to a Target System(s) and receiving and processing status updates from the Target System as a service request is performed
- [L3] generating and transmitting notifications to the Source System as the shared service record is updated with information received from the Target System as a service request is performed
A Source System claiming compliance with Level 3 SHOULD have the ability to receive and appropriately process valid messages received from a Target System or Central System where the focus is on a chained request
Note: The technical specification defines distinct technical actors corresponding to the Level 3 requirements above for both the Source System and Central System.
Trigger Events and Interactions
From a messaging standpoint the mechanism to convey that a service request received was created through chaining is for the Target System or Central System to send the Source System a copy of the new Service Record in focus.
Illustration
The chaining flow is illustrated below. In real-world implementations (e.g.: assessment centres) the referral to downstream services (e.g. surgery) may made directly by the Performer HCP or by a separate Case Assigner acting on directions received from the Performer.
Sharing Service Requests and State
The table below illustrates real-life trigger events associated with state changes associted with chaining of a service request, including the specific event codes within the FHIR message. This list is not exhaustive.
| Party | Action / Trigger | Sending System | Focus of Message | State Change | Event Code | Receiving System | Expected action upon receipt of message |
|---|---|---|---|---|---|---|---|
| Performer HCP | Creates a referral request based on another request being performed | Central System | ServiceRequest (CA:eReC) | Service Record Created | add-service-request (L1) | Target System | Store the status received for access by the user (etc) |
| Central System | Chained service record is created | Central System | ServiceRequest (CA:eReC) | Service Record Created | notify-add-service-record (L3) | Source System | Store the record received, associate with existing request |
| Central System | Updates status of record as information is received from the Target | Central System | Task (CA:eReC) (code='process-request') | Change in Task.status | notify-update-service-record (L3) | Source System | Update the status of the record |
Linking the Service Requests
When associating a chained request with the referral received a Target System or Central System SHALL set the ServiceRequest.basedOn element of the new request with a referrence to the existing request being performed.
Supporting Information on Child Requests
When Chaining takes place, the child referral (ServiceRequest) in MessageHeader.focus will have its own .supportingInfo. Within the message payload, the referenced resources in .supportingInfo SHALL be .basedOn the child referral.
This specification does not require the .supportingInfo on the child request be the same as the information received on the parent. This might be a business requirement on some (or possibly all) integrations.
Sharing Appointment Information
Where referrals are chained, Central Systems may be required to transmit Appointment information received from a Target System back to the users of the Source System.
| Party | Action / Trigger | Sending System | Focus of Message | State Change | Event Code | Receiving System | Expected action upon receipt of message |
|---|---|---|---|---|---|---|---|
| Central System | Receives Appointment from Target | Central System | Appointment (CA:eReC) | Appointment added to service record | notify-update-service-record (L3) | Source System | Store the updated service record with appointment |
| Central System or Case Assigner | Updates referral status if applicable | Central System | Task (CA:eReC) | Referral record status change | notify-update-process-request (L2) | Source System | Update status of the service request |
Note:
- This follows the pattern used for routing and splitting.
Support for Communications
Communications to an upstream Requester HCP for a chained request is not supported.