What is Oystehr and Should You Build Your EHR on It?

The headless EHR space has four serious players now. Medplum is the most mature (20M+ patients, Apache 2.0, ONC certified). Healthie owns the wellness and nutrition segment. Canvas Medical appeals to Python teams. And then there’s Oystehr – the newest, the most aggressive on FHIR version support, and the only one with truly usage-based pricing.

We’ve been tracking Oystehr since its ZapEHR days. When they announced ONC certification (July 2024) and rebranded, it became clear they were serious about the clinical platform infrastructure market, not just a developer experiment.

This is the first external architecture guide for Oystehr. Here’s what we’ve found.

I. What is Oystehr and Where Did It Come From?

A. Quick naming history

• ZapEHR – the original name for the cloud platform
• Oystehr – the current brand for the headless cloud service (backend infrastructure)
• Ottehr – the open-source frontend EHR built on Oystehr (think: Medplum’s React components, but as a full production-ready EHR application)

The distinction matters: Oystehr is the backend-as-a-service (paid, usage-based). Ottehr is the open-source frontend (free, fork and modify). You can use Oystehr’s backend with Ottehr’s frontend, with your own custom frontend, or with both.

B. What Oystehr provides

• Hosted FHIR data store (R4, R4b, and R5 – the most advanced FHIR versions support of any headless EHR platform)
• Authentication and authorization
• ONC-certified health IT (13 criteria, certified July 16, 2024), including (g)(10) Standardized API lets patients pull their data into third-party apps, the cornerstone of the Cures Act anti-info-blocking rules and (b)(10) EHI Export full patient record export on demand
• HIPAA-compliant infrastructure
• Serverless architecture – auto-scaling, no infrastructure management
• Medical services: e-prescribing, insurance eligibility, RCM, lab/imaging orders
• Communication: SMS, chat, video, fax
• Zambdas – serverless functions (Oystehr’s equivalent of Medplum Bots or AWS Lambda)

C. What makes it different from Medplum

• FHIR R5 native. Medplum is R4. Oystehr supports R4, R4b, and R5. If you need R5 resources today, Oystehr is your only ONC-certified option.
• Usage-based pricing. Medplum Cloud is ~$2K/month flat. Oystehr charges per API call, per MAU, per GB. For early-stage startups with low volume, Oystehr can cost significantly less.
• Serverless architecture. Built on serverless from the ground up. No container management, no scaling configuration.
• Medical services built in. ePrescribe, insurance eligibility checks, RCM, lab orders – native to the platform. Medplum requires external connectors for these.

II. What Does Oystehr’s Pricing Actually Look Like?

This is the section everyone wants, and nobody publishes clearly. Here’s Oystehr’s actual pricing as of April 2026:

A. Core Usage Costs

B. Medical Services (Silver+ plan required)

C. Communication

D. Support Tiers

• Bronze: $100/month (sandbox + basic)
• Silver: $1,000/month or 5% of usage (whichever is greater) – required for production medical services
• Gold: $5,000/month or 5% of usage – priority support
• Enterprise: Custom

Real cost math for a startup: 500 MAUs, 100K API calls/month, 10GB database, 5 providers with ePrescribe, Bronze support:

1. Users: $125
2. API: $100
3. Database: $1
4. ePrescribe: $175
5. Support: $100

Total: ~$501/month

Compare to Medplum Cloud at ~$2,000/month flat. For an early-stage startup with low volume, Oystehr can be 75% cheaper. The crossover point, where Medplum’s flat rate becomes cheaper, depends on your MAU and API call volume. At ~2,000 MAUs and 2M API calls, the costs converge.

III. How Does Oystehr Compare to Medplum and Healthie?

Our honest take: Oystehr has the most advanced FHIR support and the lowest entry cost. Medplum has the most mature ecosystem, a larger community, and full source code ownership (Apache 2.0). If you need FHIR R5 today, Oystehr is your only ONC-certified option. If you need full source code control and self-hosting, Medplum wins. If you need wellness/telehealth fast with minimal dev, Healthie wins.

For the full headless EHR comparison, including OpenEMR, we published a detailed comparison earlier.

IV. When Should You Choose Oystehr?

A. Oystehr is the right choice when:

1. You need FHIR R5 resources; Oystehr is the only ONC-certified platform that supports R5 natively. If your clinical data model requires R5 features (e.g., SubscriptionTopic for advanced event filtering, improved Encounter and CareTeam resources), Oystehr is currently the only compliant path.
2. You’re pre-revenue or very early-stage: Usage-based pricing means you can build and test with dollars, not thousands. A prototype running 10K API calls costs $10, not $2K.
3. You want medical services without integration work: ePrescribe, insurance eligibility, RCM, and lab orders are native. On Medplum, you’d connect these through external services.
4. You prefer serverless: No Docker, no Kubernetes, no container management. Oystehr’s serverless architecture scales automatically. If your team doesn’t have DevOps experience, this removes a major layer of complexity.
5. You want ONC certification out of the box: Systems built on Oystehr inherit this certification.

B. Oystehr is probably not the right choice when:

• You need full source code ownership – Oystehr’s backend is proprietary. Medplum (Apache 2.0) gives you the entire codebase.
• You need self-hosting for data sovereignty – Oystehr is cloud-only. Medplum can be self-hosted on your AWS/Azure/GCP.
• You need a large developer community for support – Oystehr is early. Medplum has 2,100+ stars and an active Discord.
• Your volume is high enough that flat-rate pricing is cheaper – at scale, Medplum’s ~$2K/month beats Oystehr’s per-call pricing.
• You need the deepest ONC certification coverage – Medplum has 19 criteria vs Oystehr’s 13.

V. What Should Builders Know Before Starting?

A few practical notes from evaluating the platform:

• Zambdas (serverless functions) are Oystehr’s equivalent of Medplum Bots. They run server-side logic in response to events. Same concept, different execution model (serverless vs container). If you’ve written Lambda functions, you’ll find Zambdas familiar.
• Ottehr (open-source frontend) is production-ready – it includes intake, scheduling, and telehealth modules. You can fork it as your starting point and customize, or build a completely custom frontend against Oystehr’s APIs. We’d recommend starting with Ottehr for internal tools and building custom for patient-facing experiences.
• The FHIR R5 advantage is real but nuanced. R5 has better resource definitions for some clinical domains (improved Encounter, CareTeam, SubscriptionTopic). But US Core is still on R4 (with R6 coming, not R5). If your target market is US providers needing certified EHR tech, R4 compliance is what matters today. R5 becomes strategic for forward-looking builds.
• Medical services pricing can add up. ePrescribe at $35-$45/provider/month for 50 providers is $1,750-$2,250/month just for that service. Budget medical services separately from platform infrastructure.

If you’re evaluating Oystehr for a specific clinical platform build, we can help scope the architecture and compare it against a Medplum-based approach. The right platform depends on your FHIR version needs, hosting requirements, pricing model preference, and whether source code ownership matters. Tell us about your use case.