Canvas Medical — EHR

1What Canvas is

Canvas Medical is an API-first, programmable EHR — a “decoupled EHR” whose entire clinical record is reachable through a FHIR R4 API and extensible through a developer SDK and plugins. Where a legacy EHR is a closed application you log into, Canvas is a clinical-data platform a team can either use through its full point-of-care interface or build custom experiences on top of, while still leaning on Canvas’s compliance and clinical foundations. That posture is exactly why a tech-enabled, value-based-care operator chooses it: the data is meant to flow in and out as a first-class capability.

Spelling note: the vendor is Canvas Medical — one s, “Canvas,” not “Canvass.”

2Company facts

3Architecture — how the data is shaped

Canvas’s defining architectural choice is the FHIR API as facade. The API (“Fumage”) sits in front of each customer’s EHR server container and translates between the FHIR R4 representation and Canvas’s internal data models. Everything a team reads or writes — clinically, financially, operationally — passes through one unified data architecture with built-in validation.

• One standard on the wire. External access is FHIR R4 over a language-agnostic REST API — the same shape whether the consumer is a mobile app, an analytics pipeline, or a lab/pharmacy integration.
• Programmable, not just queryable. The Workflow SDK and plugins let a customer extend behavior (automations, custom UI, custom logic).
• Custom APIs beyond raw FHIR. Canvas also exposes higher-order endpoints — CCDA, Letter, and Note — for document-shaped exchange on top of the resource-level FHIR API.

4★ How a Canvas client exports the raw payload

This is the central question for FHG, and Canvas answers it through the EHI Export capability, which implements the FHIR Bulk Data Access pattern. The export is standard FHIR R4 resources in newline-delimited JSON (NDJSON) — so the raw payload is the actual clinical record, resource by resource, not a flattened report.

4a · Single-patient export — via the UI

In admin settings, open Fhir bulk data exports → ADD FHIR BULK DATA EXPORT, pick the OAuth application (created during implementation), leave Export type as Patient, search the patient, and Start Export. Canvas generates per-resource output-file links. The capability is permission-gated — a user without the permission has their internal admins coordinate with Canvas support.

4b · Single-patient export — via the API

GET https://fumage-<instance-name>.canvasmedical.com/Patient/<id>/$export

<instance-name> is the customer’s Canvas instance; $export is the standard FHIR bulk-data operation.

4c · Population / all-patients export

For a group of patients or the entire instance, the requester contacts Canvas support with: instance name (URL), username, role, the patient group (or “all patients”), and the purpose. Canvas initiates the bulk export; output lands back in the same export table. Population exports can take significant time depending on instance data volume.

Resources included in the patient recordset

The EHI export scopes to the patient resource plus every resource associated with that patient — roughly 28 FHIR R4 resource types:

AllergyIntolerance · Appointment · CarePlan · CareTeam · Claim · Communication · Condition · Consent · Coverage · CoverageEligibilityResponse · Device · DiagnosticReport · DocumentReference · Encounter · Goal · Immunization · Media · MedicationDispense · MedicationRequest · MedicationStatement · Observation · Patient · Procedure · Provenance · QuestionnaireResponse · RelatedPerson · ServiceRequest · Specimen · Task

5The data model — three tiers of richness

Michael’s steer: “We need to navigate smartly to yield richer Canvas data.” Canvas exposes the same underlying record at three very different levels of fidelity. Knowing which tier you’re pulling is the whole game.

What “Deep Unified Architecture” means

The patient record is one normalized, versioned, referentially-intact model — with standard ontologies linked natively into the data, not bolted on after: LOINC (labs), ICD-10 (diagnoses), CPT (procedures), SNOMED-CT (clinical terminology), HCC / RAF (risk adjustment). A single query can move across conditions, labs, procedures, encounters, clinicians, and billing — native and real-time, where a legacy EHR needs an overnight report against stitched-together tables. This is precisely FHG’s wheelhouse — the ontology linkage is health-care-data domain knowledge.

The gap, stated plainly

The entire financial/RCM layer, the ADT feed, live care-gap state, reasons-for-visit, assessments, the inbound-document queue, and Command-level documentation (the native building blocks of nearly every Canvas workflow, captured as structured fields rather than free text) are Tier-2-only. For a value-based-care operator, that’s most of the value.

6★ The “navigate smartly” extraction strategy

The Data Module is read-only at plugin runtime, designed for in-instance compute, not a one-click bulk dump. To turn Tier-2 richness into an extract, someone builds a Canvas SDK plugin that queries the Data Module and emits the data on a schedule. Hence the division of labor:

FHG owns the WHAT (health-care-data semantics)

• Which Data Module models carry the signal for the clinical spine, prioritized.
• Which code systems / ValueSets matter (ICD-10, LOINC, CPT, HCC/RAF, SNOMED) and how to map them.
• What “richer” means clinically — Commands over rolled-up resources, ProtocolCurrent for care gaps, the full RCM layer, ADT via ExternalEvent.
• The target schema for downstream ingestion.

The engineering team owns the HOW

• Build the SDK plugin — a CronTask handler (scheduled) or a SimpleAPI endpoint — that reads the Data Module via the QuerySet API.
• Emit to a landing zone — the SDK ships an AWS S3 client and a C-CDA Export effect; NDJSON or Parquet to S3 is a natural target.
• Operate the pipe — incremental pulls, retries, monitoring.

7The Canvas ↔ Zus relationship

Canvas Medical and Zus have a strategic product partnership, and Zus ships a pre-built “Zus for Canvas” EHR integration. In a stack that runs both, Canvas is the system of record the clinicians work in, and Zus is the aggregation layer that pulls outside history (other EHRs, pharmacy, ADT, labs) around the patient. Complementary, not competing. See the Zus overview →

8Open questions for the Canvas transcript

• What can a Canvas client formally delegate to a trusted partner (FHG) — scope, OAuth app ownership, permissions?
• Does Canvas offer a sanctioned bulk Data-Module / warehouse export beyond per-plugin reads (a Snowflake-style share), or is the SDK plugin the only Tier-2 path?
• Plugin runtime limits — query volume, scheduled-job duration, sandboxing — at population scale.
• Incremental / delta export vs full snapshots — is there a change-feed?
• Attachment handling (Media / DocumentReference binaries) in the bulk output.
• Is the full structured Command payload retrievable historically, or only going forward?

9Sources

• Canvas Developer Docs — EHI Export
• Canvas Developer Docs — FHIR API Introduction
• Canvas Developer Docs — SDK Data Module
• Canvas Developer Docs — Commands Module
• Canvas — Deep Unified Architecture
• Canvas Medical and Zus — Strategic Product Partnership
• HL7 FHIR Bulk Data Access specification

Captured 2026-06-09. Re-validated quarterly against docs.canvasmedical.com. Cross-link target: the FHG Academy data-source track.