BusinessContext > Future Development/Consideration

Future Development/Considerations

This implementation guide covers the base case of the integration project developed in March 2019. Augmentation will continue to progress as more functionalities are introduced, including the possibility of integration with other assets (Transaction History Registry (THOR), ONEID etc.) provided by eHealth Ontario.

The initial release of this implementation guide will require the eReferral working group, authors, and participating integrators commitment to rapidly update and build upon this release as need arises by implementers. It is expected that it will continue to undergo rapid changes after its application to the initial set of real-world use cases. Implementers of this iGuide should continue to engage with the eReferral working group and contribute to the iGuide development.

This implementation guide intentionally focuses on creating a strong fundamental referral workflow, upon which most future updates can be "additions" rather than "changes" (e.g., adding attachment functionality).

As this implementation guide becomes adopted, efforts will be made to "normalize" it such that changes do not break existing implementations, however this will not be rigidly enforced in the early deployment learning phases. More early engagement and collaboration among the vendor community and system stakeholders will help enable the robustness of this specification.

Future Developments

Each future development items is rated on a priority/effort scale. Priority is often dictated by an immediate or near future implementation need.

  1. Very Low
  2. Low
  3. Medium
  4. High
  5. Very High

The status of each future development item is also listed:

  • Discussion - In preliminary discussion phase, needs significant debate
  • Proposed - Proposed as a change (with a champion backing the change), requires confirmation
  • Confirmed - Agreed that this item should proceed
  • In Progress - Updating specification for this item is in progress
  • Complete - The item has been incorporated into the specification

Proposed New Features

The following items represent entirely new functionality in the specification

Title Description Priority Effort Status
Attachments Submit attachments with new referrals High Med In Progress Complete in v0.10.0
Communications Send communication messages between RMS Source and RMS target after the initial referral submission High Med In Progress Complete in v0.10.0
Communication Attachments Include attachments with communications High Med In Progress Complete in v0.10.0
Profile Observation Resource Observation is an extremly flexible resource for collecting data, profile with eReferral instead of waiting for Canadian Base. See BSeR. High Med Discussion
Chained, Branched, and Grouped Referrals Design a method by which referral can be "chained" (Referral A generates Referral B), and "branched" referrals (Referral A generates Referral B,C,D) and "grouped" referrals (Referrals A,B,C created simultaneously and are connected). High High Discussion
Redirect URL Extension Create an extension to all a SMART on FHIR referral app to redirect to a specified URL after the referral submission is complete. High Low Proposed
Open app in iFrame vs. link Extension Add an extension or parameter to indicate to the app whether it will be displayed in an iFrame or in a new link/page. Layout could differ depending on the mode of the display, such as show/hiding headers, footers, and patient banners. High Low Proposed
Referral Cancellation Develop a method for the RMS Source to cancel the referral at the RMS Target Med Low Proposed Complete in v0.10.0
Service Directory Develop a Service Directory Med Very High Proposed
Consent Transmission Include a method to transmit consent (with consent resource) in the eReferral payload. Med High Proposed Complete in v0.10.0
Pub/Sub Architecture Create a pure RESTful method to GET updates to referrals and all of its resources Low Med Proposed
Add SMART on FHIR app to view submitted referrals Currently the SMART on FHIR LaunchString will only enable the process of submitting new referrals. Add a method to allow viewing an existing referral via a SMART on FHIR app. Consider additional option to open in a view or edit mode Med Low Proposed
Additional Profiles Add additional supported resources such as Medication, Allergy, Family History, etc. Low Med ~~Discussion ~~ More Profiles added to v0.10.0
GUI for ServiceRequest Add a GUI, or standard system for referral identifiers (e.g., "Initiator ID") Low low Proposed
Provenance Design a method to include provenance about updates to a referral via the API Low Low Discussion
RMS Registry Create an authenticated registry of RMS Source/Target systems their endpoints to simplify cross RMS system registration. Low Low Discussion
Multiple Providers Create a method to include multiple providers (note: does this overlap with "grouped" referrals concept?) Low Low Discussion
Specify "Message Sender" Specify the user that triggered an event (e.g., a referral update) in the MessageHeader.sender Low Low Discussion Complete in v0.10.0
Detail identity and trust management This should include: Systems, Providers, Patients, Users, Healthcare Services, Resources, and especially, Referal initiation bundles. It should describe identity proofing ad trust requirements (or lack of) and how identities are used end-to-end accross the eco-system Low Low Discussion

Proposed Changes

The following items represent changes to existing functionality in the specification

Title Description Priority Effort Status
Simplify "Update Referral" events There are 3 proposed alternatives to the current 5 "update Referral" events, which introduces unneeded implementation complexity
1) Reduce to 1 "notify-update-service-request" event with the full payload every time, and indicate via the focus field which resources have changed.
2) keep all events, but include the same full payload every time,
3) replace "update referral" events with fully RESTful pub/sub (subscription) model.		 High Low Discussion Complete in v0.10.0
Change referral process "Identifier" to an extension Currently the submitting system can add a number of identifiers to the initial service request, which is then included in all subsequent MessageHeader.focus.identifier fields. Change this to a MessageHeader extension. Low Low Discussion Complete in v0.10.0
Create codeset for Task.business Status Business Status is currently free text, with the state completely determined by the RMS target. Develop an agreed upon status codeset, but make it extensible to allow for more RMS defined states. Med Med Discussion Complete in v0.10.0

Proposed Fixes

The following items represent fixes to the specification, for example when the FHIR standard is incorrectly applied or an element is used inappropriately.

Title Description Priority Effort Status

Proposed usage of Ontario Provincial Assets

Leveraging various system components illustrated in the Conceptual Information Architecture can significantly improve the overall referral data quality and enhance the system security when designing integration solutions. They include, but not limited to, the following:

Title Description Priority Effort Status
ONE Access Gateway A FHIR-based API platform that enables RMSs to easily access various provincial digital services where appropriate, including, but not limited to:
- Client identity resolution via Provincial Client Registry (PCR)
- Sharing healthcare provider information from Provincial Provider Registry (PPR);
- Facilitating communication between RMSs by issuing system security keys
- Pub/Sub-based notification.		 TBD TBD Discussion
Transaction HistOry Registry (THOR) A central storage of province-wide transactional logs available via the ONE Access Gateway. It enables RMSs to contribute referral transaction activities to the THOR, as well as provides the ministry and other organizations with referral end-to-end reporting and data analytics functions. TBD TBD Discussion
ONE ID As a secure identity provider, provides enhanced privacy and security safeguards, as well as protects patient health information and provider account information. ONE ID serves various referral workflows and facilitates the following scenarios:
- Service providers access provincial digital health services from POS and/or RMSs by issuing and validating security tokens (OAuth2 and/or SAML)
- Referral communication between RMSs
- Transaction log contributions to the THOR by issuing and validating system security keys via ONE Access.		 TBD TBD Discussion

Powered by SIMPLIFIER.NET

HL7® and FHIR® are the registered trademarks of Health Level Seven International