Medplum vs Legacy EHR Platforms: When to Make the Switch
If you are a healthcare technology leader evaluating your platform options in 2026, Medplum keeps coming up. It is open-source, FHIR-native, and built for developer teams rather than clinician end-users. But the decision to adopt Medplum — or to migrate to it from a legacy platform — is not straightforward. This article breaks down when Medplum is the right choice and when it is not.
What Medplum Actually Is
Medplum is an open-source healthcare development platform built around FHIR R4. Unlike traditional EHR systems (Epic, Cerner, athenahealth), Medplum does not include a pre-built clinician interface. Instead, it provides the backend infrastructure — a FHIR data store, access control, server-side automation (Bots), and APIs — and you build the user experience on top.
Think of it as the "headless CMS" approach applied to healthcare. You get the data layer and business logic; you own the UI.
| Aspect | Traditional EHR | Medplum |
|---|---|---|
| What you get | Complete clinician UI + workflows | Backend + APIs; you build the UI |
| Target user | Health systems, established practices | Developer teams, startups |
| Customization | Limited; vendor-driven roadmap | Unlimited; your codebase |
| Time to usable MVP | 12-24 months (implementation) | 3-6 months |
| Cost model | Per-provider or per-patient licensing | Usage-based or self-hosted |
| Interoperability | Vendor-managed FHIR APIs | Native FHIR R4 throughout |
| Data ownership | Vendor-hosted, contractual access | Full ownership (self-hosted option) |
When Medplum Is the Right Choice
1. You Are Building a New Digital Health Product
If you are a startup building a telehealth platform, a patient engagement app, or a care coordination tool, Medplum gives you a massive head start. Instead of building your own FHIR server, auth layer, and data model from scratch, you get a production-tested foundation.
The sweet spot: Series A/B companies with 3-10 engineers who need to move fast without building healthcare infrastructure from the ground up. Medplum handles FHIR compliance, access control, and data modeling while your team focuses on the user experience.
2. You Need Full Control Over the User Experience
Traditional EHRs give you a pre-built UI and limited customization. If your use case requires a fundamentally different clinical workflow — asynchronous care, remote monitoring, or non-traditional care delivery models — you will fight the EHR's UI paradigm rather than building what your users need.
Medplum lets you build exactly the interface your clinicians and patients need, using modern web technologies (React, TypeScript) rather than vendor-specific configuration tools.
3. You Are Migrating from a Platform That Does Not Scale
Some digital health platforms (Healthie, Canvas Medical, DrChrono) serve early-stage companies well but create limitations as you scale. Common breaking points include:
- API rate limits that constrain your growth
- Customization ceilings where the platform cannot support your workflow
- Cost scaling that becomes unsustainable at higher patient volumes
- Data portability issues when you need to move
Medplum gives you an escape hatch: full data ownership, no rate limits (self-hosted), and unlimited customization.
4. You Need Multi-Tenant or White-Label Architecture
If you are building a platform that serves multiple healthcare organizations, Medplum's access control model (AccessPolicy) supports multi-tenant architectures natively. Each organization sees only its own data, and you can customize the experience per tenant without running separate instances.
When Medplum Is Not the Right Choice
1. You Need a Complete EHR Out of the Box
If you are a medical practice that needs to chart patient visits, manage a schedule, process billing, and prescribe medications tomorrow, Medplum is not the answer. You need Epic, athenahealth, or a similar complete EHR. Medplum requires significant development effort before it is usable as a clinical system.
2. You Do Not Have a Developer Team
Medplum is a developer platform. If your organization does not have engineers who can build and maintain a React application, manage a PostgreSQL database, and operate a production web service, Medplum will create more problems than it solves.
Minimum team for a Medplum deployment:
- 1-2 full-stack engineers (TypeScript/React)
- 1 DevOps/infrastructure engineer (for self-hosted)
- Clinical input for workflow design
- Total: 2-4 people minimum, plus clinical advisors
3. You Need Epic/Cerner Integration and Nothing Else
If your primary need is to read data from Epic or Cerner via their FHIR APIs and display it in your application, you do not need Medplum. You need a well-built SMART on FHIR app. Medplum adds complexity (running your own FHIR server) that is unnecessary if you are purely consuming data from an existing EHR.
4. Regulatory Requirements Mandate a Certified EHR
Certain programs (Medicare reimbursement for in-person primary care, Meaningful Use) require ONC-certified EHR technology. Medplum is not ONC-certified. If your use case requires certification, you need a certified platform and can use Medplum as a supplementary data layer.
The Migration Path: Legacy to Medplum
If you have decided Medplum is right for your use case, here is what a migration looks like in practice.
Phase 1: Assessment (2-4 weeks)
- Inventory your current data model and map it to FHIR R4 resources
- Identify custom fields and extensions needed beyond standard FHIR
- Document integrations with external systems (labs, pharmacies, billing)
- Assess team readiness — do you have the TypeScript/React skills?
- Evaluate self-hosted vs. Medplum cloud deployment
Phase 2: Foundation (4-8 weeks)
- Deploy Medplum (cloud or self-hosted)
- Implement your data model with FHIR profiles and extensions
- Build the auth layer (AccessPolicy, identity management)
- Create the data migration pipeline from your legacy system
- Build the first critical workflow in the new UI
Phase 3: Migration (4-12 weeks)
- Execute data migration in stages (start with non-clinical data)
- Build remaining clinical workflows
- Implement external system integrations (labs, pharmacies, billing clearinghouses)
- Run parallel systems during transition period
- Validate data integrity between old and new systems
Phase 4: Go-Live and Optimization (2-4 weeks)
- Cut over production traffic
- Monitor for data quality issues
- Optimize performance under production load
- Decommission legacy system access
Total timeline: 3-7 months depending on complexity, team size, and the number of external integrations.
Cost Comparison Framework
| Cost Category | Traditional EHR | Medplum (Self-Hosted) | Medplum (Cloud) |
|---|---|---|---|
| Platform licensing | $500-2000/provider/month | $0 (open source) | Usage-based |
| Infrastructure | Included | $500-2000/month (AWS/GCP) | Included |
| Development | Configuration only | Full custom development | Full custom development |
| Implementation | $50K-500K (vendor-led) | $80K-250K (your team) | $60K-200K (your team) |
| Ongoing maintenance | Included in license | Your team's responsibility | Shared responsibility |
| Data portability | Contractual, often limited | Full ownership | Exportable |
The break-even point varies, but for organizations spending over $3,000/month on EHR licensing with significant customization needs, self-hosted Medplum often becomes cost-effective within 12-18 months.
The Comparison Landscape
Medplum is not the only alternative to legacy EHRs. Here is how it compares to other platforms in the space:
| Platform | Best For | Trade-off |
|---|---|---|
| Medplum | Developer teams building custom clinical apps | Requires engineering investment |
| Canvas Medical | Startups wanting an API-first EHR with UI | Less customizable than Medplum |
| Smile CDR | Enterprise FHIR servers for large organizations | Commercial licensing, complex setup |
| Google Healthcare API | Organizations already on GCP | No UI components, pure data layer |
| Healthie | Wellness and nutrition practices | Limited clinical depth |
Making the Decision
Ask yourself these questions:
- Do we have engineers who can build and maintain a React/TypeScript application? If no, Medplum is probably not right for you right now.
- Does our use case require a fundamentally different UI from traditional EHRs? If yes, Medplum gives you the freedom to build it.
- Are we hitting the ceiling of our current platform? If yes, and the ceiling is customization rather than features, Medplum is worth evaluating.
- Do we need ONC-certified EHR technology? If yes, Medplum cannot serve as your primary EHR for certification purposes.
- Is data ownership and portability important to us? If yes, Medplum's open-source model provides guarantees that vendor-hosted platforms cannot.
Evaluating Medplum for your organization? 1Putt Health has hands-on experience with Medplum architecture, migration planning, and FHIR platform selection. We help healthcare technology leaders make informed platform decisions and execute migrations successfully. Book a Discovery Call to discuss your specific situation, or download our free Medplum Migration Guide for a detailed playbook.