Overview

This eReferral architecture is designed with the following criteria

  • Standards Based - Adhere to HL7 FHIR (release 3.5) standards
  • Modular - Each component in the architecture can be a different system, and is substitutable
  • Non-jurisdictional - The architecture does not depend on existing infrastructure in specific jurisdictions (but can accomodate the infrastructure context across Canada).
  • Distributed - Transactions move across an ecosystem of independent components, rather than depend on a centralized service to manage transactions
  • Enable Sophisticated Business Logic - The architecture allows for a wide variety of workflows
  • Simple to Implement APIs - The protocols should be quick to learn and deploy, with tools available to facilitate testing and learning.
    • The sending and receiving system should not require the deployment of a webserver to participate in eReferrals, but it would enable enhanced functionality.

Notes:

Core Philosophies

  • Use a transaction/transaction-response mechanism for Servicerequest. Thus, if one resource fails, all fails. The ServiceRequest is the atomic Unit.
  • Using a REST paradigm. Considered using messaging, but the process requires synchronous elements such as returning a referral ID on submission.
  • The eReferral server owns the "source of truth" for the sender.

More Notes

  • Appointment: There are many fields that could duplicate values in the ServiceRequest, so we just ignore those and rely on the serviceRequest

Last updated on