# 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