BusinessContext > Business Rules

Business rules

The following business rules highlights some key business process in this implementation guide. More technical details on some of these items and others can be found in Profiles & Operations and eReferral Workflow sections.

Messaging Paradigm

This specification uses a FHIR messaging paradigm for direct API Integration.

All functions of this implementation guide can be accomplished via messaging.

The only RESTful paradigm operation available at this time is GET ServiceRequest. It is expected that more RESTful paradigm operations will be added in the future releases of this implementation guide.

Future Iterations

This implementation guide will continue to evolve.

Upcoming features, changes and fixes are listed in the Future Development section of this implementation guide. Furthermore, some currently excluded profile elements (in the "Profiles & Operations section) may be included in future revisions.

Multiple Referral Submission Methods

The RMS Source chooses one (or both) methods to send or receive a referral

This impementation guide describes the following referral submission methods:

  • Submit Referral Method 1 - SMART on FHIR: an app-assisted eReferral for handling referral submission flows.

  • Submit Referral Method 2 - Direct API Integration: for direct API submission based eReferral.

The following table describes the differences between the SMART on FHIR and direct API submission methods.

Criteria Submit Referral Method 1
Submit Referral Method 2
(Direct API Submission)
Objective Enable the RMS Target to seamlessly define its own flexible custom referral business logic/UI independent of the RMS Source Enable back-end API oriented eReferral processes, where the eReferral business logic/UI is handled by the RMS Source
Process See SMART on FHIR Documentation page for the essentials of the SMART on FHIR process.
In Method 1 SMART on FHIR the RMS Source sends referral + authentication data to an endpoint which holds the referral data on a FHIR server and returns an authenticated LaunchString

The LauchString is then used by the RMS Source to open an authenticated eReferral app hosted by the the RMS Target, which displays a UI (e.g., booking page and custom referral form) that guides the user through the process of submitting a referral, and any relevant information is prepopulated with the data sent at the start of this process
The RMS Source submits a referral payload directly to the RMS target via backend API mechanisms.
All UI must be handled by the RMS Source
Presentation of UI by RMS Target by RMS Source
Functionality The full referral submission business logic is handled by RMS Target The full referral submission business logic is handled by the RMS Source, referral submission business may need to be synchronized between RMS Source and RMS Target (e.g., referral form configuration)
Making Changes to Business Logic Handled exclusively at RMS Target, no logic synchronization required between RMS Source & RMS Target May require collaboration & synchronization between RMS Source and RMS Target
Ease of Implementation for RMS Source Once implemented, compatible with all RMS Targets using this method, no matter the eReferral business process. Must build the eReferral interface, may need to collaborate with RMS Target
Ease of Implementation for RMS Target The full eReferral workflow is assumed by the RMS Target Easy to implement the base functionality, may become more difficult as business logic & integrations increase in scale and complexity
Submission Time The referral is considered submitted when the user completes the referral process within the app (usually by clicking a "submit" button).
If the app is launched from the RMS Source, but the referral is never submitted within the UI, then the RMS Target discards the referral
Proper business logic needs to be implemented and HTTP response code will be returned.
Submission Initiation Event notify-add-service-request is used to notify the RMS Source add-service-request

Referral data

Some referral processes may only needed a limited subset of the data that is submitted in a ServiceRequest. For example, when signing up for a "Seniors Community Board Games Night" service, advanced clinical information is not required. When the SMART on FHIR app is presented for eReferrals to a "Seniors Community Board Games Afternoon", it might only ask for name, phone number and address in its form but does not request any other clinical or contact information. If additional information was submitted in API POST step of the process, to respect patient privacy the RMS Target should keep only the data points that were asked for, and discard the remainder.

To be FHIR compliant all the elements marked as ‘Must Support’ must be included in the payload. Refer to Conformance Rules section of the implementation guide.

Referral Workflow

The overall workflow of this implementation guide is as follows:

  1. Select Target HealthcareService: (out of scope) The RMS Source selects a target HealthcareService (out of the scope of this specification).

  2. Submit Referral: The source system submits the referral to the target system, via following ways:

    • Method 1: SMART on FHIR
    • Method 2: Direct API submission
  3. Update Referral: Once submitted, the RMS Target is responsible for progressing the workflow of the referral, such as updating statuses and adding appointments. The RMS Target system sends notification messages back to the RMS Source (and any other interested systems) as the referral changes.

  4. Communicate about Referral: Both the source and target system can send communication messages about the referral back and forth to each other (e.g., request for more information).

  5. Revoke Referral: If necessary to revoke a referral, the RMS Source system can send a message to the RMS Target system commanding that the referral be revoked.

The workflow is discussed in more detail on the eReferral Workflow page.

Responsibility for Updating a ServiceRequest

The RMS Target is responsible for updating a referral after submission

RMS Targets are responsible for updating and progressing the status and data of a submitted ServiceRequest. For example, the RMS Target (not the RMS Source) would set the referral status as "Completed", or additional notes and attachments may be added to the referral as it is progressed. As these updates are made, the RMS Source can be notified of these changes.

Any updates (other than a revoke) that the RMS Source wants to make to the referral must be done via the "Communication" process, which can include ad-hoc messages and attachments.

Source of Truth

Defining the single "Source of Truth" for a referral will be deferred pending further discussion

Determining the single "Source of Truth" regarding a referral is not necessarily straight forward. Consider the following:

  • For Submission Method 2 Direct API Submission, the RMS Source creates the submitted version of the referral, and has the source of truth pre-submission
  • For Submission Method 1 (SMART on FHIR), the RMS source does not necessarily create a referral until it is submitted in the eReferral app and information is relayed back to the RMS Source
  • The RMS Target is responsible for updating a referral after submission (e.g., completion status, adding notes, etc...)
  • Updates at the RMS Target are relayed back to the RMS Source
  • The RMS Source and RMS Target may have different capabilities for handling certain resources. For example, a RMS Source may not be able to fully process an appointment resource provided by a RMS Target and convert it into a simpler format for presentation to its uses.

Considering these points, the community developing this spec has yet to come to agreement on where the single "Source of Truth" of the referral lies (or if there is just one), and remains undecided.

Receiving Referral Updates

RMS Sources must be trusted by RMS Target to receive referral updates from the RMS Target

For an RMS Source to receive an update about referral it has submitted to an RMS Target, the RMS Source must be pre-authorized and authenticated via some type of trust mechanism with the RMS Target.

Revoking Referrals

Remove PHI at RMS Target when a referral is revoked

In the rare cases when a patient removes previously granted consent for the referral to be transmitted or viewed by the target user, the referral is revoked. Revoke can be initiated from either the RMS Source of RMS Target.

In this case, the RMS Target must deny the recipient user of the referral further access to this referral's personal health information.

The RMS Target can decide within its process and legislative framework whether this also requires deletion of the PHI data on its system.

Chaining & Branching Referrals

Chain & Branch Referrals with the ServiceRequest.basedOn element is not in the scope of this implementation guide

For referral processes that generate more referrals (e.g., central intake, service navigation, etc...), the new "child" referral can have a connected "parent" referral, via the ServiceRequest.basedOn element.


RMS Systems Manage Provenance Internally

This implementation guide does not include a mechanism for deep provenance handling. It is the responsibility of the RMS systems to manage their related provenance appropriately.

Referral Status

Track Referral Status with the Task Resource

When there are tasks to be completed in association with the referral process, use the Task resource to track and communicate the progress of that activity.

Important Note: "Process Request" is required for processing the status of referrals. However, the other task codes described are in their early conceptual phase and are not yet fully detailed in this iGuide, but will be included with more detail in a future version.

Each task has a code that indicates some common referral related tasks as follows:

  • Process Request - Due to limitations with the FHIR ServiceRequest.status field, the Task resource is used to track the status of a ServiceRequest. Task.status tracks the overall status of the referral (draft | requested | received | accepted | etc...). Referral targets may also have their own custom statuses as defined by their internal process flow (e.g., waiting for manager approval), which can be communicated via Task.businessStatus.text, or use one of the common values in the extensible codeset published with this iGuide. A task with this code MUST be added to every referral by the target system on receipt of the referral. The task is updated by the provider, and the updates are communicated to the requester in the notify-update-status message or notify-update-service-request.
  • RFI - This task is used to communicate that a "Request for Information" has been issued to the referral requester (from the referral provider). The status of the task updated by the requested, and sent back to the provider with a communication.
  • Data Correction - Sometimes a requester sends out-of-date patient information to a provider. The provider may have more accurate information and wish to provide it back to the requester advising them to update their own data set. This task can be created by the provider but would be updated and completed by the requester, who would then send the task back to the provider to inform them that the task was complete.
  • General - A "General" task is an ad-hoc task whose meaning is specified as text in in Task.description (e.g., "Contact supervisor for final approval").

Note that when processing a task, it is the responsibility of the system that performs the task to update its status, and communicate that change back to the other party.

3rd Party Systems

3rd Party Systems such as patient portals, data registries, EMRs may interact with eReferrals

While this document focusses on the interaction between RMS Sources & RMS Targets, other 3rd party systems may interact with the eReferral workflow in this implementation guide as well (patient portals, data registries, EMRs, etc...).

Some potential interactions could include:

  • Receiving notifications about new or modified referrals to a regional central registry
  • Sending Communications to the RMS Target from a 3rd party Provider Portal regarding a referral
  • Patients revoking consent to their referral via a patient portal

The 3rd party system would have to be registered with the RMS Target, with appropriate scopes, authorization and authentication mechanisms in place to ensure only appropriate players can interact via the API (e.g., the patient associated with a referral, via a patient portal)

Duplicate Data in FHIR Resources

One characteristic that implementers often find unintuitive about FHIR is that the same data is often duplicate among multiple resources, rather than be normalized. For example, the Patient is referenced from ServiceRequest and Task and Appointment resources, which may all be included in the same bundle. This is because FHIR is designed as a data exchange format and not a data storage format. When designing exchange formats, you almost always end up choosing robustness and stability (i.e., redundant data) over efficiency.

Learn more about using FHIR as a data storage format here .

When there are redundant fields that represent duplicate data, it is expected that the data would be the same. This specification does not specify where priority is when redundant data fields differ, it is recommended to reject the payload in its entirety. Some examples where data is expected to match include (but are not limited to):

  • Patient across ServiceRequest, Task, Appointment, Communication, DocumentReference
  • ServiceRequest across Task, Communication, Appointment
  • PractitionerRole across Service, ServiceRequest.requester and

Handling Clinical Resources & Un-profiled Data Elements

The initial focus of this implementation guide is on the workflow of eReferral, rather than clinical data associated with eReferrals (e.g., Medication/ Allergies, Observation resources). The intention is that the clinical resources will be profiled in the future releases of eReferral implementation guide. In the interim, if there is a need for implementers to profile specific clinical resources the expectation is to collaborate and contribute those profiles to this implementation guide for broad use.

Otherwise, there are four options for handling data elements that are not mapped to an existing or newly developed profile:

  • Convert into a human-readable text format and included in the ServiceRequest.note annotation element.
  • Include the data in a QuestionnaireResponse resource, which will be included in the initial referral submission bundle, where QuestionnaireResponse.basedOn points to the referral.
  • Include the data in a DocumentReference resource.
  • Include the data in a Communication resource.

A specific FHIR implementation can be conformant with more than one iGuide. If a project requires net new resources that do not exist in this provincial eReferral iGuide, it could develop additional profile(s) to supplement the provincial eReferral iGuide, and work with the governance body to add the new requirements into the provincial eReferral iGuide if there is a general applicability to the eReferral ecosystem.

Routing Options (Extension)

Some referral processes may ask the referrer to provide some data that impacts the receiver's automated referral processing rules. The rules for how a receiver processes their referrals can be unique to the receiver. Some examples include routing based on:

  • The type of referrer (from the hospital, primary care, out of province, etc...)
  • The patient's Postal Code FSA (e.g., K8N, L0L, etc...)
  • The first letter of the patient's last name (e.g., A-J, K-Z)

To handle this, use the Routing Options extension , which is included in both the ServiceRequest AND MessageHeader (for add-service-request) resources. By also including the extension in the MessageHeader, it makes it easier for implementers to find the key routing-related data fields without needing to dig further into the referral payload.

Future Development: When the eReferral process is combined with a service directory, the directory must be able to publish the valueSet of referral options that are available for a selected service.

Gender, Birth Sex & Gender Identity

Patient.gender is to be used to specify the observed patient gender at the time of the referral (regardless of the gender presentation at birth). This is also referred to as "administrative gender", which is the gender that the patient is considered to have for administration and record keeping purposes. This property is often used as an input to patient matching algorithms.

Due to its importance in patient matching algorithms, gender is a mandatory element. In the case where a referral does not need to know gender, set "Patient.gender" = "unknown"

Note that the FHIR Patient resource documentation discusses patient.gender in depth.

Regarding more detailed tracking of gender identity there are ongoing discussions in the standards community, this implementation guide is waiting on a community consensus. If more detailed gender values are required, an implementer may consider using the FHIR patient-genderIdentity extension. To specify birth sex, consider using the US Core birthSex extension or the CIHI IRRS FHIR Implementation Guide.

Patient Present Location (Extension)

Sometimes a referral needs to communicate where the patient is at the time of the referral (e.g., in Ward X of Hospital Y), which may be different from the patient's home address. To communicate this, use the PatientPresentLocation extension, which references a Location resource.

Present location can be nested using Location.partOf to communicate locations with multiple levels, e.g., Location.partOf > Location for WardX > HospitalY.

Request Authorizer vs. Submitter

Sometimes the person who authorizes a referral can be different from the person who submits it (e.g., a hospital physician authorizes a referral that is submitted by a discharge planner). In this scenario: the referral authorizer is captured by ServiceRequest.requester, and may also be mapped onto when submitting the referral. the referral submitter is captured by MessageHeader.sender, which upon message receipt is then mapped by the receiving system onto Task.requester.

For subsequent messages in the referral lifecycle (e.g., adding an appointment, updating the status, etc..), the will continue to be used to indicate the authorizer, and MessageHeader.sender will indicate who sent it.

In the case where authorizer and submitter are the same, only is needed (MessageHeader.sender can be omitted).

Patient Self Referral

To indicate that a referral is a self-referral initiated by the patient, make the ServiceRequest.requester element reference the same Patient resource as is referenced in ServiceRequest.subject.

Note: This version of the iGuide only supports the above mentioned behavior, the detailed business rules will be included in the future release. It is not necessarily expected to be supported by the implementers of this iGuide.

Requisitons/Multiple Connected Referrals

When multiple connected referrals are made simultaneously (e.g., 3 home care services after discharge from hospital to home, multiple lab tests such as blood work and urinalysis in a single requisition, etc...), they can all be submitted in the same add-service-request. This is known as a "requisition" (in ServiceRequest resource). There is some special handling to consider for requisitions.

REQUISITION IDENTIFIER: Each service request in the add-service-request message will be connected via the "ServiceRequest.requisition" element with a common identifier. The requisition identifier must be included in all future/subsequent MessageHeaders related to this referral, in the ReferralIdentifier extension .

COMMON DATA: Note that it is expected that duplicate common elements would have common values, e.g., all service requests should

  • have the same patient
  • have the same submitter,
  • have a target ServiceRequest performer pointing to a HealthcareService (or ProviderRole) from a single organization

Some other fields are optionally the same depending on the use case. For example:

  • Reason for referral (i.e., reasonCode.text) may be duplicated among all related referrals or may differ.

COMMUNICATIONS: If there is a communication that is related to the entire requisition, the communication should have Communication.basedOn reference all of the service requests within the requisition.

Specifying a Service

Although this Implementation Guide does not profile a health service directory or provider registry, a directory/registry of some sort would need to provide a reference value for ServiceRequest.performer element, which specifies the service requested.

Every referral must specify a target service via ServiceRequest.performer, pointing to either a HealthcareService or PractitionerRole. This is typically shared as a reference to an externally hosted URL, which uniquely identifies this service. The meaning of this URL should be known by the RMS target, as a service that it can process an eReferral for.

In addition, ServiceRequest.code can be used to further define a specific procedure under a service. For example:

  • performer = Orthopaedic Surgeon, code=Knee Surgery
  • performer = Meals on Wheels, code = Frozen Meals

A service directory would also be required to specify what codes are available for a given HealthcareService or PractitionerRole.