Technical Specifications > Integration Patterns

Integration Patterns

This IG provides formal specifications for three integration approaches that serve as building blocks for integrations that support a broad range of different referral workflows and system capabilities.

Building Blocks

Direct Messaging

The Direct Messaging specified in this IG may be implemented to enable a bi-directional exchange of information about referral requests, appointments, referral related tasks and communications between two trusted systems using FHIR messaging.

A typical Direct Messaging integration will consist of:

  • a system configured as an RMS Source that is used to create referral requests, and
  • another system configured as an RMS Target that will be used to triage, plan, manage and/or fulfill the request.

Note: A system must be configured as both an RMS Source and an RMS Target when it interacts with other systems in both roles.

SMART Integration

The SMART integrations approach specified in this IG may be implemented to connect a software application that healthcare pratitioners or service providers use for managing patients to an RMS system (and associated referral network) used for creating and managing referral requests. In these integrations, the SMART App Launch Framework is used to establish a secure user interface level integration with shared context (both user and patient) between two software applications. A RESTful FHIR API connection in the background is used to share information.

A typical SMART integration will consist of:

  • a POS or RMS system that is configured as a SMART Server; and
  • an RMS system can be launched as a SMART App.

RESTful Interactions

The RESTful FHIR API approach specified in this IG may be implemented to support service discovery, and referral target recipient workflows between two systems using RESTful API.

A typical RESTful Interaction will consist of:

  • a system configured as a RESTful Client performs search and view operations related to service discovery, and determining the recipient of a referral
  • a system configured as a RESTful server processes query requests from the client, and provides a response

Workflow Support

Several common integration patterns build upon the three integrations specified above to support a variety of different workflows. These are illustrated below and are discussed in more detail on a page focused on workflow support:

POS launches RMS Source

When configured as a SMART Server, a POS can launch an RMS SMART App with Direct Messaging to provide its users with access to the specialized functionality of an RMS to create electronic referrals to a broad range of specialists and healthcare service providers accross the province.

Note: For some referrals, the RMS Source and RMS Target are the same, in which case the FHIR messaging step may not apply.

POS receives information via Direct Messaging

When configured to receive information via a Direct Messaging endpoint, a point of service system can receive notifications about referrals and/or appointments from an RMS (Source or Target) for inclusion in a patient's chart, to initiate workflow or for other purposes.

POS launches RMS Source and receives information via Messaging

When configured as a SMART Server and to receive information via a Direct Messaging endpoint, a POS can launch an RMS SMART App with Direct Messaging to provide its users with access to the specialized functionality of an RMS to create electronic referrals and receive notifications about the referral for inclusion in a patient's chart, to initiate workflow or for other purposes.

RMS Source launches RMS Target

When configured as a SMART Server with Direct Messaging, an RMS SMART App can launch other RMS SMART Apps to provide its users with access to intake forms and functionality offered by RMS systems used by other service providers to assist in the creation of requests that are then managed locally.

(Although not shown, Direct Messaging to the POS is an option as in the prior case.)

Chained API integrations

RMS systems used at a central intake or assessment centre may generate subsequent referral requests and send them on to specialists or service providers that use different RMS systems.

RMS GETs information using RESTful interactions and exchanges event-related information using Direct Messaging

RMS Systems may use a combination of RESTful Interactions and Direct Messaging to create and exchange information about a request. For example an RMS may:

  • query a RESTful FHIR API on an RMS Target for service discovery or a POS (SMART Server) to retrieve patient information, then
  • use Direct Messaging to submit a request to an RMS Target for completion