This section of the specification focuses on the eReferral/eConsult data exchange architecture using Central Intake. In this architecture, the eReferral/eConsult messages are first sent to a single intake point that passes the eReferral/eConsult requests from the eReC Source to one or multiple eReC Target destinations. The Central Intake dispatches the messages received from the original eReC Source using mechanisms for message Routing, Splitting and Chaining.

Here are some of the capabilities of the Central Intake architecture:

• Present as a single referral destination for requester providers within a region and/or specialty/sub-specialty
• Triage based on referral completeness, appropriateness and urgency
• Find the most appropriate services based on location, urgency, service provider availability, patient/requester provider preference, and destination scope of care
• Transfer the referral to the appropriate downstream service
  • Route (Forward) the original referral to a new destination
  • Create a new referral based on the original referral and send to a new destination
  • Split a referral containing distinct services into multiple referrals for each service and send to new destination(s)
• Track the steps/transformations/work done to fulfill the referral and coordinate updates between the requester provider and downstream service provider
  • Receive updates on the transferred referral from the downstream services
  • Send referral updates on the transferred referral or requests for information back to the requester provider
  • Update the referral based on new information from the requester provider and transferring the update to the downstream service
• Collect data and report on referrals that are received and transferred

---

Routing, Splitting, & Chaining

Routing, Splitting and Chaining distinguish three different categories of use cases where an eReferral received may result in the creation of additional requests to fulfill the original request.

Routing

Routing is the mechanism used by the Central Intake when a referral is received and passed to a new handler or destination as the same referral as the original.

Routing occurs before a service is performed.

Splitting

Splitting is the mechanism used by the Central Intake when a referral that contains several different services gets split into multiple referrals for processing.

The resulting referrals are all constituent parts of the original referral. Splitting can be considered a case of Routing to more than one eReC Target.

Splitting occurs before services are performed.

Chaining

Chaining is the mechanism used by the Central Intake when a referral is received, and after a service is performed, it results in one or more additional new distinct requests for downstream services created to fulfill the initially requested service.

Chaining occurs after a service is performed, and the need was identified for additional services.

Chaining is used for tracking purposes, when original requester needs to be informed about the existence of the downstream request(s), status and/or resulting appointments.

General Business Rules

To avoid unnecessary complexity when exchanging eReferrals and related information using eReC Messaging, a few design constraints exist or are proposed:

1. Downstream and upstream systems are not expected to communicate with one another directly:
   1. eReC messaging SHALL always be with the nearest neighbour/system
   2. an eReC system that receives information about an eReferral SHALL also transmit those information updates between its integration partners
   3. an eReC system SHALL only see their nearest upstream and downstream neighbours/systems, the existence of other upstream and downstream systems SHALL be invisible
2. Receivers SHALL NOT make updates to a ServiceRequest received:
   1. status updates to a ServiceRequest received SHALL always be conveyed to other systems using a Task (process-request) resource .basedOn the ServiceRequest
   2. a receiver MAY create child ServiceRequests in response to a request received when work is reassigned, delegated or distributed to others
      1. A business identifier shared between a parent and child SHALL not be changed once set.
      2. When a child ServiceRequest is created as a result of Splitting/Routing, it is indicated in the child using .replaces attribute
      3. When a child ServiceRequest is created as a result of Chaining, it is indicated in the child using .basedOn
   3. a receiver that transmits child ServiceRequests to others SHOULD have the ability to transmit back all information the requester would otherwise expect from the receiver
      1. an eReC system that transmits information about a child ServiceRequest SHALL include the parent ServiceRequests information in all messages that reference the child
      2. this does not preclude senders and receivers from agreeing to exchange messages that transmit status updates, appointments, etc. referencing the parent ServiceRequest instead of the child where it is a better fit to requester system capabilities or business requirements
      3. an eReC system that transmits information about a child ServiceRequests SHALL use the appropriate message event codes to communicate information back to sender (e.g.: add-appointment when transmitting information about an appointment that has been scheduled)
3. Receivers SHOULD only share information about child ServiceRequests created to support referral routing, chaining or splitting when the requester of the initial request needs to know about the requested downstream services or related events and information.
4. The MessageHeader.focus element in FHIR messages SHALL contain references to the ServiceRequest(s), Task, Appointment or Communication that was added or changed as a result of the business event that triggered the message.
   1. When Appointments and Communications are exchanged, they SHALL be in MessageHeader.focus and .basedOn the appropriate child ServiceRequest.
5. In scenarios where there is a combination of routing/splitting AND chaining
   1. The same referral cannot both route/split and chain within the same hop, it must be sequenced.
   2. A replacing action cannot also be basedOn.

Routing/Splitting Flow

Chaining Flow

The diagram below describes the generic chaining flow which includes both Point-to-Point and Central Intake architectures. The eReC Dispatcher Actor that is part of the Central Intake, does not play a significant role in eReferral chaining.

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 (used in splitting scenario), Task.basedOn, and Task.output.

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.

Message Creation when Routing

1. An eReC Receiver 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 ServiceRequest – including .requester, .identifier and .requisition – SHALL be copied to the new ServiceRequest
   5. the parent ServiceRequest information referenced in .replaces SHALL always be included in the message Bundle exchanged
2. After routing a referral, an eReC System (Central Intake) SHALL mirror any ServiceRequest updates received from the eReC Sender in the child ServiceRequest and transmit to downstream recipients
3. After a ServiceRequest is routed, the status of the original ServiceRequest is to be set to closed.

Message Interpretation on Receipt when Routing

1. The eReC Sender can recognize that a referral sent has been routed by the receiver when it receives a notify-add-service-request message from the system of the eReC Recipient 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 Receiver processing a routed message MAY choose to ignore information in ServiceRequest.replaces when processing referrals as all information is in the ServiceRequest 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.

Creating Messages for splitting

1. To support splitting, the eReC Sender initiating new eReferrals SHOULD populate the ServiceRequest.requisition element on all new ServicesRequests with a unique identifier, MAY be one of the identifiers sent in ServiceRequest.identifier:
2. When splitting, an eReC System (Central Intake) will create and send multiple ServiceRequest where:
   1. .replaces SHALL reference the original ServiceRequest received
   2. .requisition:
      1. SHALL be copied from .requisition on the original ServiceRequest received when present, or
      2. SHOULD be copied from .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
3. After routing a referral, an eReC System (Central Intake) SHALL mirror any ServiceRequest updates received from the eReC Sender in the child ServiceRequest and SHOULD transmit to downstream recipients
4. After a ServiceRequest is transferred, the status of the original ServiceRequest is to be set to closed.

Message Interpretation on Receipt when Splitting

1. An eReC sender can recognize that a referral sent from a downstream system has been split by the receiver when it receives a notify-add-service-request message where MessageHeader.focus includes multiple (child) ServiceRequests, each with:
   1. the same value .requisition that already exists 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.

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 upstream Sender to downstream recipients

Message Interpretation on Receipt when Chaining

1. An eReC Sender can recognize that a referral sent has been chained by the receiver when it receives a notify-add-service-request message from an eReC 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 Source 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 Target. 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.identifier: business identifier shared between parent and child - ServiceRequest.requisition: business identifier shared between parent and child - ServiceRequest.replaces: populated in child with parent - ServiceRequest.basedOn: not used - ServiceRequest.status: used to designate that a ServiceRequest has been replaced.
Splitting	Always a 1:* relationship between parent and child ServiceRequests where: -ServiceRequest.identifier: new business identifier assigned for child - ServiceRequest.requisition: business identifier shared between parent and child - ServiceRequest.replaces: populated in child with parent - ServiceRequest.basedOn: not used - ServiceRequest.status: used to designate that a ServiceRequest has been replaced.
Chaining	1:1 or 1:* relationship between parent and child ServiceRequests where: - ServiceRequest.identifier: new business identifier assigned for child - ServiceRequest.requisition: new business identifier assigned for child - ServiceRequest.replaces: not used - ServiceRequest.basedOn: populated in child with parent