Level 1 System Capabilities

Systems with Level 1 capabilities provide the minimum requirements for systems to participate in the exchange of an electronic referral request.

L1: Send, Receive, Revoke

To support the electronic exchange of referral information from a system the basic requirements are below.¹

A Source System claiming compliance with Level 1 SHALL have the ability to generate and transmit a valid message to a Target System when:

• A new Service Request is created, assigned to a Performer HCP (or Case Assigner) and submitted
• A message to Revoke the Service Request when it has been incorrectly assigned or submitted in error

A Target System claiming compliance with Level 1 SHALL have the ability to receive and appropriately process a valid message received from a Source System when:

• A new Service Request is created, assigned to a Performer HCP (or Case Assigner) and submitted
• A message to Revoke the Service Request when it has been incorrectly assigned or submitted in error

Note: ¹ Without the ability to participate in the bi-directional exchange of information a system is insufficient for closed loop eReferral or eConsult.

State Machine

In Level 1 integrations, the focus of messages is always on the service request. The exchange of information is triggered as the Requester HCP (or delegate) performs actions that change its state.

Noting that the Requester HCP is driving the states of this diagram and determine referral completion.

Trigger Events & Interactions

The table below illustrates real-life trigger events associated with Level 1 solutions the specific event codes within the FHIR message. This list is not intended to be exhaustive.

L1: Attaching Supporting Information

In eReferral and eConsult workflows a Service Request is typically accompanied by Supporting Information needed to support intake, triage or processing of a referral including pathway or destination specific referral forms, results of diagnostic tests, images, etc.

Supporting information may be passed in different formats:

• structured data
  • commonly "form" data in the FHIR QuestionnaireResponse resource
  • less commonly, specific FHIR clinical, observation or medication resources specified outside of this FHIR IG
• binary attachments referenced in the FHIR DocumentReference resource

Within messages exchanged using FHIR messaging, FHIR resources containing Supporting Information are referenced from the ServiceRequest.supportingInfo element.

Exchanging Supporting Information

To support the electronic exchange of supporting information for a referral, the basic requirements are below.

A Source System claiming compliance with the eReC FHIR messaging:

• SHALL have the ability to send references to binary documents using DocumentReference resource (more information below)
• SHOULD have the ability to send structured form information using the questionaireResponse (this is a requirement is some jurisdictions)
  • for compatibility with other systems, it is recommended that structured form information also be passed in an unstructured format as a binary attachment and/or as free text ServiceRequest.note
• MAY have the ability to send structured clinical information using other FHIR resources, for compatibility with other
  • for compatibility with other systems, it is recommended that structured form information also be passed in an unstructured format as a binary attachment and/or within QuestionnaireResponse

A Target System claiming compliance with the eReC FHIR messaging:

• SHALL have the ability to receive references to binary documents using DocumentReference resource as well as to retrieve the referenced document (more information below)
• SHOULD have the ability to receive structured form information using the questionaireResponse (this is a requirement is some jurisdictions)

Trigger Events & Interactions

The table below illustrates real-life trigger events associated with the exchange of supporting information with a referral with the specific event codes within the FHIR message. This list is not intended to be exhaustive.

Note:

• ServiceRequest is in focus when adding supporting information because ServiceRequest.supportingInfo will be updated to contain the additional reference
• when a binary attachment is updated, the DocumentReference .date and .content.attachment will be updated

Exchanging Binary Documents

In the referral workflow multiple, large binary files could potentially be referenced as ServiceRequest.supportingInfo.

To reduce message size, message performance and scalability, implementers are strongly recommended to use .content.attachment.url to enable asyncronous retrieval of binary attachments from a secure server instead of passing attachments within a message as base64 .content.attachment.data.

For future version, add information about patterns used to provide access to referenced attachments.

Level 2 System Capabilities

Level 2 systems build upon the simple electronic exchange of referral information provided by Level 1 systems by: enabling a Target System to share the status of work performed in response to a Service Request received (eReferral or eConsult), and

L2: Shared Workflow & Status

In eReferral and eConsult workflows the Service Record created on the Target System progresses through states as the request is assigned, accepted, performed and completed by the recipient.

Exchange of status information from a Target System back to the Source System using messaging imposes additional requirements on both systems.

A Target System claiming compliance with Level 2 SHALL have the ability to to generate and transmit valid messages to a Source System when the state of a request changes, including:

• when a message containing a Service Request is successfully received and stored for processing²
• as the work to process the request is assigned, accepted, rejected, completed, cancelled, etc. (etc) by the Performer HCP
• when the status of the record changes as a result of instructions received from the Requester HCP or another actor via messaging.

A Source System claiming compliance with Level 2 SHALL have the ability to receive and appropriately process a valid messages received from a Target System when the state of a request changes.

State Machine

Level 2 systems, build upon Level 1 capabilities by adding messages exchanged from the Target System to the Source System that focus on a Task (CA:eReC) that includes one of a standard set of status codes and, optionally, a deployment specific business status code. The exchange of information is triggered by actions taken in the Target System that change the Task status.

1 - Rejected and cancelled states are not considered terminal in some existing implementations, making it possible to move a request back to an active state. For more discussion of this, see Business Rules.

Trigger Events & Interactions

The table below illustrates real-life trigger events associated with state changes enabled Level 2 solutions, including the specific event codes within the FHIR message. This list is not exhaustive.

Level 3 System Capabilities

Level 3 systems build upon status tracking capabilities of Level 2 systems by:

• exchanging information about appointments that are scheduled as a result of an eReferral
• providing a secure method of communication between Health Care Providers to clarify the intent of eReferal or eConsult, to request additional supporting information, to seek clarification of advice given through an eConsult, etc.
• enabling advanced workflows that support:
  • Single Entry Models,
  • splitting of requisitions into multiple requests,
  • association of downstream referrals to the initial request

L3: Appointments

Important milestones within an eReferral workflow are the booking and completion of an appointment for the patient to receive the requested service.

A core feature of Level 3 systems is the ability for a Target System to provide Appointment information back to the Source System using messaging . The exchange pattern is similar to that used to track status.

A Target System claiming compliance with Level 3 SHALL have the ability to to generate and transmit valid messages to a Source System that focus on an Appointment when an Appointment is created, booked, rescheduled or cancelled.

A Source System claiming compliance with Level 3 SHALL have the ability to receive and appropriately process a valid messages received from a Target System when the state of a request changes.

Trigger Events & Interactions

Appointment Modifications

Transmission of a change or cancellation to a scheduled appointment is supported by the “notify-update-process-request” event.

Allowed changes include:

• a change to an appointment date
• change in location
• chagne in specialist
• change in status

L3: Communications

Secure communications between health care providers related to eReferral or eConsult are supported by messages that focus on the Communication resource.

The messaging supports both "general communications" and "requests for information". In practice, they are usually the latter and therefore should be treated as consequence events.

Trigger Events & Interactions

Requests for Information (RFI)

A request for information or RFI is to communicate that a service request received is not complete. In many cases, the Performer HCP will either have not accepted the request or will have placed it on hold pending a response.

Communications Payload

In communication messages the Communication resource SHALL contain:

• payload.contentString containing a question or comment as text
• category is a coded element typically containing rfi (request for information) or gen (general communication)
• basedOn, sender, subject containing references to the ServiceRequest, PractitionerRole sending the Communication and Patient respectively

Responses

When responding to a communication received, the Communication will also contain:

• inResponseTo referencing the Communication received
• payload.contentString containing a text response, and/or
• one or more payload.contentAttachment containing a .url to retrieve an attachment or .data

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:

1. [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
2. [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)
3. [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
4. [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.

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.

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

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.

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:

1. [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
2. [L3] generating and transmitting a notification to the Source System of the service request being performed of the new referral
3. [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
4. [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.

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.

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.

L3: eReferral vs eConsult

The exchange paradigms outlined within this Implementation Guide can be applied to both eReferral and eConsult workflows but there are slight variations between workflow to be taken into consideration when using this specification.

eConsult is considered an L3 capability in the guide because it draws upon other L3 capabilities including Communications and, typically, separate Requester HCP, Case Assigner, and Performer HCP roles and corresponding flows.

Case Assignment

The ON-eReferral-eConsult iGuide identifies eConsult specific business models that align closely but not identically with the Single Entry model examples in this IG, in a few ways:

• the Central System is used by both the Case Assigner (where applicable) and the Performer HCP;
• the Central System supports multiple Case Assignment models:
  • BASE Managed Service uses an algorith to perform case assignment taking into account location, availability, specialty, and sub-specialty, sometimes with human support.
  • Group Model allows the Requester HCP to choose a Group that performs Case Assignment to Performer HCPs within their group.
  • Direct allows the the Requester HCP to choose the Performer HCP to respond to the request

Notes

Consult notes are text-based notes and attachments exchanged using the Communication resource (contentString and/or contentAttachment). Exchange of notes may coincide with changes to Task.status (or Task.businessStatus) or not.

Notes can be added to an eConsult request at various stages of the process. The referrer may add notes when the consult is in the following states:

• Case Submitted/Redirected
• Clarification Requested
• More Information Provided

The specialist may add notes during the following consult states:

• Consult Provided
• More Information Requested

Case Redirect

Cases may be redirected to different specialists by the referrer and the case assigner. If a specific provider is not available, the assigner may redirect the case to another specialist. This scenario will not cancel or close the original request but direct it to another target.

A referrer has the ability to redirect a case when it is not assigned and before a consult is provided. In this scenario, the original request is terminated and a new one is generated.

Requesting Clarification

After a consult has been provided, if further information is needed, the referrer has the ability to request clarification from the specialist. The consult state changes to Clarification Requested.

Case Completion

After a consult has been provided by the specialist, if the referrer is satisfied with the response they will then mark the case complete. At this stage, the case state is Case Completed.

While the ON-eReferral-eConsult iGuide did have an additional step for completion of questionnaire by both the requester and the performer, the focus on collection is currently out-of-scope for the CA:eReC.

Trigger Events & Interactions

Examples corresponding to the business events above