When Should You Use Canvas Medical’s Python SDK vs FHIR API?

If Medplum is the Rails of EHR and Oystehr is the serverless contender, Canvas Medical is the one that took a completely different approach: instead of giving you a FHIR server and saying “build everything,” Canvas gives you a working EHR and says “customize it.”

That’s a fundamentally different proposition. And for the right team, it’s the faster path to production.

The Out-of-Pocket Health analysis called Canvas “a bet on new EMRs.” We’d frame it slightly differently: it’s a bet that most clinical platform builders don’t want to build scheduling, charting, and billing from scratch. They want those out of the box and the ability to deeply customize the 20% that makes their platform different.

I. What is Canvas Medical and How Is It Different?

Canvas Medical is an AI-powered EHR platform designed primarily for primary care and value-based care organizations. But “EHR platform” undersells it. The real product is the customization layer.

What makes Canvas different from other headless EHR platforms:

• It’s a working EHR, not just infrastructure. When you sign up, you get scheduling, charting, billing, messaging, and a patient portal. Then you customize.
• Python SDK with plugins. Write Python programs that run inside the EHR server container. Not external webhooks. Not API polling. Your code executes synchronously with the EHR’s own processes.
• FHIR R4 API for external integrations — data access, third-party app connections, reporting
• Built-in payments and insurance reimbursement — billing isn’t an integration, it’s native
• AI-assisted plugin development — Canvas offers a Claude Code-powered plugin assistant that goes from idea to deployed plugin in minutes

Key specs:

• FHIR R4 compliant
• Python 3.11-3.13 for SDK development
• Pricing: Builder plan at $3,950/month, Enterprise custom
• ONC certified
• Open source plugin runtime environment

The mental model: Medplum and Oystehr give you a FHIR foundation and say, “build the EHR.” Canvas gives you the EHR and says, “extend it with code.” If your team is 80% satisfied with a commercial EHR and needs to customize the other 20%, Canvas is likely faster than building from scratch on Medplum.

II. What’s the Difference Between Canvas SDK and FHIR API?

Canvas gives you two customization paths. They solve different problems.

A. The Canvas SDK (Plugins): Modify the EHR from Inside

Plugins are Python programs that execute synchronously inside the Canvas server container. They react to events, read patient data, and return “effects” that alter workflows.

What plugins can do:

• React to clinical events — patient checks in, lab result arrives, medication prescribed, encounter opened
• Read patient data in real time — conditions, medications, allergies, care plans
• Return effects that change behavior — add a banner alert, modify a note, trigger a task, block an action with a reason
• Enforce business rules — “don’t allow this medication if the patient has this condition”
• Implement CDS logic — “flag this HCC code gap based on the patient’s diagnosis history”

Real use cases being built with plugins:

• Identify care gaps based on HCC coding and automatically trigger clinical workflows
• Convert AI scribe output into structured, command-based clinical notes
• Optimize ICD-10 diagnosis code selections in real time
• Auto-generate care plans based on condition combinations

Why this matters: On Medplum or Oystehr, achieving the same result means building a separate application that talks to the FHIR API from the outside. Canvas plugins run inside the EHR. The latency is lower, the integration is tighter, and the development model is simpler for Python teams.

B. The FHIR API: Access Data from Outside

Canvas also provides a standard FHIR R4 API for external access:

• Read patient demographics, encounters, observations, conditions, medications
• Write data from external sources (lab systems, devices, third-party apps)
• Bulk export for reporting and analytics
• Authentication via OAuth 2.0

When to use the FHIR API instead of SDK:

• Your integration is a separate application (mobile app, patient portal, analytics dashboard)
• You need data exchange with external systems (labs, pharmacies, HIEs)
• Your development team isn’t Python — the FHIR API is language-agnostic
• You need bulk data for population health or research

III. How Does Canvas Compare to Medplum and Oystehr?

Three platforms, three philosophies.

Our honest assessment: Canvas is the right choice when you want a production EHR today and need to customize workflows with Python, not build everything from scratch. The $3,950/month price includes scheduling, charting, billing, and patient portal, things that cost $100K-$200K to build on Medplum or Oystehr. The tradeoff: you’re customizing Canvas’s EHR, not building your own from scratch. If you need full architectural control and IP ownership, Medplum or Oystehr gives you that. If you need a working EHR with deep customization hooks, Canvas gets you there faster.

For the complete headless EHR comparison, including all platforms, see our earlier guide.

IV. What Should Builders Know Before Starting with Canvas?

Practical notes from evaluating the platform:

• Python-first, no exceptions for SDK. If your engineering team writes TypeScript, the plugin system requires a language switch. The FHIR API is language-agnostic, but the deep customization — the part that makes Canvas worth choosing — is Python only. Python 3.11-3.13 required.
• The plugin model is event-driven. You define which events your plugin listens to (encounter created, medication prescribed, lab result received), what data to read, and what effects to return. If you’ve built event-driven systems (Kafka consumers, Lambda triggers, webhook handlers), the mental model will feel familiar.
• Canvas CLI for deployment: Install via pip install canvas. The CLI handles plugin packaging, deployment, and testing. Canvas also offers an AI-assisted development path using Claude Code that can generate plugin scaffolding from a natural language description.
• $3,950/month is the floor for production: The Builder plan includes the full EHR, SDK access, and FHIR API. Enterprise pricing is custom for larger deployments. Compare:
  • Canvas: $3,950/month includes EHR + scheduling + charting + billing + portal
  • Medplum Cloud: ~$2K/month does not include any EHR UI – you build everything
  • Oystehr: ~$500/month at startup volume does not include any EHR UI

The Canvas price includes what you’d spend $100K+ building on other platforms. Factor that into total cost calculations.

• Primary care and VBC are the sweet spot. Canvas was designed for primary care workflows and value-based care models. If your use case is primary care, VBC, or a direct primary care (DPC) model, Canvas’s out-of-the-box workflows will cover 80%+ of what you need. If your use case is highly specialized (fertility, home health, oncology), you may be fighting Canvas’s assumptions rather than benefiting from them.