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

Routing, Splitting and Chaining

The following sections address use of messaging for more advanced workflows. The diagrams in this section illustrate the use of messaging for service request routing and splitting. Systems illustrated have Level 3 capabilities.

Related Content:

1. For details on Routing, Splitting, and Chaining system requirements, see the L3: Advanced Workflows and Business Rules pages.
2. For details on Routing, Splitting and Chaining in Central Intake workflows, see the Use Case 3 - Referral to a Central Intake sequence diagram.

Tracking eReferrals

Generally, when tracking eReferrals, the information is captured as of what happens to the eReferral throughout its lifetime – from the time the eReferral request is first submitted, until all the work and related work is complete. Along the way it is possible that the eReferral goes through multiple systems (e.g. Central Intake), organizations and/or providers and additional related referrals could be generated (as a result of routing, splitting and chaining activities. All this information is captured and linked back to the original eReferral request.

To track the eReferral and related information, there are specific attributes available in the ServiceRequest and Task FHIR resources, that are used specifically to identify the resources and capture the relationship between them, including but not limited to:

• ServiceRequest.identifier
• ServiceRequest.basedOn
• ServiceRequest.replaces
• ServiceRequest.requisition
• Task.basedOn
• Task.output

Please refer to L3: Advanced Workflows for a description on how each of these elements are used in the flows.

The diagrams below show how each of the attributes are used to track the information and link it back to the original eReferral.

Note: This section is not diving deeply into FHIR Resources, it rather aims to highlight specific information tailored to the topics described.

---

Tracking the eReferral when Routing

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Routing mechanism.

Note:

• ServiceRequest 2 can have its own identifier, in addition to the ServiceRequest 1 identifier

Message Creation when Routing

1. An eReC Requester (Central System) SHALL create and send copies of a ServiceRequest when ServiceRequest.performer is changed, where:
   1. .replaces SHALL reference the original ServiceRequest received/copied
   2. an .id is local to each system where the resource is stored and MAY be different from the ServiceRequest.id received from the requester
   3. references in ServiceRequest.supportingInfo MAY be added to include additional information when needed SHALL be subject to the same constraints as the original ServiceRequest
   4. other elements of the parent ServiceRequest – including .requester and .identifier – SHALL be copied to the new child ServiceRequest
   5. the child ServiceRequest MAY add a new .identifier in addition to the parent .identifier
   6. the parent ServiceRequest information referenced in .replaces SHALL always be included in the message Bundle exchanged
2. After routing a referral, a Central System SHALL mirror any ServiceRequest updates received from the eReC Requester (Source System) in the child ServiceRequest and transmit to downstream recipients

Message Interpretation on Receipt when Routing

1. The eReC Recipient (Source System) can recognize that a previously sent referral has been routed by the receiver when it receives a notify-add-service-record message from the eReC Informer (Central System) where MessageHeader.focus includes a single (child) ServiceRequest with:
   1. an .identifier that already exists in the local system
   2. .replaces references an existing (parent) ServiceRequest with the same .identifier
   3. performer is different between the parent and child
2. The eReC Performer (Target System) processing a routed message MAY choose to ignore information in ServiceRequest.replaces when processing referrals as all information is in the ServiceRequest referenced in MessageHeader.focus

---

Tracking the eReferral when Splitting

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Splitting mechanism.

Note:

• Status updates that are coming back from eReC performer to Recipient is the status of the original referral/ServiceRequest
• Status updates from the informer will reflect the status of the split referrals
• Implementaters may filter these based off what they are using and the workflow they are trying to achieve
• For additional information, please see Business Rules

Message Creation when Splitting

1. When splitting, an eReC System (Central Intake) SHALL create and send multiple ServiceRequest where:
   1. .replaces SHALL reference the original ServiceRequest received
   2. .requisitionSHALL be copied from an .identifier on the original ServiceRequest Note: multiple .identifiers with different systems may be present on the message, requiring a consistent rule to be defined by implementers.
   3. .id, .identifier SHALL be assigned by the system used to create the child ServiceRequest
   4. a parent ServiceRequest information referenced in .replaces SHALL always be included in the message Bundle exchanged
2. After routing a referral, a Central System SHALL mirror any ServiceRequest updates received from the eReC Requester (Source System) in the child ServiceRequest and SHOULD transmit to downstream recipients

Message Interpretation on Receipt when Splitting

1. An eReC Recipient (Source System) can recognize that a previously sent referral has been split by the receiver when it receives a notify-add-service-record message from the eReC Informer (Central System) where MessageHeader.focus includes multiple (child) ServiceRequests, each with:
   1. a .requisition that matches with an existing .identifier in the local system
   2. .replaces references an existing (parent) ServiceRequest

---

Tracking the eReferral when Chaining

This section illustrates the message creation and the message interpretation on receipt, including the most important data elements that are used to track an eReferral when it is passed through the Chaining mechanism.

The diagram below describes the generic chaining flow which includes both Point-to-Point and Central System integrations. i.e. Target Systems with Level 3 capability with the eReC Informer actor SHOULD be able to chain referrals.

Message Creation when Chaining

1. New ServiceRequests created as a result of services performed by the receiver SHALL only be shared with the requester using the chaining pattern where the downstream request is required to complete the requested service and the requester needs to know about downstream services or related events and information. In these cases:
   1. .basedOn SHALL reference the original ServiceRequest received
   2. .requester SHALL reference the person or organization that initiated the child ServiceRequest (not the initial requester)
   3. all identifiers including: .id, .identifier, .requisition should be assigned by the system used to create the child ServiceRequest
   4. a (parent) ServiceRequest is referenced in .basedOn SHALL always be included in the message Bundle exchanged
2. After sharing a ServiceRequest with downstream systems, an eReC System SHOULD also transmit ServiceRequest updates received from the eReC Requester (Source System) to downstream recipients

Message Interpretation on Receipt when Chaining

1. An eReC Recipient (Source System) can recognize that a previously sent referral has been chained by the receiver when it receives a notify-add-service-record message from an eReC Informer (Central System) where MessageHeader.focus includes a ServiceRequest with:
   1. .basedOn referencing an existing (parent) ServiceRequest with an unknown .identifier

---

Distinguishing between cases when receiving eReferrals

The eReC Recipient will need to recognize whether an eReferral has been Routed on to a new receiver, Split into multiple referrals or Chained to take appropriate action when processing a notification of a new service request received from eReC Informer. The following table summarizes the use of elements that can be used to distinguish between cases.

Case	Required Elements
Routing	1:1 relationship between parent and child ServiceRequests where: - ServiceRequest.identifier1: There is a shared business identifier between parent and child - ServiceRequest.requisition: not used - ServiceRequest.replaces: populated in child with a reference to the parent - ServiceRequest.basedOn: not used
Splitting	Always a 1:* relationship between parent and child ServiceRequests where: -ServiceRequest.identifier: new business identifier assigned for child - ServiceRequest.requisition: Populated in child with the ServiceRequest.identifier received from the parent - ServiceRequest.replaces: populated in child with a reference to the parent - ServiceRequest.basedOn: not used
Chaining	1:1 or 1:* relationship between parent and child ServiceRequests where: - ServiceRequest.identifier: new business identifier assigned for child - ServiceRequest.requisition: Populated in child with the ServiceRequest.identifier received from the parent when there is a 1:* relationship between parent and child - ServiceRequest.replaces: not used - ServiceRequest.basedOn: populated in child with a reference to the parent

Note: ¹ 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.