BusinessContext > Business Rules

Business rules

The following business rules highlight some key business process in this implementation guide. More technical details on some of these items and others can be found in the Direct Messaging Specification, SMART Integration Specification and FHIR Artifacts.

Messaging Paradigm

This implementation guide is primarily based on a FHIR messaging paradigm that supports Direct Messaging Integrations.

Current implementations MAY support the RESTful paradigm in one or both of two contexts:

1. To retrieve information from a FHIR Server as part of a SMART Integration, minimally to GET Patient and Practitioner context information
2. To GET current information about ServiceRequest

It is expected that more RESTful operations will be added be included in future revisions to this implementation guide.

Future Iterations

This implementation guide will continue to evolve.

Requested features, changes and fixes are listed in the Future Development section of this IG. Furthermore, some currently excluded FHIR profile elements may be included in future revisions to FHIR Artifacts.

Responsibility for Updating a ServiceRequest

The RMS Target is responsible for processing a referral after submission.

RMS Targets are responsible for updating and progressing the status and data of a submitted ServiceRequest by sending updates to a "process-request" Task. The flow of information of the lifecycle of a ServiceRequest is illustrated the Direct Messaging specification

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 and its status is not straightforward. Consider the following:

• the RMS Source creates and maintains the ServiceRequest resource used to transmit a referral request to the RMS Target
• the RMS Target creates and maintains "Process Request" Task used to transmit any updates to the referral request back to the RMS Source (this includes outcomes of the referral including any Appointments, care plans or ServiceRequests its users create)
• in a Direct Messaging integration, the RMS Source creates the referral (a ServiceRequest) and is clearly the source of truth prior to its submission to the RMS Target
• in a SMART Integration where an RMS Source launches an RMS Target "app" to help create a referral, the referral isn't necessarily created in the RMS Source until it has been submitted in the RMS Target and information has been relayed back to the RMS Source via Direct Messaging
• in either case, the RMS Target is responsible for updating the referral status after submission (by updating the status of the "Process Request" Task and sending along Communications, Appointments, etc...)
• status updates at the RMS Target are sent to the RMS Source as notifications without a strict requirement for processing by the RMS Source - which therefore might not reflect the current status of the referral
• The RMS Source and RMS Target may have different capabilities for handling certain resources associated with a referral (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

RMS Target SHALL Remove PHI 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

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, ServiceRequest.basedOn SHALL be used to associate the new referral(s) with the original referral it is based on.

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

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

See Branching and Chaining Requests for implementation details.

Provenance

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 implementation guide, 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 implementation guide. 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.
• 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 and data registries may interact with eReferrals

While this document focusses on the interaction between RMS Sources, RMS Targets and POS systems other 3rd party systems may interact with the eReferral workflow in this implementation guide as well.

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 MessageHeader.author

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 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 provincial eReferral IG, it could develop additional profile(s) to supplement the provincial eReferral implementation guide, and work with the governance body to add the new requirements into the provincial eReferral implementation guide 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-servicerequest event) 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 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

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 implementation guide 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 implementation guide.

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 message (event: add-servicerequest). 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-servicerequest 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 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.