Canvas Medical takes a different approach from most EHRs. Beyond a standards-based FHIR API, it lets organizations write Python plugins that run inside the EMR itself, customizing workflows, interfaces and integrations. For care delivery companies and digital health teams, that means Canvas can be shaped around their care model rather than the other way around. This guide explains both integration paths, when to use each and how to build reliably on Canvas. For broader EHR connectivity, see our EHR and EMR integration services. Building on Canvas? Request a free architecture review.
Canvas’s Two Integration Pathways
Canvas describes itself as an ONC-certified EMR with two main programmatic pathways: the FHIR API for interoperability and the Canvas SDK for deep customization. Most serious Canvas implementations use both, choosing the right tool for each requirement rather than forcing everything through one interface.
The Canvas FHIR API
The FHIR API is a standards-based REST interface built on HL7 FHIR, covering many resources with a substantial number writable. It suits integrations with external systems, data synchronization and applications that need portable, standards-based access to Canvas data. Confirm current resource coverage in documentation.
The Canvas SDK
The Canvas SDK lets developers write Python plugins that execute within the EMR environment. Plugins respond to events, read data and apply changes, enabling deep customization of workflows, user interface elements and integrations that external APIs alone cannot achieve. Plugins should be treated as production code.
Choosing between them
Use the FHIR API when external systems need to exchange data with Canvas. Use the SDK when you need to change how Canvas behaves for users, such as adding alerts, automating tasks or customizing documentation. Many projects combine both approaches thoughtfully.
Authentication
Canvas uses OAuth for its FHIR API, and the Canvas command line interface uses OAuth as well. Developers register a third-party application to obtain a client ID and secret. Store these credentials securely and manage them separately for each environment.
How Canvas Plugins Work
The SDK’s plugin model is what makes Canvas distinctive. Understanding its core concepts helps teams design plugins that are reliable, maintainable and safe for clinical use, rather than accumulating scattered customizations that become difficult to support.
Events, data and effects
Canvas describes three foundational plugin concepts. Events trigger plugin logic, such as a note being updated. Data provides read-only access through defined models. Effects are typed payloads that apply changes or control the user interface, such as creating tasks or banner alerts.
Read-only data through stable models
Plugins read data through SDK data models built on the Django ORM, which makes filtering and navigating relationships straightforward. Canvas notes these views provide a stable interface, so internal database changes do not break plugins that rely on the documented models.
Custom APIs inside plugins
The SDK lets developers define HTTP and WebSocket APIs within plugins. This allows external systems to call custom endpoints that run plugin logic inside Canvas, opening integration patterns beyond standard FHIR, such as tailored synchronization or specialized workflow triggers. Secure these endpoints carefully.
Command line deployment
Developers install the Canvas command line interface using Python package tools, then use it to develop and deploy plugins to Canvas instances. Treat plugins like production software, with version control, code review, automated tests and controlled deployment practices. Document every deployment for traceability.
Common Canvas Use Cases
Canvas attracts organizations building differentiated care models, such as virtual-first primary care, specialty programs and value-based care. The use cases below show how teams combine the FHIR API and SDK to support these models effectively.
Custom clinical workflows
Plugins can add protocol cards, banner alerts, tasks and documentation helpers tailored to specific care models. This lets organizations guide clinicians through their unique pathways inside the EMR, improving consistency without forcing staff to switch between separate tools. Validate each change with clinicians first.
Embedded SMART on FHIR apps
Canvas documents guides for embedding SMART on FHIR apps within its interface. This lets organizations add specialized tools with patient context. Our SMART on FHIR app development team builds apps designed for embedded clinical use. Each app is tested inside Canvas with real clinicians before launch.
Event-driven external integrations
Plugins can make automatic API requests when Canvas events occur, such as notifying external systems after a visit is signed. This enables near real-time integrations with labs, billing platforms, care management tools and analytics systems without constant polling. Log every outbound call for troubleshooting.
Patient portal customization
Canvas documents SDK capabilities for customizing the patient portal, including launching applications and adding widgets. Organizations can tailor patient experiences to their care model, keeping patients engaged through features aligned with their specific programs and services. Test features with patients before full rollout.
Building Reliably on Canvas
Flexibility brings responsibility. Plugins run inside the EMR and affect clinical workflows directly, so engineering discipline matters as much as speed. The steps below reflect how we deliver Canvas projects for care delivery organizations.
Step 1: Design around the care model
Start by mapping your care model, clinical workflows and data flows. Decide which needs belong in Canvas configuration, which need plugins and which need FHIR integrations. A clear design prevents duplicated logic and conflicting customizations later. Review this design with clinical leaders.
Step 2: Set up development environments
Install the Canvas command line interface, register applications for credentials and configure separate development and production instances. Use version control for every plugin, and establish code review practices before writing significant clinical logic. Keep credentials separate for each environment and restrict who can access them.
Step 3: Build and test plugins
Develop plugins using documented events, data models and effects. Write automated tests for logic, and test with realistic clinical scenarios in non-production instances. Pay special attention to performance, because plugins run within clinician workflows. Document expected behavior for every plugin before deploying it.
Step 4: Integrate external systems
Use the FHIR API and plugin-defined APIs to connect labs, billing, analytics and partner systems. Handle authentication, retries and error logging carefully. Monitor integrations so failures are detected quickly rather than discovered by clinicians. Document each integration’s owner and escalation path for support teams.
Step 5: Deploy, monitor and iterate
Deploy plugins through controlled releases, monitor behavior and gather clinician feedback. Track Canvas product updates and SDK changes, testing plugins before upgrades. Continuous improvement keeps customizations aligned with evolving care models and platform capabilities. Share release notes with clinicians so they understand every change.
Limitations and Considerations
Canvas’s flexibility is powerful, but it changes the responsibilities of the organizations using it. Understanding these considerations early helps teams staff appropriately and avoid customizations that become difficult to maintain as programs grow.
Engineering ownership
Plugins are code your organization owns and maintains. You need developers with Python skills, testing practices and clinical workflow understanding. Budget for ongoing maintenance, not just initial development, because care models and platform capabilities keep changing. Assign clear owners for every plugin.
Clinical safety review
Plugins that alert clinicians, create tasks or modify documentation affect patient care. Establish clinical review for every plugin before deployment. Document intended behavior, test edge cases and monitor real-world use to catch unintended consequences quickly. Keep records of every review decision.
Customization sprawl
Without governance, plugins can multiply into overlapping or conflicting logic. Maintain an inventory, assign owners and retire unused plugins. Regular reviews keep the system understandable for new team members and reduce the risk of unexpected interactions. Quarterly reviews work well for most teams.
Interoperability with partners
External partners may expect HL7 v2 or FHIR rather than custom APIs. Use Canvas’s FHIR API where partners support it, and plan engine-based interfaces for HL7 partners. Our FHIR and HL7 integration services bridge these needs. Plan these interfaces early in your roadmap.
How Taction Helps Organizations Building on Canvas
Taction has delivered 200+ healthcare projects, including EHR integrations, clinical workflow tools and virtual care platforms. We help care delivery organizations design Canvas architectures, build reliable plugins and connect Canvas to their wider ecosystem securely.
Free Canvas architecture review
Share your care model and Canvas plans. We review workflows, plugin designs and integrations, recommend where to use the FHIR API versus the SDK, and flag risks early. You receive a practical roadmap. Request your free review. We also flag quick wins you can start immediately.
Plugin development and testing
We build Canvas plugins with clinical input, automated tests and controlled deployment practices. Every plugin is documented, reviewed and monitored, ensuring customizations stay reliable and understandable as your organization and care model grow. We also train your team to maintain plugins confidently after handover.
Python developers for Canvas
Canvas plugins are written in Python. You can hire healthcare Python developers who understand clinical workflows, FHIR and healthcare security requirements. They accelerate plugin development and strengthen your internal engineering team. Engagements scale with your roadmap, from a single plugin to a full customization program.
Startup and scale-up support
Many Canvas customers are growing care delivery companies. Our healthcare software development for startups services provide product, design and engineering support that keeps pace with rapid growth while maintaining compliance. Engagements scale with your growth, from early care model design on Canvas to a mature platform serving many patients.
Frequently Asked Questions
These answers address common questions about integrating with and building on Canvas Medical. Because Canvas’s SDK and APIs evolve, confirm current capabilities in Canvas’s developer documentation when planning your project.
Does Canvas Medical have an API?
Yes. Canvas offers a standards-based FHIR API for interoperability and the Canvas SDK, which lets developers write Python plugins that run inside the EMR. Many organizations use both, depending on whether they need data exchange or workflow customization. Each serves different needs.
What is the Canvas SDK?
The Canvas SDK lets developers build Python plugins that respond to events, read data through stable models and apply changes through effects. Plugins can customize workflows, user interface elements, patient portal features and integrations directly within Canvas. Plugins should follow strong engineering practices.
Should I use the FHIR API or the SDK?
Use the FHIR API when external systems need to exchange data with Canvas in a standards-based way. Use the SDK when you need to change how Canvas behaves for users. Complex projects typically combine both approaches. Document the choice for each requirement.
Can Canvas embed SMART on FHIR apps?
Yes. Canvas documents guides for embedding SMART on FHIR applications within its interface, letting organizations add specialized tools with patient context. This supports care models that rely on third-party or custom clinical applications. Test embedded apps with clinicians before launch to confirm fit.
What skills do teams need to build on Canvas?
Teams need Python development skills, familiarity with FHIR, testing discipline and understanding of clinical workflows. Clinical safety review and governance processes are also important, because plugins directly influence how clinicians work and care for patients. Training helps teams start faster.