Open Source EHR: OpenEMR vs Medplum vs Oystehr, and When to Build Instead

I’ve built on OpenEMR’s twenty-four-year-old codebase and I’ve built on Medplum’s two-year-old FHIR-native stack, and the honest answer to “which open source EHR should we use” is that you’re usually choosing between two different questions, not two competing answers to the same one.

One question is “which finished product can my staff start using this quarter.” The other is “which platform can my engineers build a specific clinical product on top of.” OpenEMR answers the first. Medplum answers the second. Oystehr answers a narrower version of the second, for teams building a specialty product rather than a general EHR. Confuse the two questions and you’ll pick the wrong platform no matter how carefully you read the feature list.

I’m writing this because the searches for “open source EHR” outnumber almost everything else in this cluster, and the pages that rank for it don’t actually help you decide. Vendor sites sell one platform each. Listicle roundups name five or six tools with no build proof behind any of them. Nobody’s put a federally qualified health center’s constraints and an international health ministry’s constraints on the same page and worked through what each one should actually do. That’s what this is.

If you already know you want the deep OpenEMR implementation detail, our full OpenEMR implementation guide covers the 7-step rollout. If you want the broader technical comparison across five headless platforms, our headless EHR comparison of Medplum, Healthie, OpenEMR, Oystehr, and Canvas goes deeper on architecture than I will here. This piece sits above both. It’s the landscape and the decision, not the implementation manual.

What Counts as an Open Source EHR in 2026?

An open source EHR is a clinical records platform whose source code is publicly available under a license (usually GPL, MPL, or Apache 2.0) that lets you host it, modify it, and extend it without paying license fees to a vendor for the base software.

That’s the whole definition. It doesn’t mean free to run. It doesn’t mean unsupported. And it doesn’t mean one category of product. In practice, “open source EHR” in 2026 covers three genuinely different things: monolithic ready-made systems you install and use (OpenEMR, OpenMRS, GNU Health), FHIR-native developer platforms you build a product on top of (Medplum), and specialty-scoped developer platforms built for one clinical use case (Oystehr, formerly branded Ottehr, for pediatric urgent care and virtual-first workflows).

You (yes, you, reading this because someone asked you to evaluate “open source options”) need to know which of those three you’re actually shopping for before you compare a single feature. Most comparison content skips this and jumbles all three together under one column of checkmarks. That’s the first thing wrong with almost everything else ranking for this term.

The Three Platforms That Actually Matter: OpenEMR, Medplum, and Oystehr

Three platforms come up in every serious open source EHR conversation I’ve had in the last two years. Not five, not twelve. OpenEMR, Medplum, and Oystehr. OpenMRS and GNU Health matter for specific geographies and I’ll cover them separately below, but they don’t compete for the same buyer as these three.

Source: OpenEMR project documentation (open-emr.org), Medplum documentation (medplum.com), Oystehr documentation (oystehr.com). Compiled 2026-07-31. (Verify ONC certification status and license terms at publish, as these change.)

The distinction that matters most isn’t in the table. It’s this: OpenEMR gives you an EHR. Medplum and Oystehr give you the plumbing to build one. If your FQHC needs staff logging into a system by next quarter, OpenEMR is the only one of the three that gets you there without a development team. If you’re building a Series A digital health product where the EHR is your differentiation, OpenEMR will fight you at every customization point, and Medplum or Oystehr is the right foundation.

I’d add a fourth axis nobody puts in these tables: who actually maintains momentum. OpenEMR ships regular releases through an active community, most recently version 8.0.0. Medplum publishes a public roadmap and merges community PRs weekly. Oystehr is the youngest and the one where you should ask hardest about long-term maintenance commitment before you build on it. None of the three are going away in the next 18 months. Only two of them have a decade-plus track record.

If your evaluation stops here, you’re not the reader this piece is for. Most teams need a Request an Assessment conversation to figure out whether their specific workflow, patient volume, and compliance posture point toward OpenEMR, Medplum, or something custom entirely. That’s a 45-minute conversation, not a feature checklist. Start a Conversation with our team if you want that conversation before you commit budget.

OpenEMR: The 24-Year-Old Workhorse

OpenEMR is the platform most people mean when they say “open source EHR” without qualification. It runs on PHP and MySQL, it’s been through four major architectural eras since 2001, and it powers more than 5,000 documented installations covering an estimated 30 million patients worldwide (per OpenEMR’s own project documentation, verify at publish for current figures). That’s not a small deployment base. It’s larger than most commercial EHR vendors serving the ambulatory market.

Version 8.0.0 shipped February 11, 2026 (OpenEMR release documentation, verify exact release date at publish), twenty-four years after the project’s original release. That’s the detail I keep coming back to when people ask if OpenEMR is “still maintained.” Twenty-four years is longer than most commercial EHR vendors have existed as companies. The codebase carries real technical debt from that history. It also carries something almost no newer platform has: two decades of edge cases already discovered and patched by other people’s production deployments.

I’m not going to re-walk the full implementation process here. We’ve already published the 7-step version of that, with FQHC and international deployment specifics, in our full OpenEMR implementation guide. What I want to flag here, because it doesn’t show up in most comparison content, is the honest maintenance-burden conversation.

Source: OpenEMR project (open-emr.org) release notes and community documentation, accessed 2026-07-31.

Here’s the reluctant opinion. OpenEMR’s installer looks approachable enough that a lot of small practices attempt self-hosting without a partner. Some of them succeed. More of them end up on Reddit and Capterra a year later describing exactly the same problem: the software works, but there’s no vendor support line to call when a plugin conflicts with a PHP version upgrade, and “you’re more or less on your own” is the recurring phrase in the reviews I’ve read (verify at publish, specific review sourcing to confirm). That’s not a knock on OpenEMR. That’s the actual trade you’re making with any self-hosted open source system, and it’s the reason most FQHCs and community health centers that run OpenEMR successfully long-term have a hosting or implementation partner, not a solo IT admin.

Medplum: FHIR-Native and Built to Extend

Medplum is a different animal entirely, and if you came here expecting a feature-by-feature comparison against OpenEMR, that’s your first sign you’re evaluating the wrong axis. Medplum isn’t trying to be an EHR you install. It’s a FHIR-native backend and a set of React component libraries you build your actual product on top of.

Every resource in Medplum is a native FHIR R4 resource from the ground up, not a custom schema with a FHIR export layer bolted on afterward. That distinction sounds academic until you’ve tried to build bidirectional FHIR sync on top of a legacy relational schema. I have. It’s the difference between translating a document and writing in the target language natively.

Medplum came out of Y Combinator’s Summer 2022 batch and has built real developer momentum since. Its GitHub repository sits around 2,500 stars as of this research pass (verify exact count at publish, GitHub stars move daily), which puts it well ahead of most healthcare-specific open source projects for raw developer mindshare. That number matters less than what’s behind it: an actively merged public roadmap, a documented plugin architecture (called “Bots” for workflow automation), and a managed-cloud option alongside the fully self-hostable core.

Actually, let me be more precise about what “FHIR-native” buys you, because I’ve watched teams underestimate this. When your data model IS the FHIR resource, every integration you build (lab interfaces, payer eligibility checks, HIE connections, a patient app) speaks the same protocol as your core data. You’re not maintaining a translation layer between “how we store it” and “how we exchange it.” That translation layer is where most custom EHR builds burn budget they didn’t plan for. For Medplum’s architecture and how it differs from a traditional EHR, I’ve written up the deeper technical breakdown separately.

We’ve built on Medplum ourselves. A Seed-stage precision-medicine platform for functional and longevity medicine practitioners came to us needing a full clinical workflow (intake, pre-visit prep, an AI ambient scribe during the visit, post-visit automation, and patient engagement) built on a compliant, extensible foundation rather than a rigid commercial EHR. We built it on Medplum plus Google Cloud Platform, and the AI-augmented documentation layer alone cut provider documentation time by 70% (Mindbowser internal delivery data, 2026, single-client engagement, verify at publish before reuse in a different context). That’s not a claim about Medplum’s generic capability. That’s what one specific build achieved on top of it, with a team that knew where the FHIR edge cases live.

Who shouldn’t use Medplum: anyone who wants staff logging into a system next month with no engineering team involved. Medplum has no default clinical UI you install and start charting in. You build that UI, or you hire someone who has.

Oystehr (Ottehr): The Developer-First Specialty Platform

Oystehr is the platform least people evaluating “open source EHR” have heard of, and it’s the one I’d flag first for a specific buyer: a team building urgent care, pediatric, or virtual-first care specifically, not general ambulatory care.

Where Medplum gives you generic FHIR primitives and expects you to build the clinical workflow yourself, Oystehr ships with pre-built workflow scaffolding for the use cases its founding team knew best. It runs on FHIR R4B and R5, which puts it slightly ahead of Medplum on spec version currency, and it’s built by a team with direct pediatric urgent care operating experience, not just platform engineering experience.

I won’t rebuild the full technical breakdown here. What Oystehr’s Ottehr platform actually offers is the dedicated deep dive, and it’s worth reading in full if pediatric or virtual-first is your actual use case. The short version for this comparison: Oystehr is the right call when your clinical workflow maps closely to what it was purpose-built for, and the wrong call when you’re building general ambulatory care and would be fighting its opinions the way you’d fight OpenEMR’s rigidity, just from the opposite direction.

Beyond the Big Three: OpenMRS, GNU Health, and WorldVistA

If your evaluation is happening outside the US, or you’re a health ministry or NGO with a global-health mandate, the three platforms above aren’t the whole conversation. Three more names come up constantly in that context, and I’d be doing you a disservice to leave them out.

OpenMRS is the dominant open source EHR across sub-Saharan Africa and much of South and Southeast Asia (verify current deployment-share figures at publish), purpose-built for resource-constrained, high-volume public health settings (HIV care programs, TB tracking, maternal health). It’s not competing with OpenEMR for a US ambulatory practice’s business. It’s competing for a ministry of health’s national rollout, and it wins that comparison in low-resource, high-volume, program-driven contexts where OpenEMR’s assumptions about connectivity and infrastructure don’t hold.

GNU Health takes a different angle entirely: it’s built on the Tryton framework and extends past clinical records into a broader health and hospital information system, with modules for laboratory, pharmacy, and even socioeconomic determinants tracking, aimed at public health systems that need more than a chart.

Is Open Source EHR Actually Free? The Real Cost Math

No. And if a vendor comparison told you otherwise, that’s the first sign it wasn’t written by anyone who’s actually run one of these in production.

Let’s do the math the way I’d do it for a client, because “free” is doing a lot of work in most people’s assumptions and none of it survives contact with a real deployment.

Source: composite estimate from Mindbowser delivery engagements and published open source EHR hosting-partner pricing ranges, 2026 (verify at publish, ranges vary by scope and region).

The license fee disappears. The total cost of ownership doesn’t, because someone still has to host it, patch it, integrate it with your lab and pharmacy systems, and answer the phone when it breaks. What actually changes with open source isn’t “free vs paid.” It’s “predictable recurring vendor fee vs variable cost you control more directly, with more responsibility for the parts a commercial vendor would otherwise own.”

For a deeper breakdown of where those numbers come from across different build models, our EHR software cost guide walks through the full range from configuration-only to fully custom. And if you’re weighing whether OpenEMR’s finished UI is worth the customization ceiling against a from-scratch Medplum build, that trade-off deserves its own conversation. Start a Conversation with us before you budget either path, because the honest cost estimate depends entirely on how much your workflow actually deviates from what OpenEMR ships out of the box.

WorldVistA, derived from the US Veterans Health Administration’s VistA system, is the oldest lineage of the group by a wide margin (VistA’s origins trace to the 1970s and 80s) and still shows up in conversations about government and military-adjacent deployments, though its active development pace lags the other platforms covered here (verify current maintenance status at publish).

If you’re mapping the full landscape of EHR system types, not just the open source subset, our guide to the full landscape of EHR system types covers where open source fits against cloud-based, on-premise, specialty-specific, and integrated delivery network systems as a category, which is useful context if you’re still at the “what kind of EHR do we even need” stage rather than the “which specific platform” stage this piece assumes.

Self-Hosting vs Managed Cloud: Who Should Run What

Every one of these three platforms gives you a choice most commercial EHR buyers never have to make: run it yourself, or pay someone to run it for you.

Self-hosting means your team, or a contracted partner, owns the server, the patching cadence, the backup strategy, the uptime, and the security hardening. It’s the highest-control, highest-responsibility option. It’s also the option where most of the “OpenEMR is a nightmare” reviews originate, and in nearly every case I’ve dug into, the nightmare wasn’t the software. It was a practice with no dedicated IT capacity trying to run production healthcare infrastructure as a side project.

Managed cloud flips that. OpenCoreEMR, launched in May 2025 by Open Core Ventures and now an operating alternative-access option (verify current plan terms at publish; not a “just launched” experiment anymore, which is how some older comparison content still frames it), offers a free hosted tier of ONC-certified OpenEMR alongside paid plans. Medplum offers its own managed cloud option on top of the open source core. The trade you’re making here is the inverse of self-hosting: less infrastructure burden, less deep customization control, and a recurring cost that starts to resemble the commercial EHR pricing you were trying to avoid in the first place.

The FQHC and Community Health Center Case for Open Source

I want to talk to a specific reader here, because most open source EHR content pretends the reader is generic. You’re probably an IT lead or ops director at a federally qualified health center, or something close to it. Your budget is real but constrained. Your patient population needs the same clinical rigor as any hospital system, and your Uniform Data System reporting requirements to HRSA don’t get relaxed because your software budget is smaller.

This is where open source earns its strongest case, and it’s not really about the license fee. It’s about control over a system that has to serve a patient population commercial EHR vendors don’t always build for first. Sliding-fee-scale billing workflows, 340B pharmacy program integration, and integrated behavioral health documentation all show up more naturally in a system you can modify than in a locked commercial platform where every customization request goes through a vendor’s roadmap committee.

A referral coordination workflow is where I’ve seen this play out most concretely. Community health centers route an outsized share of their patients to specialists outside their own system, and every dropped referral is a patient who doesn’t get seen. Mindbowser’s Patient Referral Manager, our accelerator for FHIR R4 and HL7-based referral coordination, plugs into an OpenEMR or Medplum build to capture, route, and track every referral in one guided flow instead of a fax machine and a spreadsheet. It’s the kind of workflow gap a commercial EHR treats as a $40,000 add-on module and an open source build treats as a configuration decision.

I don’t want to oversell this. Open source isn’t automatically cheaper or automatically better for an FQHC. It’s better when your team, or your build partner, actually understands both the FHIR layer and the HRSA compliance layer well enough to build the workflow correctly the first time. Get that wrong and you’ve traded a vendor’s roadmap committee for your own technical debt.

If you’re still deciding whether open source is the right lane at all versus a commercial FQHC-focused platform, our full FQHC EHR buyer’s guide walks the complete shortlist: athenaOne, NextGen, eClinicalWorks, Epic via OCHIN, Oracle Health, and Netsmart included, against the same UDS+, 340B, and sliding-fee-scale criteria, before narrowing to where open source specifically fits.

If community health center workflow gaps like this sound familiar, Start a Conversation with us. We’ve built referral coordination, sliding-scale billing logic, and behavioral health documentation workflows on top of open source EHR platforms before, and the FQHC-specific compliance questions are exactly where a generic implementation partner starts to show its limits.

When a Government or International Health System Needs Its Own EHR

The other reader I have in mind here is a program manager at an international health ministry, evaluating whether to adopt a commercial EHR contract, deploy OpenMRS or OpenEMR as-is, or commission a custom build. This isn’t a hypothetical for us.

We built a national-scale electronic health records platform for a Caribbean nation’s health ministry, standing up clinical infrastructure across their public hospital network from the ground up. This wasn’t a module or an integration layer bolted onto something that already existed. It was country-scale custom EHR development, on open source foundations, for a government that needed full ownership of its clinical data infrastructure rather than dependency on a single foreign commercial vendor.

The reason that distinction (full ownership vs vendor dependency) matters more at the national level than almost anywhere else: a health ministry that adopts a proprietary commercial EHR is also adopting that vendor’s pricing power, roadmap priorities, and data residency terms for every hospital in the deployment. A government running its own open source-based platform, even one it paid a partner to build, keeps the source code, the data model, and the modification rights. That’s not a small distinction when you’re planning infrastructure meant to run for decades, not fiscal quarters.

For compliance-sensitive international deployments specifically, where HIPAA-equivalent data handling requirements intersect with a country’s own health data regulations, PHISecure handles the compliance layer our teams build on top of: de-identification across 18 identifier types, spanning DICOM imaging, video, and document formats, built for exactly this kind of cross-border, multi-regulatory clinical data handling. It’s not a feature every open source EHR build needs. It’s close to mandatory for one crossing international regulatory lines.

Whether your evaluation looks anything like a health ministry’s constraints, the underlying question is the same one an FQHC asks: does an existing open source platform get you 80% of the way there, or does your specific regulatory and workflow environment need something closer to a ground-up build? Request an Assessment if you’re weighing that decision and want an honest read before committing to either path.

Build-vs-Buy-vs-Hire: The Decision Framework

Here’s where I pull the whole comparison together into an actual decision, because a comparison table without a decision framework just leaves you more informed and equally stuck.

Three real paths exist once you’ve decided open source is in play at all: adopt a ready-made platform as-is (OpenEMR, OpenMRS), build on a developer platform (Medplum, Oystehr), or commission a fully custom build that may use open source components under the hood but isn’t “adopting a platform” in any meaningful sense.

I think the framework most vendor content skips is this: the decision isn’t about which platform has more features. It’s about where your differentiation actually lives. If your competitive edge is clinical workflow efficiency for a specific specialty or population and the EHR interface is that workflow, you need build-level control, which points toward Medplum, Oystehr, or a custom foundation. If your competitive edge is somewhere else entirely (your care model, your patient relationships, your outcomes) and the EHR just needs to work reliably and get out of the way, adopting OpenEMR as-is is the faster, cheaper, lower-risk path.

I’d bet most FQHCs and small-to-mid practices land in the second category and most Series A/B digital health companies land in the first, but I’ve seen exceptions go both directions enough times that I wouldn’t treat that as a rule. For the fuller version of this decision tree, including where “custom from scratch, no open source foundation at all” fits, choosing between ready-made and custom EHR solutions is the companion piece to this section, and how to build an EHR system from scratch covers the build path in full if that’s where you land.

What I still can’t give you a clean rule for is the “hire a partner vs build entirely in-house” question. It depends on whether you can actually hire and retain FHIR-literate engineers in your market, and that’s gotten harder, not easier, over the last two years as more digital health companies compete for the same small pool of people who’ve actually shipped a FHIR-native system in production. If you’ve found a clean solve to that hiring problem that doesn’t involve a build partner, I’d genuinely like to hear it.

Start a Conversation about which of these three paths fits your specific constraints. This is the one part of the evaluation that doesn’t compress well into a blog post, because the right answer depends on details specific to your team.