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 CA:eReC Messaging as well as throughout the FHIR Artifacts.

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.

There are various integration methods that provide support for additional interactions in the eReferral/eConsult workflow (e.g., RESTful FHIR API calls to a Service Directory, launching applications to generate and populate referral forms using SMART on FHIR protocol). This guidance on SMART-Integration and RESTful Paradigm will eventually be included and expanded on future versions of the guide.

Messaging Exchange Paradigm

ServiceRequest transmission and handling is primarily implemented using the FHIR messaging paradigm. In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens (this is essentially a "webhook"). Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request. In a messaging paradigm, an event will trigger a full set of relevant information.

More details about messaging and the events used in this iGuide are detailed on the CA:eReC Messaging page.

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, eReC Source, eReC Target, 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 eReC Sources, eReC Targets 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 eReC 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 eReC Source or eReC Target, 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 CA:eReC 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 that do not exist in this pan-Canadian eReferral-eConsult iGuide, it could develop additional profile(s) to supplement this implementation guide, and 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 eReC Source system whereas in a scenario where an appointment is booked the 'source of truth' would be the eReC 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 eReC Source is responsible for the contents of the ServiceRequest. A requester at the eReC Source creates the ServiceRequest and is responsible for its content. Thus, the Service request should not generally be modified by the eReC Target
  • If the eReC Source makes a modification to a ServiceRequest, it should notify the eReC Target
  • The eReC Target is responsible for processing the ServiceRequest (with a process-request Task) A provider at the eReC Target 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 eReC Target updates the Task (and related resources), it should notify the eReC Source
  • If the eReC Target wishes to modify the ServiceRequest (e.g., fix client's phone number), it should send a "notify-data-correction" message to the eReC Source

Receiving Referral Updates

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

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

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 eReC Source.

When a patient withdraws their consent, those directives will apply to future referrals.

This implementation guide does not currently include a mechanism/requirements for exchanging consent resources. It is the responsibility of the eReC Source 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 eReC Source 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 eReC Source (requester) to change the status of a ServiceRequest as deemed appropriate. For example, the requester could set the ServiceRequest.status as 'completed' if they are satisfied that the ServiceRequest has been processed.

Status updates by the eReC Source are communicate to the eReC Target using ServiceRequest Bundle Events.

To track the overall status of the ServiceRequest processing, the eReC Source 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 eReC Target are communicated to the eReC Source 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.

Note: As the content continues to evolve around Routing/Splitting/Chaining eReferrals, we will continue to update this iGuide and its content accordingly. For additional information on this content please refer to CA:eReC Central Intake.

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. For additional information on this content please refer to CA:eReC Central Intake.
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 eReC 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 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.

Extensions

Business rules and context describing the extensions used by this guide have been moved to the

Command 'pagelink' could not render: Page not found.
page.

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 CA:eReC 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.