DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.
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 requistion) is split into multiple service requests and send each to Performer HCPs on different Target Systems.
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.
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 requests 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
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
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 associted 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 | 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 | 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 | 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 | 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 | Source System | Store the status received for access by the user (etc) |
Routing vs Splitting
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 Alberta's 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.
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 | 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 | Source System | Update status of the service request |
Note:
- Adding appointments to the Service Record, sharing using notify-update-service-record allows appointments to be correctly assoicated with the service request and version.
- Using a separate message to convey associated status updates allows a Central System to communicate status of a request or requisition to a L2 Source System
Support for Communications
Where referrals are routed or split, Central Systems may be required to transmit Requests for Information received from Target Systems back to the Source System / Requester HCP.
| Party | Action / Trigger | Sending System | Focus of Message | State Change | Event Code | Receiving System | Expected action upon receipt of message |
|---|---|---|---|---|---|---|---|
| Central System | Receives RFI from Target System | Central System | Communication (CA:eReC) | n/a | send-communication-from-provider | Source System | Notify Requester HCP |
| Central System | Receives response from Source System | Central System | Communication (CA:eReC) | n/a | send-communication-from-requester | Target System | Notify Performer HCP |
Note: Secure communications are an L3 level capability with implications for patient care. Central Systems that integrate with less mature Source Systems must have appropriate processes in place to either restrict or support electronic communications with Target Systems.
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 Recordin 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 | 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 | 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-add-service-record | 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.
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 | 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 | 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.