Overview
This guide is designed to assist EMR and EHR vendors with their integration with Ocean Cloud Connect using the FHIR module within Cloud Connect.
Historically, the Ocean team added specific modules to Cloud Connect for specific EMRs to connect to the proprietary APIs provided by these EMRs. This approach was effective for achieving integration in the early days before FHIR was the prevalent standard it is today. However, like other proprietary integrations, it does not scale well for either party.
Moving forward, the Ocean team is aiming to provide new integrators with the option of connecting to Ocean as an integrated EMR/EHR using a single, well-defined FHIR API protocol. In this context, Cloud Connect is acting not as the FHIR server but as a FHIR client, with certain specific requirements for the FHIR server. These requirements will ensure that adequate endpoints and resources are available for Ocean when providing the following EMR-integrated products and services:
- Ocean eReferrals and eConsults
- Online Booking (OAB)
- Patient Reminders and Appointment Reminders
- Check-In Kiosks
- Tablets
- Patient Messages
- Website Forms
High-Level Requirements
For a successful integration, implementors must provide the following services:
- Authorization via OAuth2
- HL7 FHIR Release 4 (R4) RESTful endpoints for core FHIR Resources such as Patient and Appointment
- A FHIR capability statement endpoint in the standard location GET [base]/metadata?mode=oceancc for Cloud Connect to determine which integration features are available.
- The Patient/$everything operation for comprehensive patient record loading
- Depending on the product, extra endpoints may be required (see RESTful Endpoint Requirements)
Design Principles for This Specification
We have attempted to keep this implementation relatively straightforward by minimizing the baseline requirements, while balancing against mandatory functionality. We want to provide sufficient documentation to eliminate ambiguity in the implementation decisions, particularly with regard to the resource endpoints and data elements.
We all win by adhering to existing standards, so whenever possible we have attempted to align with established regional standards, particular pan-Canadian FHIR standards, using the US convention as a fallback. Another important guide is the WELL FHIR API Documentation, which is an important reference implementation for this project and an implementation we aim to ensure is fully compatible.
FHIR Profile Standards
With this in mind, we have extended the profiles outlined in the Canadian Baseline; project source here; simplifier project here). The public URLs for the Canadian Baseline unfortunately do not resolve at the time of this writing due to a reconciliation process (e.g. http://hl7.org/fhir/ca/baseline/StructureDefinition/MedicationStatement); as a result we use the continuous-build URLs (e.g. https://build.fhir.org/ig/HL7-Canada/ca-baseline/StructureDefinition-profile-medicationstatement)
When no Canadian baseline profile is available, the equivalent US Core profiles are used, or the base R4 profile when nothing else is available (e.g. Appointment).
Coding Standards
In terms of diagnostic and Observation clinical coding, LOINC should be used, with SNOMED as a fallback in areas outside of the scope of LOINC. In particular, Ocean references a core set of LOINC codes for certain use cases, such as the pre-population of a patient's hemoglobin or blood pressure in a referral form. However, the specific diagnostic codes used are otherwise ignored by Ocean.
RESTful Endpoint Requirements
M = mandatory, O = optional, N = not used
| Endpoint | Online Booking | Reminders | Kiosks | Messages | Website Forms |
|---|---|---|---|---|---|
| Appointment GET | M | M | M | O | N |
| Appointment POST | M | M | M | O | N |
| Appointment PUT | M | M | M | O | N |
| CapabilityStatement | M | M | M | M | M |
| DocumentReference | M | M | M | M | M |
| Patient GET | M | M | M | M | M |
| Patient PUT | M | M | M | M | M |
| Patient POST | M | M | M | M | M |
| Practitioner | M | M | M | N | O |
| Schedule | M | M | M | N | N |
| Slot | M | N | N | N | N |
| ValueSet | M | M | M | M | M |
| Observation | M | M | M | M | M |
| Patient/$everything | M | N | M | M | N |
| Condition | N | O | O | O | O |
| Consent | O | O | O | O | O |
| QuestionnaireResponse | O | O | O | O | O |
| Task | O | O | O | M | M |
| Procedure | N | O | O | O | O |
Other Resources (not offered as endpoints)
| Resource | Used For | Accessed Via |
|---|---|---|
| AllergyIntolerance | Form pre-population | Patient/$everything |
| CareTeam | OAB, Kiosk | Patient/$everything |
| Immunization | Form pre-population, Vaccine reminder forms | Patient/$everything |
| MedicationStatement | Form pre-population, Medication reconciliation form | Patient/$everything |
Other Ocean Integrations
This implementation guide focuses on Cloud Connect's direct back-end integration with a compatible EMR/EHR system. There are two other Ocean integrations to consider that are complementary to Cloud Connect: SMART on FHIR, which is used for user single-sign-on and patient-contextual launching of Ocean as an application, and the eReferral specification, which assists with the backend sending and receiving of FHIR ServiceRequests designed to support eReferral and eConsult use cases.
SMART on FHIR
The requirements for SMART on FHIR contextual launch for Ocean are outlined in a separate article: SMART on FHIR Implementation Guidance
eReferral and eConsult Back-end Integration
Ocean implements the Ontario eReferral Specification for the purpose of sending and receiving eReferrals, eConsults, and other ServiceRequest resources. Although this integration may feel like a whole other project, it is best described in relation to this implementation as an extra set of implementation criteria for the ServiceRequest endpoint (which has been omitted as an endpoint in this guide to avoid unnecessary overlap).