eReferral Analytics Repository
Background
The purpose of the CWM eReferral Repository is to support health systems planning;and, to develop and provide digital solutions which provides full visibility to and supports patients and caregivers through their entire health system journey.
Improve the provider experience through equitable and seamless access to health data and information to better support their patients and caregiver.
Develop and implement a Central Waitlist Management advisory structure to provide oversight and support key initiatives.
Create systemic navigational structures to provide coordinated patient flow through the surgical pathway.
To support an integrated approach to understanding a patient’s journey andincludes data from all eReferrals.
Overview
eReferral Repository is a specialized analytics data store for referral information.
The eReferral Repository is a recipient system that relies on other systems (typically a referral management system) to contribute referral data (in the case of CWM in near real time), in response to business events that take place over the lifecycle of the referral.
Contribution to the eReferral Repository is unidirectional and it is implemented typically with only one referral system that is responsible for covering all referral interactions between referral author and recipient.
The data sent to the eReferral Repository could be a subset of the original referral document (eReferral MDS). Therefore, supporting information will not be sent to the eReferral Repository by the Referral Event Contributor.
Note: The Referral Event Contributor is an RMS (typically an RMS Source) that sends snapshots of current information about a referral to a repository in response to business events that take place throughout the lifespan of the referral
Actors
The eReferral Repository use case actors are depicted above as follows:
Human Actors:
- Referral Author – a primary care provider (PCP) or other clinician that initiates the referral cycle and authors the referral request (“eReferral Document”) conveyed to the Referral Performer.
- Referral Performer – a clinician, administrator in central intake, etc. who receives the eReferral Document through electronic means and is expected to act upon the receipt of such document.
- System Planners/Decision Support – designates actors that interact with the repository data in an aggregated form. These actors do not participate clinical referral workflow but consume the referral data for care planning purposes.
System Actors:
- Referral Source System (RMS Source, Referral Event Contributor) – a technical actor – represents the system that initiates the referral workflow and tracks information about status updates, booked appointments and outcomes throughout the lifespan of the referral until completion.
- Referral Target System (RMS Target) – a technical actor – represents a system that receives the eReferral Document and communicates information about action taken and outcomes back to the Referral System that initiated the communication.
- eReferral Repository – is a system receiving a stream of referral data for analytical purposes. This system is just a repository of referral records. The data is processed and presented to System planner users in another system – the Dashboard in the above diagram.
- Dashboard – is an example of a system that consumes information from the repository for use by Health System Planning, Decision Support, etc.
Documents:
- eReferral Document – represents the information exchanged between the Referral Author and Referral Performer and in messages sent between an RMS Source and an RMS Target.
- eReferral MDS – represents the subset of the information in the eReferral Document that is relevant to health system planning that will be consumed by the Referral Repository.
eReferral Repository Use Case
Data Collection Scenario
Jane Doe is an independent senior who lives alone. She has had a recent injury that resulted in an emergency room visit, and has a follow-up appointment with her family doctor, Dr. Jones. During the visit, Dr. Jones decides that Jane should see an orthopedic surgeon to determine whether surgery is required.
Dr. Jones (the Referral Author and sender) initiates a search for the service from her EMR (Electronic Medical Record system), which is integrated with a Referral Management System (an RMS Source). She selects a surgeon, Dr. Treat (the Referral Performer), and completes the referral form. Upon submitting the referral, the referral request (eReferral Document) is sent to Dr. Treat's Referral Management System (the RMS Target). An email is sent to Jane confirming that the referral has been requested. A subset of the referral information is also submitted to eReferral Repository.
Dr. Treat reviews the referral and decides to accept it. Her secretary schedules an assessment appointment and sends the appointment date to Dr. Jones and Jane via her RMS Target system. In the background, a message is sent from the RMS Target system to notify the RMS Source system that the referral has been accepted, along with the proposed appointment time. After storing the information received in the message, the RMS Source system notifies the staff in Dr. Jones’ office and sends an email with the appointment information to Jane. The RMS Source system also sends an update to the eReferral Repository indicating that the request has been accepted with the appointment information.
Jane already has an important appointment on that date, so she declines the appointment and calls Dr. Treat's office to request a new appointment date. The medical secretary changes the appointment date and sends an update via her RMS Target system to Dr. Jones and Jane. Information is updated in the RMS Source system as it is received from the RMS Target. After storing the information received in the message, the RMS Source system notifies the staff in Dr. Jones’ office and sends an email with the updated appointment information to Jane. The RMS Source system also sends an update to the eReferral Repository with the updated appointment information.
Jane presents for the planned appointment with Dr Treat. She assesses Jane’s condition, and they agree to proceed with the surgery.
Jane relocates to another address and advises Dr. Jones’s office of the same. The medical secretary updates Jane’s address in their EMR, which also updates the RMS Source with which it is integrated. The RMS Source system notifies the RMS Target of this update and also sends an update to the eReferral Repository indicating that there has been an update to the patient demographics.
Operating Room time is booked by Dr. Treat’s secretary and appointment information is entered into the RMS Target where it is forwarded to the RMS Source. After storing the information received in the message, the RMS Source system notifies the staff in Dr. Jones’ office and sends an email information about the new appointment to Jane. The RMS Source system also sends an update to the eReferral Repository with information about the new appointment.
Jane presents for her scheduled surgery and the procedure is performed. Information entered into the RMS Target system by Dr Treat’s secretary flows back to the RMS Source system and the referral is marked as complete. The RMS Source system notifies the eReferral Repository of the change in status.
Alternate Flows
| Alternate Flow # | Scenario |
|---|---|
| ALT 1 | Dr. Jones and Dr. Treat use the same RMS in their practices. In this case, RMS Source is used to perform activities associated with RMS Target in the case above. |
| ALT 2 | Dr. Treat does not accept the referral. Referral is declined. |
| ALT 3 | After the referral has been sent, Jane’s medical condition changes and/or she reconsiders, and the referral is cancelled by Dr. Jones (Referral Author). |
| ALT 4 | After her initial appointment with Dr. Jones, Jane’s medical condition changes and/or she reconsiders, and the referral is declined by Dr. Treat (Referral Performer). |
| ALT 5 | During the initial consult, Dr. Treat determines that surgery is not required. Referral is completed after the initial consultation without booking a second appointment. |
Description of steps in the use case above
| Step | Action Description |
|---|---|
| 1. | Referral Author Creates Referral A Patient visits a Primary Care Physician (Referral Author), and they agree that the Patient should be referred to a specialist for assessment. The Referral Author uses her RMS Source system to select a specialist to refer the patient to and complete the necessary paperwork (eReferral Document). |
| 1.1 | Referral is transmitted to RMS Target system for access by Referral Performer The eReferral Document is sent from the RMS Source used by the Referral Author to the RMS Target used by the selected Referral Performer. (Note: Not required for scenario ALT 1) |
| 1.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 2 | Referral Performer receives and accepts the referral The specialist reviews the referral and decides to accept it. The Referral Performer updates the status of the eReferral in the RMS Target to reflect acceptance. |
| 2.1 | Referral status update is transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information (Note: Not required for scenario ALT 1) |
| 2.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 3 | Referral Performer schedules an appointment Staff in the specialist’s office schedule an appointment to perform a consultation with the patient. The scheduled appointment is recorded in the RMS Target system. |
| 3.1 | Appointment is transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT1) |
| 3.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 4 | Referral Performer updates Appointment Information or Status Patient or specialist request a change to the scheduled appointment date or time. Changes to the scheduled appointment is recorded in the RMS Target system. |
| 4.1 | Appointment updates are transmitted to RMS Source system, information is updated in RMS SourceInformation updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT1) |
| 4.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 5 | Appointment with Referral Performer, follow up appointment is scheduled Patient attends the appointment with the specialist, and it is determined that surgery is required. Visit information is recorded with information about the room visit is scheduled in the RMS Target used by the Referral Performer. Note: follow-up appointment maynot always recorded in the RMS source. |
| 5.1 | Appointment updates are transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT1). |
| 5.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 6 | Appointment with Referral Performer, Referral is completed Patient attends the appointment (or surgical visit) with the specialist. Visit information is recorded and the referral is marked as complete in the RMS Target. |
| 6.1 | Appointment updates are transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT1). |
| 6.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| 7 | Update to Referral Information (other than status change) The patient advises her Primary Care Physician (Referral Author) that her address has changed. This information is updated by the Referral Author in her RMS Source system. |
| 7.1 | Update to Referral Information is communicated to RMS Target The eReferral update is sent from the RMS Source used by the Referral Author to the RMS Target used by the selected Referral Performer. (Note: Not required for scenario ALT 1) |
| 7.2 | Update to Referral Information is communicated to Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| ALT 2 | Referral Performer receives and declines the referral The specialist reviews the referral and decides not to accept it. The Referral Performer updates the status of the eReferral in the RMS Target to reflect that the referral was declined. |
| ALT 2.1 | Referral status update is transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT 1) |
| ALT 2.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| ALT 3 | Referral Author cancels the referral After the referral has been sent, a decision is made to cancel the referral. The Referral Author uses her RMS Source system to cancel the referral. |
| ALT 3.1 | A request to revoke the referral is transmitted to RMS Target system, the RMS Target system deletes the Referral (Note: Not required for scenario ALT 1) |
| ALT 3.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
| ALT 4 | Referral Performer declines the referral after acceptance The specialist reviews the referral and decides not to accept it. The Referral Performer updates the status of the eReferral in the RMS Target to reflect that the referral was declined. (Note: this is the same action as ALT 2) |
| ALT 4.1 | Referral status update is transmitted to RMS Source system, information is updated in RMS Source Information updates in the RMS Target used by the Referral Performer are sent to the RMS Source system used by the Referral Author. The RMS Source system updates the information. (Note: Not required for scenario ALT 1) |
| ALT 4.2 | Referral information is transmitted to the eReferral Repository A subset of the information in the current version of the eReferral Document is sent from the RMS Source used by the Referral Author to the eReferral Repository used for health system planning. |
Minimum Data Set Elements
Privacy Context
In the case where the data collected for eReferral repository is under prescribed entity context the patient information will be limited to a Minimum Data Set specified for analytics repository.
For the Ontario eReferral repository, the Minimum Data Set is comprised of a set of FHIR resources defined in this guide with PI and PHI redactions.
Table 1 - Minimum Data Set Elements Mapping
| Data Element | Data Element Description | FHIR Resource Element | FHIR Resource Mapping |
|---|---|---|---|
| Referral Date | The date and time indicating when the referral was authored by the HSP. In absence of the HSP authored date/time, use the date/time when the bundle was created by the transmitter. | ServiceRequest.authoredOn | ServiceRequest |
| Appointment date | The date (yyyy-mm-dd) the patient had their first consult with the clinician. | Appointment.Start (date/time) -- associated with most recent fulfilled appointment when Appointment.status=fulfilled | Appointment |
| Wait 1 days | The total number of days the patient waited for the first consultation with a clinician. It is measured from the date the referral is created to the date of the first appointment with the clinician. (This is calculated field. Not included as a data collection item) |
N/A | N/A |
| Health Service Offering | The type of referral made for the patient from one clinician to another clinician for a first consultation. Equivalent to "service offering". | ServiceRequest.code ServiceRequest.category PractitionerRole.Specialty |
ServiceRequest PractitionerRole |
| Referral source | Who is generating the eReferral. There will be multiple rows containing the following information; referral source clinician name, CPSO number, clinic name, clinic address, and unique Oceans site number. |
ServiceRequest.requestor MessageHeader.author |
ServiceRequest MessageHeader |
| Referral Urgency | Level of urgency indicated on the referral by the referring clinician eReferral Values: -Routine -Urgent -ASAP -STAT Ocean does not capture ASAP and STAT. |
ServiceRequest.priority | ServiceRequest |
| Reason for Referral | From the perspective of the practitioner creating the referral what was the clinical condition that resulted in the need for the referral. | ServiceRequest.orderDetail | ServiceRequest |
| Referral Status | Was the referral accepted, rejected or redirected? If the referral was rejected then indicate what was the reason. | Task.status MessageHeader.reason |
Task MessageHeader |
| Outcome of the referral consultation | What was the treatment plan determined as part of the consultation (Surgical, Medical, return for follow up etc.) | N/A | N/A |
| Date referral was accepted by specialist | Date referral was accepted by specialist | Task.lastModified when Task.status=accepted | Task |
| Date the patient was provided with a consult appointment | To be used in identifying the mean turnaround time. | Appointment.Start (date/time) -- associated with first/unconfirmed appointment when Appointment.status=pending |
Appointment |
| Most current Date of the schedule consult appointment | KPI: Current scheduled vs actual consult date | Appointment.Start (date/time) -- associated with most recent confirmed appointment when Appointment.status=booked |
Appointment |
| Completed Date | The date the referral is considered completed (i.e. from a transition in care perspective) | Task.lastModified when Task. status=completed | Task |
| Consultation outcome | Are you treating the Patient [Yes / No] | Task.note | Task |
| Practitioner HCP/License# of clinician sending the referral | Practitioner identifier. (i.e. CPSO# for physicians) | PractitionerRole.Identifier.Value | PractitionerRole |
| Practitioner HCP/License# of clinician receiving the referral | Practitioner identifier. (i.e. CPSO# for physicians) | PractitionerRole.Identifier.Value | PractitionerRole |
| Practitioner Issuing Authority | Indicate the issuing authority that the Practitioner HCP/License # was retrieved from. | PractitionerRole.Identifier.Type | PractitionerRole |
| Practitioner Full Name | Practitioner full name | Practitioner.Name.Family Practitioner.Name.Given |
Practitioner |
| Organization Name | Organization name, and any associated identifier (e.g. address, phone, MOH code, if exists), where the service is to be provided. For community referrals this will identify the referral destination. For other referral types this can be associated with a specific care setting (e.g. hospital name) | Organization.identifier Organization.name Organization.telecom Organization.address |
Organization |
| Service Location | Location where the services are supposed to be delivered. This is typically associated with the appointment location. In cases where the appointment location is not provisioned it is assumed to be the receiving provider location included in the referral | Location.identifier Location.name Location.telecom Location.address |
Location |
| Service Area | Classification of the requested service or procedure. What specialty does the clinician fall under. | ServiceRequest.code PractitionerRole.specialty |
ServiceRequest PractitionerRole |
| MRN | Site specific identifier of the patient | Patient.identifier.value (where Patient.identifier.type.coding.code = MR) | Patient |
| HCN | Health card number of the patient | Patient.identifier.value (where Patient.identifier.type.coding.code = JHN) | Patient |
| Issuing Authority | Organization that issued HCN | Patient.identifier.system (where Patient.identifier.type.coding.code = JHN) | Patient |
| Patient Last Name | Patient full name | Patient.name.family | Patient |
| Patient First Name | Patient full name | Patient.name.given | Patient |
| Date of Birth | Patient's Date of Birth | Patient.birthDate | Patient |
| Patient Gender | Gender of the patient | Patient.gender | Patient |
| Address | Patient's (i.e. home or service address) complete address with the postal code. | Patient.address | Patient |
Redacted Data Elements
Table 2 - List of Redacted Data Elements
| FHIR Resource | FHIR Resource Purpose | Redacted Data Elements |
|---|---|---|
| MessageHeader | Message purpose and processing instructions | no redactions |
| Patient | Patient identifier and demographic information | telecom – e.g. phone #, email address maritalStatus contact – e.g. next of kin and other family members communication – preferred language, etc. generalPractitioner |
| ServiceRequest | Referral request from sender | supportingInfo – referral form data note – referral form data |
| Task | Status information from Referral recipient | output – may contain careplan, clinical notes, and other PHI from referral recipient |
| Practitioner | Provider information | no redactions |
| PractitionerRole | Additional provider information | no redactions |
| Organization | Organization information | no redactions |
| Appointment | Patient appointment information | comment – may contain other PHI from referral recipient patientInstruction – may contain other clinical info from referral recipient |
| Location | Location for the service/appointment | no redactions |
MessageDefinition: Analytical Repository ServiceRequest Bundle
The relationships between these resources are illustrated below.
Description:
Entries in the message Bundle used for Analytical Repository contributions will vary depending according to the trigger event. Minimally, a valid FHIR message SHALL include:
- a MessageHeader
- a ServiceRequest, Task, Patient or one or more Appointments referenced in MessageHeader.focus
- all FHIR resources referenced in the MessageHeader or any other resources in the Bundle
Repository Events
| Action | Event# | Repository Event | Focus | Sample Message (JSON) |
|---|---|---|---|---|
| Referral Author Creates Referral | 1.2 | notify-report-service-request | ServiceRequest | JSON |
| Referral Performer receives and accepts the referral | 2.2 | notify-report-service-request | Task | JSON |
| Referral Performer receives and declines the referral | ALT 2 | notify-report-service-request | Task | JSON |
| Referral Performer schedules an appointment | 3.2 | notify-report-service-request | Appointment Task |
JSON |
| Referral Performer updates Appointment Information | 4.2 | notify-report-service-request | Appointment | JSON |
| Referral Performer updates appointment Status | notify-report-service-request | Appointment Task |
JSON | |
| Appointment with Referral Performer, follow up appointment (or surgery) is scheduled. | 5.2 | notify-report-service-request | Two Appointments - Appointment | JSON |
| Appointment with Referral Performer, Referral is completed | 6.2 | notify-report-service-request | Task | JSON |
| Source Updates Patient Information | notify-report-service-request | Patient | JSON | |
| Update to Referral Information (other than status change) | 7.2 | notify-report-service-request | ServiceRequest (could be other resources depending upon what has changed) |
JSON |
| Referral Author cancels referral | ALT 3.2 | notify-report-service-request | ServiceRequest | JSON |
| Referral Performer declines referral | ALT 4.2 | notify-report-service-request |
Task | JSON |
| Appointment completed | ALT 5.2 | notify-report-service-request | Appointment Task |
JSON |