Business Context > Future Development Considerations

Future Development Considerations

This implementation guide covers the base case of the integration project developed in March 2019. Content was added in July 2021 to help clarify the expected use of FHIR Messaging and SMART on FHIR with some technical fixes to enable validation of message instances created by implementers.

The requirements and expectations in this IG are not intended to be exhaustive. The current version of the IG establishes a baseline of expected behavior that communication partners can rely on and then build upon without standardizing referral pathways or defining what clinical data must be exchanged when referring patients.

Augmentation will continue as more functionality is introduced, including the possibility of integration with other assets provided by Ontario Health.

The implementation guide will require the eReferral working group, authors, and participating integrators commitment to continue to update and build upon this release as need arises by implementers. It is expected that it will continue to undergo 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 IG development.

Future Developments

Future development items are identified below and 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 In Progress Draft in v0.10.1
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
Response handling Response handling page does not include
- description of 200 for sync and async messaging
- requirement for OperationOutcome for the 400s
- links to examples		 TBD TBD Discussion
Security (use of encryption protocols, authentication, authorization) Secuirty deserves its own section. Familairity with OAuth2 Authorization Framework, OpenID Connect is mentioned everywhere. However there will still be big variations in implementation.
I would even go as far as to suggest the use of a specific framework (i.e. OneID latest version) that can be used as a provincial standard.
As a bare minimum there should be some guidance on security concepts that will be required for any implentation.		 TBD TBD Discussion

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
Context Management System A question was raised about role of CMS raised in conversation about SMART Integrations during 0.10.1 development TBD TBD Discussion
Viewlet Framework A question was raised about role of Viewlet framework vs SMART on FHIR was raised in conversation about SMART Integrations during raised during 0.10.1 development TBD TBD Discussion