BusinessContext > 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.
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.
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.
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 (SMART on FHIR) |
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 |
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.
The overall workflow of this implementation guide is as follows:
Select Target HealthcareService: (out of scope) The RMS Source selects a target HealthcareService (out of the scope of this specification).
Submit Referral: The source system submits the referral to the target system, via following ways:
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.
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).
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.
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.
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:
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.
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.
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.
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.
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:
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 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:
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)
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):
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:
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.
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:
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.
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.
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.
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).
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.
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
Some other fields are optionally the same depending on the use case. For example:
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.
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:
A service directory would also be required to specify what codes are available for a given HealthcareService or PractitionerRole.
Powered by SIMPLIFIER.NET