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

Business Rules

The following business rules highlight some key business processes in this implementation guide. More technical details on some of these items and others can be found in the Messaging as well as throughout the Resource Profiles

Exchange Paradigms

The current version of this guide is focused on the exchange of the electronic referral/consult payload using the FHIR Messaging Exchange Paradigm.

Messaging Exchange Paradigm

Transmission of eReferral and eConsult service requests, status updates, appointments and communications is provided by FHIR messaging. Details about messaging and the events used in this iGuide are detailed on the Messaging page.

REST and SMART Paradigms

Existing eReferral / eConsult solutions may depend on FHIR related exchange paradigms that are currently beyond the scope of this specification to support workflow, including:

  • RESTful FHIR API calls to retrieve information from Service Directories
  • SMART on FHIR to launch RMS applications from POS systems to intitiate and/or manage referrals.

Use Case, Technical, and Real-World System Actors

This guide utilizes Use Case Actors and Technical Actors to describe how electronic referrals and consults are transacted between parties. Real-world systems like and EMR, HIS, or Referral Management Systems may be grouped under actor roles such as Requester, Source System, Target System, and/or Performer based on their current configuration.

If further business rules responsibilities are identified that are applicable under the context of the real-world system (e.g., applicable solely to referral management systems) these will be called out in the guide.

There are additional types of systems, that are not currently defined actors, that may be involved in eReferral and eConsult workflows (e.g., 3rd Party Systems).

While this document focuses on the interaction between Source Systems, Target Systems and POS systems, other 3rd party systems (such as patient portal or data registries) may interact with the eReferral workflow in this implementation guide as well. Some potential interactions could include:

  • Sending notifications about new or modified referrals to a regional referral registry or repository
  • Sending Communications to the Target system 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 Source System or Target System, with appropriate scopes, authorization and authentication mechanisms in place to ensure that appropriate systems can access the API or receive messages with appropriate controls.

More details about actors can be found on the Messaging page.

Business Rules Related to Handling FHIR Content

Duplicative/Repetitive Data in FHIR Resources

One characteristic that implementers often find unintuitive about FHIR is that the same data is often duplicated/repeated 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.

When there are redundant fields that represent duplicate/repetitive 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 MessageHeader.author

Handing 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 that they collaborate with the FHIR Implementers community and contribute the profiles to this implementation guide for broad use.

In the meantime, 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 FHIR implementation guide.

If a project requires net new resources, it should confirm with the governance body that these cannot be supported within the existing pan-Canadian eReferral-eConsult iGuide and then develop additional profile(s) to supplement this implementation guide. They should work with the governance body to add the new requirements into the pan-Canadian eReferral-eConsult iGuide if there is a general applicability to the eReferral ecosystem.

Business Rules for Referrals that Impact Data & Behaviour Requirements

Source of Truth and System Responsibilities

The "source of truth" is dependent on the implementation scenario. For example when a referral is created, the 'source of truth' would be the Source system whereas in a scenario where an appointment is booked the 'source of truth' would be the Target system.

The Referral Management System is intended to support exchange of data between the source and the target. It’s a bidirectional flow of data from one system to the other. This does not refer to which health information custodian or an agent acting on behalf of the health information custodian has the (most) accurate information.

Any correction and updates to the original referral would be submitted as an update to that referral and the original referral will not be altered or over-written in any way.

Determining the single "Source of Truth" regarding a referral and its status is not straightforward. Consider the following:

  • The Source System is responsible for the contents of the ServiceRequest. A requester at the Source System creates the ServiceRequest and is responsible for its content. Thus, the Service request should not generally be modified by the Target System
  • If the Source System makes a modification to a ServiceRequest, it should notify the Target System
  • The Target System is responsible for processing the ServiceRequest (with a process-request Task). A provider at the Target System receives a ServiceRequest, creates a Task resource (i.e., "process-request") to progress the referral through its workflow. This includes setting outcomes of the referral, adding appointments, care plans, communications, or even creating additional ServiceRequest(s) its users create)
  • As the Target System updates the Task (and related resources), it should notify the Source System
  • If the Target System wishes to modify the ServiceRequest (e.g., fix client's phone number), it should send a "notify-data-correction" message to the Source System

Receiving Referral Updates

Source Systems must be trusted by Target System to receive referral updates from the Target System.

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

Future versions of this guide may expand the guidance on authorization/authentication further.

Revoking Referral

In the rare cases when a patient no longer wishes to be referred and removes previously granted consent for the referral to be transmitted or viewed by the target user, the status of the referral reflects that it is revoked. Revoke can be initiated from the Source System.

This implementation guide does not currently include a mechanism/requirements for exchanging consent resources. It is the responsibility of the Source Systems and Target Systems to manage their consents appropriately until/unless further requirements for conveying consent information are defined.

Provenance

This implementation guide does not currently include a mechanism for deep provenance handling. It is the responsibility of the Source Systems and Target Systems to manage their related provenance appropriately until/unless further requirements for conveying provenance information are defined.

Referral Status

From the perspective of a Requester, the status of a ServiceRequest is tracked using ServiceRequest.status element. It's the responsibility of the Source System (requester) to change the status of a ServiceRequest as deemed appropriate. For example, the Target System could inform the Source System via a Task that the referral has been completed and the Source System would change the ServiceRequest.status to 'completed'.

Status updates by the Source System are communicated to the Target System using ServiceRequest Bundle Events.

To track the overall status of the ServiceRequest processing, the Source System uses the process-request Task.status (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 implementation guide.

Updates by the Target System are communicated to the Source System using the Task Bundle Events.

Routing, Splitting and Chaining Referrals

For referral processes that generate more referrals (e.g., central intake, assessment centres, service navigation, etc.), the new "child" referrals will have a connected "parent" referral.

In these cases, multiple messages will often be needed to:

  • forward the new referral request(s),
  • notify the requester that new referral request(s) were created in response to the original, and potentially to
  • notify other systems of the existence of the new requests.

To avoid unnecessary complexity when exchanging eReferrals and related information using eReC Messaging, a few design constraints exist or are proposed:

  1. Downstream and upstream non-neighbour systems are not expected to communicate with one another directly:
    1. eReC messaging SHALL always be with the nearest neighbour/system
    2. an eReC system that receives information about an eReferral SHALL also transmit those information updates between its integration partners
    3. an eReC system SHALL only see their nearest upstream and downstream neighbours/systems, the existence of other upstream and downstream systems SHALL be invisible
  2. Receivers SHALL NOT make updates to a ServiceRequest received:
    1. status updates to a ServiceRequest received SHALL always be conveyed to other systems using a Task (process-request) resource .basedOn the ServiceRequest
    2. a receiver MAY create child ServiceRequests in response to a request received when work is reassigned, delegated or distributed to others
      1. A business identifier shared between a parent and child SHALL not be changed once set.
      2. When a child ServiceRequest is created as a result of Splitting/Routing, it is indicated by referencing the parent referral in the .replaces element.
      3. When a child ServiceRequest is created as a result of Chaining, , it is indicated by referencing the parent referral in the.basedOn element.
    3. a receiver that transmits child ServiceRequests to others SHOULD have the ability to transmit back all information the requester would otherwise expect from the receiver
      1. an eReC system that transmits information about a child ServiceRequest SHALL include the parent ServiceRequest's information in all messages that reference the child
      2. this does not preclude senders and receivers from agreeing to exchange messages that transmit status updates, appointments, etc. referencing the parent ServiceRequest instead of the child where it is a better fit to requester system capabilities or business requirements
      3. an eReC system that transmits information about a child ServiceRequests SHALL use the appropriate message event codes to communicate information back to sender (e.g.: add-appointment when transmitting information about an appointment that has been scheduled)
  3. Receivers SHOULD only share information about child ServiceRequests created to support referral routing, chaining or splitting when the requester of the initial request needs to know about the requested downstream services or related events and information.
  4. The MessageHeader.focus element in FHIR messages SHALL contain references to the ServiceRequest(s), Task, Appointment or Communication that was added or changed as a result of the business event that triggered the message.
    1. When Appointments and Communications are exchanged, they SHALL be in MessageHeader.focus and .basedOn the appropriate child ServiceRequest.
  5. In scenarios where there is a combination of routing/splitting AND chaining
    1. The same referral cannot both route/split and chain within the same hop, it must be sequenced.
    2. A replacing action cannot also be basedOn.

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 MessageHeader.author 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 MessageHeader.author 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 MessageHeader.author is needed (MessageHeader.sender can be omitted).

Patient Self-Referral

This section has been temporarily removed until the use case and guidance can be further fleshed out in future releases.

Requisition/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 message (event: add-service-request). This is known as a "requisition" (in the ServiceRequest resource). There is some special handling to consider for requisitions.

Requisition Identifier

Each service request in the add-service-request message will have a common identifier in the "ServiceRequest.requisition" element. The requisition identifier must be included in all future/subsequent MessageHeaders related to this referral, using 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 HealthcareService1 (or PractitionerRole) 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

Every referral must specify a target service via ServiceRequest.performer, pointing to either a HealthcareService1 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 Target System, 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 HealthcareService1 or PractitionerRole.

eConsult Business Events

Guidance related to managing eConsult Business Events has been moved to an independent page to assist with easier navigation of content that is specific to use case(s) that not some implementers may not incorporate into their workflows. Implementers participating in eConsult Use Cases should refer to eConsult Business Events for more details on eConsult business context and rules.

HealthcareService Business Rules

1Note: The Ontario eServices v0.11.1 Guide describes a variety of business rules that apply to implementers of HealthcareService within a Service Directory. The current version of this guide focuses on the exchange of the referral payload through the Messaging . Future releases may expand the guidance related to hosting and calling endpoints for HealthcareService information (either as a section in this guide or through a separate guide). In the meantime, implementers in need of further guidance on the HealthcareService characteristics and design practices should refer to the HealthcareService Directories Section under the Business Rules page the Ontario eServices v0.11.1 Guide.