Written and maintained by CASRAI Editorial Board
Last updated
Canvas Medical (canvasmedical.com), alongside Medplum and Aidbox (by Health Samurai), represents a generation of developer-first, API-driven electronic health record (EHR) platforms designed for programmable care delivery, digital health clinics, and clinical research informatics. Whereas monolithic legacy hospital EHRs such as Epic and Oracle Health couple proprietary database schemas tightly to fixed desktop interfaces, programmable and headless EHR platforms expose HL7 FHIR resources, event streams, and software development kits (SDKs) as first-class engineering primitives.
What Is Canvas Medical and What Is a Headless EHR Architecture?
Canvas Medical is an ONC-certified ambulatory EHR and practice management platform headquartered in San Francisco, California. Canvas combines a complete clinician-facing charting and medical billing user interface with a programmable backend composed of two primary developer interfaces:
- The Canvas SDK (Python Plugin Runtime): Engineering and clinical informatics teams write Python plugins (`canvas-sdk`) that subscribe to real-time clinical and operational event hooks inside the EHR (such as note creation, vital sign entry, diagnosis coding, lab result receipt, or questionnaire completion). Plugins return effects that dynamically insert clinical decision support (CDS) protocol cards, pre-populate orders, enforce research eligibility checks, or automate task routing directly inside the clinician’s charting view.
- ONC-Certified HL7 FHIR R4 API: Listed on the ASTP/ONC Certified Health IT Product List (CHPL) under 45 CFR § 170.315(g)(10), Canvas exposes standardized HL7 FHIR R4 endpoints (`Patient`, `Encounter`, `Condition`, `Observation`, `MedicationRequest`, `QuestionnaireResponse`, `Task`, `Coverage`, `Claim`) to drive custom patient portals and mobile applications.
A headless EHR architecture takes this separation one step further: it provides the regulated clinical backend—FHIR data storage, HIPAA audit logging, role-based access control, e-prescribing (Surescripts), laboratory ordering, and HIE connectivity—without locking the organization into a predetermined frontend user interface. Organizations can run Canvas Medical in a hybrid or headless configuration (using the Canvas charting UI for clinicians while driving custom patient/care-coordinator frontends via FHIR and the Canvas SDK) or adopt a pure headless FHIR platform such as Medplum or Aidbox.
How to Build and Operate Workflows on Programmable & Headless EHR Platforms
Based on the official developer documentation for Canvas Medical (docs.canvasmedical.com), Medplum (medplum.com/docs), and Aidbox (docs.aidbox.app), clinical engineering teams deploy custom clinical or research workflows across six steps:
- Provision a Sandbox or Self-Hosted FHIR Instance: Developers initialize a dedicated Canvas development instance (`canvas-cli`) or spin up a local Dockerized PostgreSQL + FHIR server using Medplum or Aidbox.
- Model Clinical Questionnaires and Data Profiles: Define intake instruments, clinical trial screening forms, and assessment scales as standard HL7 FHIR `Questionnaire` resources paired with terminology value sets (SNOMED CT, LOINC, ICD-10-CM, RxNorm).
- Configure OAuth 2.0 / SMART on FHIR Access Policies: Register client applications and configure granular resource-level access control policies (such as Medplum `AccessPolicy` resources or Aidbox `AccessPolicy` engines) enforcing HIPAA minimum-necessary rules per user role.
- Write Event-Driven Clinical Automation (SDK Plugins or FHIR Bots): Implement server-side automation logic—using Python `Protocol` classes in the Canvas SDK or TypeScript/JavaScript `Bot` functions triggered by FHIR `Subscription` webhooks in Medplum—to evaluate incoming `Observation` or `QuestionnaireResponse` payloads and generate automated follow-up tasks or orders.
- Connect Diagnostic Laboratories, e-Prescribing, and HIE Aggregators: Bind order/result routing to national laboratory interfaces (HL7 v2 ORU/ORM or FHIR `ServiceRequest`/`DiagnosticReport`), e-prescribing networks, and external clinical aggregators such as Zus Health or Health Gorilla.
- Deploy and Monitor Audit Logs (`AuditEvent`): Promote tested plugins or bots to production while recording every read, write, and automated decision in immutable HL7 FHIR `AuditEvent` logs for HIPAA and clinical trial governance.
How Do Medplum and Aidbox Use FHIR as Their Native Database Schema?
Legacy EHRs store clinical records in thousands of proprietary relational tables and run an external translation layer whenever an API caller requests an HL7 FHIR resource—a pattern that introduces mapping latency and limits write-back capabilities. In contrast, Medplum and Aidbox (by Health Samurai) use a FHIR-native PostgreSQL architecture:
- Medplum’s PostgreSQL + JSONB Architecture: Medplum is an open-source (`Apache-2.0` licensed) headless EHR built in TypeScript and Node.js on top of PostgreSQL. Every FHIR R4 resource type (`Patient`, `Observation`, `Encounter`, etc.) is stored natively as validated JSON inside a PostgreSQL `JSONB` column (`content`), accompanied by a companion `History` table tracking every immutable resource version (`versionId`) and dedicated search-parameter lookup tables that index FHIR search parameters for fast SQL execution.
- Aidbox’s Native JSONB & SQL-on-FHIR Engine: Developed by Health Samurai (health-samurai.io), Aidbox stores FHIR resources (supporting FHIR STU3, R4, and R5 plus custom Implementation Guides) directly as binary JSON (`JSONB`) in PostgreSQL with functional GIN and B-tree indexes. Because the underlying storage is native PostgreSQL without an object-relational impedance mismatch, data scientists and clinical informaticists can run standard ANSI SQL and SQL-on-FHIR analytical queries directly against millions of FHIR resources in real time.
Comparison Table: Canvas Medical vs. Medplum vs. Aidbox vs. OpenEMR
| Platform | Licensing & Core Stack | Database & API Architecture | Clinician UI & ONC Certification Status |
|---|---|---|---|
| Canvas Medical | Commercial SaaS; Python SDK (`canvas-sdk`), Django/PostgreSQL | Relational EHR core with bidirectional HL7 FHIR R4 API and real-time Python event-driven plugin SDK. | Full turnkey ambulatory charting & RCM UI included; ONC 45 CFR § 170.315 certified complete EHR. |
| Medplum | Open-source (`Apache-2.0`) + Managed Cloud; TypeScript, Node.js, React, PostgreSQL | FHIR-native PostgreSQL (`JSONB`), FHIR `Subscription` webhooks, server-side TypeScript `Bots`, and GraphQL. | Headless backend + modular React UI component library (`@medplum/react`); ONC 45 CFR § 170.315 certified. |
| Aidbox (Health Samurai) | Commercial (Self-hosted Docker/Kubernetes or Cloud); Clojure/PostgreSQL | FHIR-native PostgreSQL (`JSONB`) supporting FHIR STU3/R4/R5, terminology server, custom IGs, and SQL-on-FHIR. | Pure headless FHIR backend & database platform; includes ONC § 170.315(g)(10) certified API module. |
| OpenEMR | Open-source (`GNU GPL`); PHP, MySQL / MariaDB | Traditional relational LAMP-stack schema with built-in HL7 FHIR R4 and SMART on FHIR API layer. | Full traditional web EHR & practice management UI; ONC 45 CFR § 170.315 certified. |
Strengths and Limits of Developer-First and Headless EHRs
- Strengths:
- Rapid Custom Clinical & Research Workflow Engineering: Enables digital health organizations and clinical trial networks to embed protocol-specific decision support, automated eligibility screening, and custom participant apps directly into the clinical record.
- Standards-First Data Portability: Native HL7 FHIR R4 storage and SQL-on-FHIR capabilities eliminate proprietary data lock-in and simplify real-world data (RWD) extraction.
- Limits:
- Software Engineering Overhead: Pure headless platforms (Medplum and Aidbox) require dedicated frontend and backend engineering teams to build, validate, and maintain clinician-facing interfaces, whereas Canvas Medical provides a ready-to-use charting UI that still requires Python engineering for custom SDK plugins.
- Outpatient vs. Acute Inpatient Scope: These platforms target ambulatory care, specialty clinics, telehealth, laboratory workflows, and clinical trials rather than high-acuity inpatient hospital bed management or operating room anesthesia systems.
Frequently Asked Questions
What is a headless EHR architecture?
A headless EHR architecture decouples the backend clinical data repository, HL7 FHIR API layer, identity and access management (OAuth 2.0 / SMART on FHIR), audit logging, and health information exchange (HIE) integrations from the frontend user interface. This allows clinical informatics and digital health engineering teams to build custom clinician dashboards, patient portals, or decentralized clinical trial workflows on top of an ONC-certified backend.
How does Medplum use FHIR as its native database schema?
Unlike legacy EHRs that store data in proprietary relational tables and translate to FHIR on the fly, Medplum is FHIR-native: every clinical and operational object is validated and stored directly as an HL7 FHIR R4 resource inside PostgreSQL using JSONB columns paired with indexed relational search-parameter lookup tables and resource version history tables.
How do developer-first platforms like Medplum, Canvas Medical, and Aidbox compare?
Canvas Medical is a commercial, ONC-certified programmable ambulatory EHR featuring a clinician charting UI, revenue-cycle management, and a Python-based plugin SDK for custom clinical workflows. Medplum is an open-source (Apache-2.0) headless EHR and developer platform built on TypeScript, React components, and a PostgreSQL FHIR R4 data store with ONC certification. Aidbox (by Health Samurai) is an enterprise FHIR-native backend and database platform built on PostgreSQL supporting FHIR R4/R5, custom Implementation Guide profiling, and SQL-on-FHIR analytics.
Sources
- Canvas Medical — Official FHIR API and Python Canvas SDK Documentation (docs.canvasmedical.com).
- Medplum — Open-Source Headless EHR Architecture, PostgreSQL FHIR Storage, and ONC Certification Documentation (medplum.com/docs).
- Health Samurai — Aidbox FHIR Platform, PostgreSQL JSONB Schema, and SQL-on-FHIR Documentation (docs.aidbox.app).
