eReferral Form Business Process Flow

eReferral Form Management has five stages (Forms Design, Forms Approval and Publication, PHSD Form Publication and Dissemination, RMS Form Retrieval and Customization, and RMS Form Rendering) and three Systems to support Forms Approval and Publication, PHSD Form Publication and Dissemination, RMS Form Retrieval and Customization, RMS Form Rendering

Form Design stage focuses on:

• Priority Referral Form from Forms Request
• Review, Define and Refine specifications
• Document Referral Form Specification
• Render specification (display and form customization)

Forms Approval and Publication stage is supported by Form Designer system, this stage has below activities:

• Translate the Referral form specification into FHIR SDC compliant System Specifications
• Design, Build, and Develop Form Template
• Test and Validate Form Template against FHIR SDC and Referral Form specification
• Approve Form Template(s)
• Store Form Templates into repository and make them ready to publish

PHSD Form Publication and Dissemination stage performs below activities, the stage is backed with PHSD System

• Pickup, Import and Load All or new Form Templates into Form Template Repo under PHSD
• Use a PHSD service taxonomy convention, and update the corresponding PHSD record with the new form URL
• Assign Form Template to Health Providers mapped on Health Service Category, Specialty or Procedure Code
• Prepare and disseminate Form Templates to RMS Vendor on request.

RMS Form Retrieval and Customization stage:

• Retrieve and Download Form Templates from PHSD Forms Repo
• Store Form Templates into RMS Local Form Repo
• Develop Customized Forms

RMS Form Rendering stage perform:

• Use of rendered form to perform eReferral by RMS source and target
• Render forms using predefined templates
• Capture form data and trigger an eReferral request upon submission.

RMS Vendor System provides system support for RMS Form Retrieval and Customization and RMS Form Rendering stage.

Referral Form Retrieval, Customization and Rendering

Background

With the introduction of standardized referral forms (SRFs) in support of the Ontario eReferral network, there is an increasing need for referral forms to be created in a digital, standards-based compliant format so they can be interchanged between various RMS vendors collaborating to connect providers engaged in the referral workflow.

OH in consultation with its partners decided to use the Fast Healthcare Interoperability Resources (FHIR) Structured Data Capture (SDC) HL7® interoperability standard to define referral form templates and make them available to end users through Referral Management System (RMS) vendor solutions.

Form templates are published through the eForms Designer. The Public Health Service Directory (PHSD) then associates these templates with referral destinations using coded values embedded by the designer. A single form template can be linked to multiple referral destinations. To support this, PHSD augments the form template by adding PHSD-specific identifiers for the matched destinations into the form content (via the useContext element).

RMS Implementation Support

The end-to-end referral form workflow starts with new forms designed and published in PHSD and ends with the RMS user interface rendering the form to the end user.

This journey can be split into the following sections:

• Referral Form Template Publication (Form template design and approval in the eForms designer)
• Form Template association with Service Destinations in PHSD (by service category and type)
• RMS Synchronization of Service Destinations and Form Templates with PHSD
• Customized forms creation from Referral Form Templates based on an individual service destination’s service offerings
• Referral Forms Rendering during the referral workflow

Referral Form Template Publication

The Standardized Referral Forms (SRFs) Working Group (SRF WG), as part of the Ontario Health (OH) Patients Before Paperwork (PB4P) initiative, is a clinically led working group that aims to standardize referral forms in Ontario.

The SRF WG prioritizes the referral templates subject to publication. The SRF WG requirements are then implemented through a clinical lead engagement process, with the final product being a referral form for a specific pathway, digitized using the FHIR SDC standard.

Referral Form Templates, developed to be FHIR SDC-compliant, are approved by clinical users and published into the Forms Repository. PHSD ingests the form templates to the PHSD repository and assigns the form templates to service destinations.

At the time of form design and publication, each form contains, in addition to the actual form fields, a set of metadata parameters that indicate the service offerings targeted by the published form.

Example – Neurology referral form with service coding for services requested:

This metadata is used to look up service listings (service destinations) in the PHSD and associate the service listing to the form template. The PHSD published form template is supplemented with a reference to the Service Listing(s) via the useContext (0..*) element within the Questionnaire (SDC) template.

In addition, the published forms also include coded values for specific form fields.

These fields are typically used to codify requested services that a referral requester may select at referral creation time, and a referral performer may support/accept when receiving the referral.

These coded form fields are also intended to support real-time form customization by service (i.e., the referral form presented to the user includes only service choices that the service provider can deliver).

More details about the form coded elements are provided in the Referral Form Customization Process topic below.

Referral Form Templates Download and Service Association

As new referral templates become available in PHSD, the RMS solution can download them on a regular basis (daily, weekly, or as needed). This ensures that the latest standardized forms are available to end users for referral processing.

Each form will contain service mapping data in its metadata parameters. The RMS solution is expected to download the form template into its local directory and associate each form with the local referral destination records using the cross-reference to the service listings embedded in the useContext element. This will require a cross-reference between the PHSD ID and the local service identifier to be maintained.

The form template download/synchronization is an RMS-initiated workflow.

Form download is achieved by a series of REST API GET calls to:

• Initialize download request
• Inquire about the download preparation process status with the status URL until ready to download
• Download Form Templates from the PHSD-generated endpoint

RMS form download sequence starts with a GET request to the PHSD Bulk Export API.

The PHSD Bulk Exporter API responds with an acknowledgment and a URL upon receiving the download request from RMS. The Bulk Export API invokes a backend Form Template preparation process.

Note: The Bulk Export API is the same API for all resource types, including Practitioners, Healthcare Services, and Form Templates. The operation has the ability to filter by resource and time (e.g., request only new Form Templates (Questionnaire)).

The PHSD backend process will take some time to prepare the data for export.

Once bulk export files are ready, the backend service will generate a download URL for each file containing the required resources from the request (e.g., Form Templates, Healthcare Service resources, etc.).

Note: If there are no form templates or the request criteria return no records, empty files will be generated and download URLs will still be provided.

When RMS receives the full URL, it can start downloading the bulk export file(s).

OH recommends storing the downloaded form templates within the RMS into the local RMS Form Repository.

Similarly, the Healthcare Service and Provider records should be saved into the local RMS Health Service Directory (Local HSD).

Based on the service linkage included in the form templates, the RMS must associate the form templates with referral destinations in the local HSD.

Once the forms are associated with referral destinations in the RMS and (optionally) customized per destination, RMS is expected to invoke the PHSD Bulk Import API to upload any RMS-customized Forms and the associated Healthcare Service data back to PHSD.

Referral Form Customization Process

The primary goal of customizing referral forms for each service listing is to increase the number of referrals that are accepted by service providers. Rejected referrals create administrative burdens for both the service provider and the service requestor, leading to delays and inefficiencies. While eReferral helps streamline the process and accelerates patient access to appropriate care, managing rejected referrals remains a time-consuming and avoidable effort. Referral quality and acceptance rates can be significantly improved by aligning referral form content with service-specific requirements.

The referral destination’s capabilities are required to be searchable to ensure that only relevant service providers are available for selection based on the patient’s needs. Searching for a service provider for one service and then opening the form to find out they do not provide that service would be a frustrating user experience.

The Standardized Referral Forms and Provincial Health Service Directory (PHSD) integration allow forms to render only those service options and clinical indications that match the service provider’s capabilities.

To facilitate this, we need to capture the appropriate level of information:

• The service provider’s capabilities defined at a granular level and codified
• The form’s service options defined at the same granular level as the service provider’s capabilities using the same code set (e.g., SNOMED)

NOTE: As part of the clinical engagement process, the appropriate SNOMED terminology needs to be verified with clinical leads to ensure proper usage/mapping to requested services.

The systems involved in the referral ecosystem (primarily RMS) need to be able to “switch off” service options on the form based on the service provider's capabilities, ensuring selection of services that referral destination providers are able to process/accept.

A Referral Form Template may include multiple service options.

Note: Not all referral forms contain multiple service options (e.g., Universal Referral Form). In these cases, the form will not be subject to customization. Also, service providers or Central Intake destinations that support all service options on the form will not need customization.

RMS should customize Form Templates according to referral destination capabilities, or services that a referral performer advertises (or lists) in the service directory. This requires the RMS to have knowledge of services supported by each referral destination and associated performing providers.

The diagram below illustrates the customization flow, based on the service offerings supported by the performing provider:

The services options in a referral form template are coded with SNOMED so they can be identified programmatically and matched with services and providers in the service directory.

The example below depicts a concrete example of a Neurology form:

The above section with JSON representation is:

Let’s assume the form needs to be customized to only show the first two values for a specific referral destination.

This can be achieved by “removing” the third option from the choice list before rendering the template to the end user.

The RMS solution needs to track all SNOMED codes for referral destinations to match the requested services in a standard template and display the “customized referral form view” to the user for the selected destination.

This is achieved by synchronizing the referral listings created in RMS Target system with PHSD and then with RMS Source systems.

The RMS Target listings are created by deployment teams (DT) and site administrators in the RMS Target system. The DT captures the provider capabilities for when onboarding the organization or the individual specialist to the eReferral network, or when creating new listings for an existing referral destination site.

FHIR SDC support: there is an SDC extension that, once included in the Questionnaire.item, supports toggling to hide or display choices within a list of options. The extension name is answerOptionsToggle. It includes an expression to control the display of the option.

For example, in the Cardiology form below, the following services are indicated and may be offered by different service providers.

Let’s assume that one service provider only offers the following services – Coronary Angiogram, ECG and Title Table Testing. All other services are not offered by this service provider.

As such, the SNOMED codes within the Form Level Attributes of the form must be updated to reflect only the services provided by the provider – all other services should be deleted.

The questionnaire’s JSON has been set up so that the options associated to the SNOMED codes defined within the form level attributes will be displayed. All other options will be hidden:

In the example above one option to make the “Stress Testing” option invisible to the end user is to blank out the code associated with this option.

RMS Referral Form Rendering

Standardized referral form templates are associated with services performed by various practitioners represented in the service directory.

It is expected that once a user finds a referral destination in the RMS local service directory, the system would render a referral form associated with the specific destination selected by the user.

The referral form template would need to be rendered within the user interface of the RMS solution.

The referral form template, compliant with FHIR SDC format and customized for services available at the referral destination, follows this implementation guide.

The RMS ability to rendered provincial referral form templates, and regional referral form templates, with or without customization, is dependent on the solution ability to support this implementation guide.

Dynamic form rendering is a feature associated mainly with the RMS Source since it is the sending provider that the needs to see only service options available at the selected referral destination.

However form rendering capability is not only associated with RMS Source ability to render a FHIR SDC Questionnaire template.

RMS Target systems need to be capable of following the SDC Questionnaire structure for rendering QuestionnaireResponses that were package in the referral bundle by the RMS Source system.

The RMS Source must include a Questionnaire reference in the QuestionnaireResponse resource if an FHIR SDC SRF was used to render the referral form for the referring provider.