Skip to content

Canadian EMR Landscape

Last Updated: 2026-02-14

This page documents the three major Canadian EMRs beyond OSCAR: Juno, Accuro, and Med Access. Understanding their APIs, access models, and business constraints is critical for multi-EMR integration strategy.

Overview

EMR Owner Based on OSCAR? API Auth Access Model
Juno WELL Health Yes (fork) SOAP + REST WS-Security + OAuth 1.0a IP whitelist + credentials
Accuro Loblaw/SDM No REST only OAuth 2.0 Business agreement + 6mo sandbox
Med Access TELUS Health No GraphQL JWT (RS512) TELUS partnership approval

1. Juno EMR

What It Is

Juno is a fork of OSCAR McMaster. Same Java/Spring/Hibernate codebase, same org.oscarehr.* packages, same Tomcat + MariaDB stack.

  • Creator: Cloud Practice Inc. (Victoria, BC, ~2012)
  • Acquired by: WELL Health for $5.75M in October 2022
  • Current status: Sits alongside OSCAR Pro in WELL Health's EMR portfolio

The GitHub repo (https://github.com/junoemr/junoemr) describes it as:

"a branch of open source electronic medical record (EMR) software released by McMaster University focused on stability, cloud-hosting, UI improvements, and 3rd party integrations."

API Surface — Identical to OSCAR

Because it's a fork, Juno exposes the exact same SOAP and REST endpoints:

SOAP (WS-Security, inherited from OSCAR)

/oscar/ws/ScheduleService     ← same getDayWorkSchedule
/oscar/ws/DemographicService  ← same searchDemographicByName
/oscar/ws/ProviderService     ← same getProviders2
/oscar/ws/BookingService      ← same bookAppointment
/oscar/ws/AllergyService
/oscar/ws/PrescriptionService
/oscar/ws/MeasurementService
/oscar/ws/LabUploadService
...all 14 SOAP services

REST (OAuth 1.0a, inherited from OSCAR)

/oscar/ws/services/schedule/*
/oscar/ws/services/demographics/*
/oscar/ws/services/providers/*
...same ~30 REST services

Confirmed from Juno's own release notes:

"looking up schedule slots via SOAP API now respects the case of the schedule code"

This proves SOAP API is actively maintained and patched in Juno.

How Commercial Products Connect to Juno

Cortico (Confirmed)

Source: https://help.cortico.ca/help/allowing-cortico-to-access-your-juno-emr

  • Juno uses IP whitelisting — clinic emails support@junoemr.com requesting whitelist of Cortico IPs:
  • 192.30.89.37
  • 192.30.89.38
  • 193.188.3.213
  • 193.188.3.212
  • 199.49.111.174
  • Then REST client created via Administration > Integration > REST Clients
  • OAuth 1.0a token exchange
  • Compatibility rating: COMPLETE (excellent with minor differences)

DermEngine (Confirmed)

Source: https://www.dermengine.com/integration/juno

  • REST API with OAuth via registered REST client in Juno

OceanMD (Confirmed)

Source: https://support.cognisantmd.com/hc/en-us/articles/360046938751-OSCAR-Pro-Create-your-REST-Client-in-OSCAR

  • REST API via Ocean Cloud Connect + REST client in OSCAR/Juno

Veribook (Confirmed for OSCAR, works identically on Juno)

Source: https://medical.veribook.com/syncing-scheduling-templates

  • Schedule template sync via SOAP (getDayWorkSchedule is SOAP-only)

Key Difference from Self-Hosted OSCAR

Juno is cloud-only, managed by WELL Health. You don't get SSH. You request IP whitelisting from Juno support before any external system can reach the API.

Once whitelisted, the SOAP and REST endpoints work identically to any self-hosted OSCAR.

What This Means for Your Strategy

Your OscarSoapAdapter works on Juno with zero code changes.

Same ScheduleWs, same getDayWorkSchedule, same addAppointment. The only onboarding difference is the IP whitelisting step.

2. Accuro EMR

What It Is

Completely different from OSCAR. Proprietary EMR built by QHR Technologies (Kelowna, BC, founded ~2000).

  • Acquired by: Loblaw Companies / Shoppers Drug Mart for $170M CAD in August 2016
  • Market position: ~17% of Canadian physicians (Statista 2021), ~18,000 physicians
  • Leading single-platform EMR in Canada. 70%+ of Manitoba providers.
  • Tech stack: Java-based thick client, delivered via Citrix Workspace cloud virtualization, backed by Microsoft SQL Server (not MySQL/MariaDB)

NOT open source. NOT related to OSCAR in any way.

Accuro API — Modern REST, Nothing Like OSCAR

Accuro has a proper, documented REST API with 150+ endpoints:

Attribute Value
Protocol REST (JSON)
Auth OAuth 2.0 (client credentials, provider, patient grants)
Documentation https://apidocs.dev.qhrtech.com/docs/ (public Swagger UI)
Spec OpenAPI/Swagger JSON downloadable

Scheduling Endpoints (Subset)

GET    /v1/provider-portal/scheduler/appointments
POST   /v1/provider-portal/scheduler/appointments
GET    /v1/provider-portal/scheduler/appointments/{id}
PUT    /v1/provider-portal/scheduler/appointments/{id}
DELETE /v1/provider-portal/scheduler/appointments/{id}
GET    /v1/provider-portal/scheduler/availability-templates
POST   /v1/provider-portal/scheduler/availability-templates
GET    /v1/provider-portal/scheduler/applied-availabilities
GET    /v1/provider-portal/scheduler/statuses
GET    /v1/provider-portal/scheduler/reasons
GET    /v1/provider-portal/scheduler/sites
POST   /v1/provider-portal/scheduler/lock
DELETE /v1/provider-portal/scheduler/lock

Patient Booking

GET    /v1/patient-portal/scheduler/appointments
POST   /v1/patient-portal/scheduler/appointments

No SOAP whatsoever. Zero evidence of SOAP in Accuro.

Accuro's Scheduling Model vs. OSCAR's

OSCAR:                                 ACCURO:
┌─────────────────────────┐            ┌──────────────────────────────┐
│ scheduletemplatecode     │            │ Template Suggestions         │
│ (single char: '1','C')  │            │ (full objects: Lunch,        │
│                          │            │  Physical, Consultation...)  │
├─────────────────────────┤            ├──────────────────────────────┤
│ scheduletemplate         │            │ Availability Templates       │
│ (48-96 char timecode    │            │ (arrange suggestions into    │
│  string)                │            │  time slots with durations)  │
├─────────────────────────┤            ├──────────────────────────────┤
│ scheduledate             │            │ Applied Availabilities       │
│ (provider + date +       │            │ (template applied to         │
│  template name ref)     │            │  provider for specific dates)│
├─────────────────────────┤            ├──────────────────────────────┤
│ appointment              │            │ Appointments                 │
│ (provider + patient +    │            │ (+ types, reasons, statuses, │
│  time + status)         │            │  priorities, sites, rooms)   │
└─────────────────────────┘            └──────────────────────────────┘

OSCAR: character-based timecodes       ACCURO: proper relational model
       joined by varchar refs                  with typed API resources

API Access — Gated Behind Business Agreement

This is the critical business constraint:

  1. Email inquiry@AccuroEMR.com with your company details
  2. Business discussion with QHR team
  3. Sign Terms of Use (DocuSign)
  4. Receive OAuth 2.0 credentials + 6-month sandbox
  5. Complete sandbox/UAT testing + privacy and security review
  6. Sign production agreement
  7. All costs borne by the vendor
  8. Not listed on QHR marketplace until you have at least one live implementation

Sources: - https://accuroemr.com/accuroapi/ - https://accuroemr.com/vendor-expectations/

What This Means for Your Strategy

Your OscarSoapAdapter does NOT work here.

Accuro needs a separate AccuroRestAdapter implementing the same IEmrAdapter interface but talking REST/OAuth 2.0 to completely different endpoints.

The scheduling concepts map (templates → applied availabilities → appointments) but the protocol and data shapes are entirely different.

Good news: Accuro's API is vastly better documented than OSCAR's, with proper OpenAPI specs you can generate client code from.

3. Med Access EMR

What It Is

NOT OSCAR. Not even close.

Proprietary EMR built by Med Access Inc. (Kelowna, BC, founded ~2002).

  • Acquired by: TELUS Health in March 2014
  • Current status: One of TELUS's two primary EMR products (alongside PS Suite)
  • Market: ~2,000+ physicians across BC, AB, SK, MB, ON, NS, NL
  • OntarioMD certified
  • Web-based, TELUS-hosted cloud

Med Access API — Walled Garden

This is the hardest integration target of the three:

Attribute Value
Protocol GraphQL (TELUS CHR Enterprise API)
NOT REST, NOT SOAP, NOT FHIR
Auth JWT (RS512 algorithm)
Documentation NOT public. Available only to approved partners.
Access Must request through TELUS. They provision everything.

FHIR

TELUS publishes FHIR R4 profiles on Simplifier.net ("TELUS Patient Chart") but this appears to be push-only data extraction, not a full read/write API.

Cloud Connect

OceanMD connects via TELUS Cloud Connect middleware. Requires EMR Instance ID + EMR Secret from TELUS.

There is no self-service developer portal. You fill out an Integration Request Form with TELUS, they decide whether to work with you, they provision credentials, they control the connection.

This is a walled garden.

Who Integrates with Med Access

OceanMD (Confirmed)

Source: https://support.cognisantmd.com/hc/en-us/sections/360002957851-TELUS-Med-Access-Integration-Set-Up

  • Via TELUS Cloud Connect
  • Full eReferrals, eConsults, patient messaging, eForms

Cortico — NOT officially integrated

Source: https://help.cortico.ca/help/emr-compatibility

  • Listed as "In Progress" on Cortico's compatibility page
  • Explicit statement:

"While users of Med Access and PSS may use Cortico, we have no partnership with TELUS, and Cortico is not a TELUS-endorsed integration."

Tali AI (Confirmed)

Source: https://help.tali.ai/en/articles/9672039-tali-ai-s-integration-with-med-access

  • AI medical scribe, officially integrated via TELUS

What This Means for Your Strategy

This is a separate adapter AND a separate business relationship.

You'd need: - TELUS partnership approval - GraphQL client (not REST, not SOAP) - JWT auth with RS512 signing - Completely different data model mapping

Med Access is the hardest and lowest-priority integration target.

Even Cortico — the most established OSCAR booking platform — hasn't been able to officially integrate with Med Access.

Summary: Three EMRs, Three Realities

Attribute Juno EMR Accuro EMR Med Access EMR
Based on OSCAR YES (fork) NO NO
Owner WELL Health Loblaw/SDM TELUS Health
API Protocol SOAP + REST REST only GraphQL
Auth WS-Security + OAuth 1.0a OAuth 2.0 JWT (RS512)
API Docs WSDL + WADL (self-serve) OpenAPI/Swagger (public) NOT public (gated)
Schedule API getDayWorkSchedule (SOAP only) Full REST CRUD + templates Unknown (GraphQL)
Access Model IP whitelist + credentials Business agreement + 6mo sandbox TELUS approval + provisioning (walled garden)
Hosting Cloud (WELL) Citrix Cloud Cloud (TELUS)
Database MariaDB SQL Server Unknown
FHIR No (OSCAR Pro has it) No (via Ocean only) Partial (TELUS FHIR profiles)
Your Adapter OscarSoapAdapter (SAME as OSCAR!) AccuroRestAdapter (NEW, ~400 lines) MedAccessGraphQLAdapter (NEW, hardest, needs TELUS partnership)
Effort ZERO (reuse OSCAR adapter) MEDIUM (good docs, clear API) HIGH + business dev required
Priority FREE — comes with OSCAR adapter 2nd target after OSCAR Last target (even Cortico can't do it)

How This Maps to Your Adapter Strategy

IEmrAdapter interface
       │
       ├── OscarSoapAdapter     → OSCAR + Juno + OSCAR Pro + MedAccess(Oscar-based)
       │                          (one adapter, four EMRs — all OSCAR forks)
       │                          getDayWorkSchedule via SOAP
       │                          addAppointment via SOAP
       │                          Auth: WS-Security
       │
       ├── AccuroRestAdapter    → Accuro EMR
       │                          /v1/provider-portal/scheduler/* via REST
       │                          availability-templates + applied-availabilities
       │                          Auth: OAuth 2.0
       │                          Good docs, clear path, business agreement needed
       │
       ├── MedAccessAdapter     → Med Access EMR (TELUS)
       │                          GraphQL via TELUS CHR Enterprise API
       │                          Auth: JWT RS512
       │                          Requires TELUS partnership
       │                          Lowest priority, hardest access
       │
       └── FhirR4Adapter        → US EHRs (Epic, Cerner) + future Canadian FHIR
                                   FHIR Schedule/Slot/Appointment resources
                                   Auth: SMART on FHIR / OAuth 2.0
                                   Future play (US market or CA 2029+)

The adapter pattern holds. Each EMR speaks a different language, but your BookingEngine doesn't care — it calls the same IEmrAdapter methods regardless.

The strategy is sound across all target EMRs.

Next: Adapter Implementations — Technical details of each adapter