Referral Forwarding

Referrals can be forwarding within the Ocean platform or via

Referral Forwarding in Ocean

eReferrals which are created in Ocean can be forwarded to another Ocean listing (and/or site) that is more appropriate for administering care. This forwarding takes place in Ocean using the “forward” button on an eReferral and is typically common with the Central Intake listings in Ocean – more information on the Central Intake Listings and Ocean forwarding can be found in this article. Additionally, this workflow is supported by the FHIR APIs and is a form of routing, which is outlined in the Pan-Canadian eReferral iGuide.

With this workflow, when an eReferral is forwarded from Listing A to Listing B, if Listing B is a FHIR integrated site, it receives an add-service-request payload informing its system of a new eReferral creation. Additionally, the MessageHeader.destination in this payload will pertain to Listing B. Furthermore, there will be two ServiceRequest resources present in the payload; where one pertains to the forwarded site with its ServiceRequest.performer present as Listing B, and the other pertains to the forwarding site with a replaces element present and it’s ServiceRequest.performer present as Listing A.

Referral Forwarding via RMS Target

Similar to the referral forwarding in Ocean workflow described in the section above, eReferrals which are created in Ocean can be forwarded to a listing in Ocean via the APIs. i.e. A receiving system (RMS Target) can forward an eReferral which it received from Ocean to another listing in Ocean by sending Ocean an API message. Similar to the workflow which is performed in Ocean, this is also a form of routing outlined in the Pan-Canadian eReferral iGuide.

A few things to note is that this forwarding can only be successfully completed to an existing listing in Ocean, with its corresponding HSC. Additionally, each listing in Ocean has a unique listingRef, which must be highlighted in the payload for this to be successful. At this time, this information must be obtained from an Ocean Support resource.

The requirements of this workflow are outlined below:

• In v0.10.0, this forwarding must be completed with a notify-update-service-request message event, while in v0.11.1, it must be completed with a notify-update-process-request message event.
• The request should have two ServiceRequest resources that look similar - one of those is for the forwarding listing/referral target (Listing A) and the other is for the forwarded/new listing (Listing B).
  • The ServiceRequest for Listing A should be unchanged and the same as was previously present
  • The ServiceRequest for Listing B should contain a ‘replaces’ element which references the referral ID for Listing A. Additionally, it should include a ‘category’ element which properly highlights the listing’s HSC – more information on supported HSCs are found here, and a ‘performer’ element referring to the Listing’s PractitionerRole.
  • The MessageHeader.destination and subsequently the MessageHeader.receiver should refer to Listing B’s PractitionerRole.

Once the payload has been properly set up and send to Ocean, the referral would be forwarded to the new target listing, and the event log will reflect this forward.