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 (Apache 2.0, ONC-certified). Our Medplum data infrastructure guide covers how its FHIR-native backend is structured.  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 got an ONC certification listing and rebranded, it became clear they were serious about the clinical platform infrastructure market, not just a developer experiment.

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)
• Authentication and authorization
• An ONC Health IT certification listing (check CHPL for the criteria it currently covers before you rely on any one of them). 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 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 the only platform here with native R5 support
• Usage-based pricing. Medplum Cloud charges a monthly plan fee that includes a usage allowance (Medplum pricing). 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 published pricing as of October 2026, from its pricing page:

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:

Total: Depends on usage. Model it on Oystehr’s pricing page before you commit.

Compare that with Medplum Cloud, whose Production plan starts at $2,000/month as of October 2026 (Medplum pricing). For an early-stage startup with low volume, Oystehr can cost less. 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?

Oystehr is currently the only native path. If you’re still mapping your overall EHR modernization approach, our EHR modernization guide covers all platform options by clinical need.

A. Oystehr is the right choice when:

1. You need FHIR R5 resources; Oystehr is the only platform here 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 native path
2. You’re pre-revenue or very early-stage: Usage-based pricing means you can build and test with dollars, not thousands.
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.

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 a larger open-source community and an active Discord.
• Your volume is high enough that a monthly plan is cheaper – at scale, Medplum’s plan pricing can beat Oystehr’s per-call pricing.

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 is billed per provider per month, so it grows with your provider count. 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.