DRAFT - The specification is currently in development and subject to significant change. It is not ready for limited roll-out or production level use.

Sequence Diagrams

The section below provides guidance on how to read the sequence diagrams:

  • The sequence diagrams illustrate how the different standardized actors of systems should interact with each other to carry out specific standardized transactions, and the order in which the transactions and interactions occur when the Use Cases of the eReC are executed. Typically, a sequence diagram is referring to a particular Use Case.
  • The green swim lane is a simplified view of the actors and transactions, referencing as required the Foundational Profiles, defined here, in addition to other ones that are not explicitly illustrated on the diagram. These are pre-requisite conditions for this particular use case and it is assumed that these will be satisfied.
  • The blue swim lanes group sequence of processes (along with their required actors and transactions) that are needed to occur to satisfy this particular use case. These are to be read from left to right and top to bottom. Note that the sequence diagrams are not explicitly calling out whether the processes are synchronous or asynchronous, and in certain cases it may depend on the specific implementations.
  • The actors and corresponding transactions in red, represent the technical actors and transactions that are the bases to achieve interoperability between the different clinical systems.
  • For more information on core IHE Profiles and specific Canadian implementation guidance, refer to the Reference Architecture (RA v0.1.0 DFT).

UC-01: Referral to Service

Scenario: Requester Health Care Provider sends a referral request to a Performer Health Care Provider

Please see UC-01: Referral directly to a Service Provider for the full description of the use case.

UC01-Referral_Service


UC-02: Consultation Request

Scenario: Requester Health Care Provider sends a consult request to a Performer Health Care Provider

Please see UC-02: Provider-to-Provider Consultation Request for the full description of the use case.

uc02-consult_request


UC-03: Referral to a Central Intake

Scenario: Requester Health Care Provider sends a referral request to a Central Intake, which forwards to most appropriate downstream Performer Health Care Provider

Please see:

Routing and Splitting Referral Requests

Routing: The referral request is forwarded to a new downstream service from Central Intake.

Splitting: The referral request gets split into multiple parts/services that logically make up the original request at Central Intake, to be fulfilled by different downstream services.

UC03-central-intake_routingsplitting

Chaining Referral Requests

Chaining: A new, distinct referral is created to a downstream service based on the original referral after a service is performed at central intake.

UC03-central-intake_chaining


UC-04: Central Access and Triage (CAT)

Scenario: Requester Health Care Provider sends a referral request to Central Access and Triage, which manages the referral process

Please see:

Primary Flow

uc04-central-access-triage

Sequence Diagrams for select alternate flows

Additional Flows illustrating sceanarios in alternate flows. Based on UC04.

Please see Single Entry Models for additional information about why there is multiple service requests (SRs) referenced in these flows.

Additional Flow: CAT Request For Information

uc04-central-access-triage-RFI1

Additional Flow: Performer Request for Information

uc04-central-access-triage-RFI2

Additional Flow: Redirect after Performer Declined

uc04-central-access-triage-redirect

Additional Flow: Cancel eReferral

uc04-central-access-triage-cancel