Technical Actors

CA:eReC Messaging defines four different Technical Actors that perform different roles within messaging integrations.

As illustrated in the sections that follow, systems participating in real world architectures will commonly perform some or all of these roles.

Basic Integration Patterns

CA:eReC Messaging is meant to provide implementable technical specifications in support of real-world architectures associated with a range of integration patterns supporting different Business Models. Two basic message integration patterns provide building blocks for real-world solutions.

Requester/Performer Point-to-Point Integration (P2P)

The Requester/Performer Integration provides a means to exchange information within a closed loop eReferral / eConsult process where the Requester HCP and the Performer HCP work in separate systems, each with a separate record of the service being requested and performed.

Information exchange is supported by technical actors that align closely with the role of the user performing actions in a system to trigger the information exchange. Each actor contributes information to a notional or actual Service Record as the work to initiate the request and perform the service advances. Each actor is considered the definitive source for the information within their scope.

Technical Actors, Systems and Users

A basic P2P integration between a Source System and Target System to manage a referral with the relevant actors is illustrated below.

Role of Technical Actors

• eReC Requester: As an integration component of the system used by the Requester HCP, the eReC Requester uses eReC FHIR Messages to send service requests to Performing HCPs or delegates along with information needed to successfully triage and perform the requested service, including:

  • Patient Demographic and Identifying Info
  • Referring Practitioner Identifying Info
  • Requested Service
  • Referral Reason
  • Supporting Documentation

• eReC Performer: As an integration component of the system used by the Performer HCP, the eReC Performer uses eReC FHIR Messages to communicate acceptance of the referral and to share information as the work progresses including:

  • Referral Status
  • Appointment Info
  • Outcomes

Informer/Recipient Integration

The Informer/Recepient Integration provides a means for a system used to create and/or manage referrals to share information with other systems used by parties that participate in or need to be informed about service being requested and/or their status.

Technical Actors, Systems and Users

An example of Informer/Recipient integration is illustrated below:

Role of Technical Actors

• eReC Informer: As an integration component of a system used to create, manage, fulfill or store a Service Record, the eReC Informer uses eReC FHIR messages to notify interested parties / systems when a new Service Record is created, when content is added or changes, and when its state changes.

• eReC Recipient: As an integration component of a system used by an interested party, the eReC Recipient uses eReC FHIR messages to recieve notifications with information to maintain a copy of the Service Record. eRec Recipients may be a component of POS system used by an HCP participating in the request process or at the patient's medical home, shared EHR accessed by patient or provider portals, etc.

Example Architectures

Real-world solutions may build upon the basic integrations to provide more functional solutions for users. Below are illustrations of potential implementations that could serve as stand-alone solutions or be composed into larger networks.

Single, Shared RMS with Integrated POS Systems

The Informer/Recepient Integration provides a means for a shared RMS sytem used to create and/or manage referrals to share information with other systems used by parties that participate in or need to be informed about service being requested and/or their status.

Technical Actors, Systems and Users

An example of how Informer/Recipient integrations may be used by a Shared RMS to share referral information with POS systems used by a Requester HCP and Performer HCP is illustrated below:

Role of Technical Actors

• eReC Informer: As an integration component of a system used to create, manage, fulfill or store a Service Record, the eReC Informer uses eReC FHIR messages to notify interested parties / systems when a new Service Record is created, when content is added or changes, and when its state changes.

• eReC Recipient: As an integration component of a system used by an interested party, the eReC Recipient uses eReC FHIR messages to recieve notifications with information to maintain a copy of the Service Record. eRec Recipients may be a component of POS system used by an HCP participating in the request process or at the patient's medical home, shared EHR accessed by patient or provider portals, etc.

Point-to-Point integrations with Informers

Specialized systems participating in point to point integrations may be connected with POS systems that HCP use in their practices to provide a record of the referral in the patient's health record and/or to notify HCPs of information in the RMS that required action.

Technical Actors, Systems and Users

Requester HCP and Performer HCP work in two separate RMS systems and each also have a connected POS that they use to for record keeping and practice management. In this architecture, there may be many Source Systems and Target Systems with integrations with one another.

Role of Technical Actors

• eReC Requester: As an integration component of the RMS used by the Requester HCP, the eReC Requester uses eReC FHIR Messages to send service requests to the Performing HCP along with information needed to successfully triage and perform the requested service, including:

  • Patient Demographic and Identifying Info
  • Referring Practitioner Identifying Info
  • Requested Service
  • Referral Reason
  • Supporting Documentation

• eReC Performer: As an integration component of the RMS used by the Performer HCP, the eReC Performer uses eReC FHIR Messages to communicate acceptance of the referral by the Requester HCP and to share information as the work progresses including:

  • Referral Status
  • Appointment Info
  • Outcomes

• eReC Informer: As an integration component of both RMS Systems, the eReC Informer uses eReC FHIR messages to notify the eReC Recipients on Connected Systems when a new Service Record is created, when content is added or changes, and when its state changes.

• eReC Recipient: As an integration component on Connected Systems used by participants in the referral process, the eReC Recipient receives eReC FHIR messages containing information needed to maintain a copy of the Service Record.

Single Entry Model Integrations

Integrations that support Single Entry Models also build upon the basic messaging patterns to construct workflows that require users working within a Central System to receive service requests from Requester HCPs, perform actions within their scope and then direct referrals on to Performer HCPs.

Central Access & Triage (CAT)

In Alberta's CAT Model, a single, enterprise RMS will be integrated with POS systems that HCPs use at the point of care, where:

• a Central System (entrprise RMS) used by the CAT Team will be considered a shared source of truth for the referral record
• Source System will be the POS system used by the Requester HCP to initiate the referral process
• the Target System will be the POS system used by the Performer HCP to receive and accept referrals, book appointments, etc

Technical Actors, Systems and Users

The CAT architecture with the relevant actors is illustrated below. In this architecture, the Central RMS System will have integrations with many Source Systems and Target Systems where all are POS systems.

.

Role of Technical Actors

• Source System: eReC Requester: As an integration component of the POS System used by the Requester HCP, the eReC Requester uses eReC FHIR Messages to send service requests to Central Access and Triage along with information needed to successfully triage and perform the requested service, including:

  • Patient Demographic and Identifying Info
  • Referring Practitioner Identifying Info
  • Requested Service
  • Referral Reason
  • Supporting Documentation

• Central System: eReC Performer: As an integration component of the enterprise RMS used by the CAT Team, the eReC Performer uses eReC FHIR Message received to create a Service Record on the Enterprise RMS System. eReC Performer MAY communicate acceptance of the referral by CAT to the Requester HCP to share status updates as the work progresses.

• Central System: eReC Requester: As an integration component of the enterprise RMS used by the CAT Team, the eReC Requester uses eReC FHIR Messages to send service requests to the Performer HCP along with information needed to successfully perform the requested service. It also uses information received from the eReC Performer on the Target System to update the state and information of the Service Record.

• Target System: eReC Performer: As an integration component of the RMS used by the Performer HCP, the eReC Performer uses eReC FHIR Messages to communicate acceptance of the referral by the Performer HCP and to share information as the work progresses. including:

  • Referral Status
  • Appointment Info
  • Outcomes

• Central System: eReC Informer (Link): As an integration component of the enterprise RMS used by the CAT Team, the eReC Informer uses eReC FHIR messages to notify the eReC Recipients on the Source System when the Service Record is created within the RMS (with an enterprise identifier) as well as to send updates when content is added or changed to the service record or its state changes. The Link option MAY be used to associate the Service Record with the request received from eReC Requester.

• Source System: eReC Recipient (Link): As an integration component of the Source System the eReC Recipient receives eReC FHIR messages containing the current version of the Service Record and notification of changes. The Link option MAY be used to associate (or update/replace) request sent by eReC Requester with the Service Record received.

Central Intake in Point-to-Point

In Ontario, Central Intake services have been introduced to provide single points of access to high demand services within specific geographical areas within the province. Central Intake exists alongside Performer HCPs as destinations for referrals in a Point-to-Point architecture.

Technical Actors, Systems and Users

A Central Intake within an architecture with multiple RMS with the relevant actors is illustrated below. In this architecture, the Central System is one of many RMS Systems that the Source System and Target System have integrations with.

Role of Technical Actors

• Source System: eReC Requester: As an integration component of the RMS used by the Requester HCP, the eReC Requester uses eReC FHIR Messages to send service requests to Central Intake along with information needed to successfully triage and perform the requested service, including:

  • Patient Demographic and Identifying Info
  • Referring Practitioner Identifying Info
  • Requested Service
  • Referral Reason
  • Supporting Documentation

• Central System: eReC Performer: As an integration component of the RMS used by the Central Intake Team, the eReC Performer uses eReC FHIR Message received to create a Service Record within the RMS System. eReC Performer will communicate acceptance of the referral by the Central Intake team to the Requester HCP to share status updates as the work progresses.

• Central System: eReC Requester: As an integration component of the RMS used by the Central Intake Team, the eReC Requester uses eReC FHIR Messages to send service requests to the Performer HCP along with information needed to successfully perform the requested service. It also uses information received from the eReC Performer on the Target System to update the state and information of the Service Record.

• Target System: eReC Performer: As an integration component of the RMS used by the Performer HCP, the eReC Performer uses eReC FHIR Messages to communicate acceptance of the referral by the Performer HCP and to share information as the work progresses. including:

  • Referral Status
  • Appointment Info
  • Outcomes

• Central System: eReC Informer (Link): As an integration component of the RMS used by the Central Intake Team, the eReC Informer uses eReC FHIR messages to notify the eReC Recipient on the Source System when the Service Record is created on the RMS (with an identifier) as well as to send updates when content is added or changed to the service record or its state changes. The Link option MAY be used to associate the Service Record with the request received from eReC Requester.

• Source System: eReC Recipient (Link): As an integration component of the Source System the eReC Recipient receives eReC FHIR messages containing the current version of the Service Record and notification of changes. The Link option MAY be used to associate (or update/replace) request sent by eReC Requester with the Service Record received.

Actor Options

The table below lists the options that may be selected for each actor. Dependencies between options when applicable are specified in notes.

If no option is specified, the default capabilities are required for that actor. Otherwise, the capabilities for the specific option are required.

Note 1: L1, L2, L3 Options represent the maturity level of the Actor. Most procurements will require L3 support. To function in real-world environments, L2 and L3 systems SHOULD be designed to safely integrate with less mature systems.

Note 2: The Link Option is part of more complex flows, typically involving a Central System. eReC Informers that support the Link option are able to associate service requests / service records created and managed in the system with a service request received by eReC Performer actor when sending messages. See: Routing, Splitting, Chaining

Note 3: The Link Option is part of more complex flows, typically involving a Central System. eReC Recipients that support the Link option are able to associate service requests / service records created and managed in the Central System with the service request sent by eReC Requester actor when receiving messages. See: Routing, Splitting, Chaining

Actor Groupings

Grouped Actors are actors which are implemented together on a single system to provide more complex functionalities. For a grouping to occur, an actor from this profile (Column 1 - eReC Actor) shall implement all the required transactions and/or content modules in this profile in addition to all the transactions required for the grouped actor (Column 2 - Actor to be grouped with).

Note 1: Grouping an eReC Informer with an eReC Requester on a system provides the ability for the system to send a copy of a service record sent to an eReC Performer system as well as updates made in response to information received from an eReC Performer system to be shared with other interested parties and/or other systems used by a Requester HCP.

Note 2: Grouping an eReC Informer with an eReC Performer on a system provides the ability for the system to send a copy of a service record created or updated in response to information received from an eReC Receiver to be shared with other interested parties and/or other systems used by a Performer HCP.

Note 3: In systems used to support Central Intake and CAT business models, the eReC Requester may need to transmit service requests that have been created or reassigned by the Central Intake or CAT team to a Performer HCP(s) who work on another system(s).

Note 4: In systems used to support Central Intake and CAT business models, the eReC Informer (link) may be implemented to share information about and updates to service requests that have been created or reassigned by the Central Intake or CAT teams to a Requester HCP(s) that work on another system(s). The Link option relates to the ability for the system to associate service requests received by the eReC Performer to new requests created and managed within the system in messages sent by the eReC Informer. See: L3: Advanced Workflows

Note 5: Where Central Intake and CAT business models are in use, implementing an eReC Recipient (Link) with the eReC Requester on the system used by the Requester HCP provides a mechanism for the system to receive information about and updates to a service request that has been created or reassigned by the Central Intake or CAT teams. The Link option relates to the ability for the system to associate service requests received by the eReC Recipient with existing requests created and managed within the system. See: L3: Advanced Workflows

Note 5: Where this grouping exists, the system may receive two streams of updates related to a request sent from the system used by the Central Intake or CAT team:

• eReC Requester: will receive FHIR messages that provide notifications focused on services (Tasks) performed by the organization operating Central Intake or CAT with the purpose of conveying acceptance, completion, etc of the request received from the Requester HCP / eReC Requester.
• eReC Recipient: will receives notifications update to service record created and managed on the system used by the Central Intake or CAT team with the purpose of passing along information about downstream services requested from and performed by the Performer HCP.