Open Source EHR for Custom Builds: OpenEMR, OpenMRS, Medplum, HAPI FHIR and openEHR Compared

An open source EHR can save a product team months of groundwork. Five projects are serious starting points in late 2026: OpenEMR, OpenMRS, Medplum, HAPI FHIR and EHRbase, an openEHR server. Pick OpenEMR if you need a complete US ambulatory EHR with an active ONC listing today and can work with PHP and the GPL. Pick a FHIR platform or server if you are building your own product and screens. Pick openEHR if your clinical data model is the product. Whichever you choose, the licence is free and the hosting, security, upgrades and support are real work.

This guide is for founders, CTOs and product leads choosing a base to build on. Every licence, stack, certification and GitHub figure below was checked on 27 October 2026, with links so you can check them again. If you have not yet decided whether to build at all, start with our guide to custom EHR software development.

What Is an Open Source EHR?

An open source EHR is an electronic health record system whose source code is published under a licence that lets you use, study, change and share it. Some are complete applications with clinical screens, such as OpenEMR. Others are building blocks, such as a FHIR server or an openEHR data repository, that you build your own EHR on.

Most "open source EMR" lists are written for a clinic that wants to stop paying a vendor. A product builder asks different questions:

• Can I change anything I want, and still sell or host the result?
• Does the data model fit my specialty, or will I fight it for years?
• Does anything here help with ONC certification, or do I start from zero?
• Who maintains this, and how active is the project?
• Will my team spend its time on my features, or on keeping someone else's code running?

Open Source EHR Options Compared

The table compares the five main bases, our own open source headless EHR and Ottehr, which appears on several lists. GitHub numbers show activity, not code quality. "Customising effort" is our judgement from building on these kinds of systems, not a measurement.

How we checked: licences from each project's LICENSE file, GitHub numbers from the public GitHub API, and ONC status by searching the Certified Health IT Product List (CHPL) by name. "No active listing found" means our name search found nothing; it does not rule out a certified product built on that project by another company. OpenMRS spreads its code across many repositories, so its core repository understates its community.

OpenEMR: The Complete EHR You Start From

OpenEMR is the option here that gives you a working US ambulatory EHR on day one, with clinical screens, a FHIR API and an active ONC listing.

Licence. OpenEMR uses GPL-3.0. Modified versions you distribute must carry the same licence with source available (summary at choosealicense.com). GPL-3.0 has no network-use clause; AGPL-3.0 is the licence with that clause. If you plan to ship an installable product, white-label it for other groups or sell it to hospitals that host it themselves, have a lawyer read the GPL against your model before you write code.

Certification. CHPL lists OpenEMR version 8 from the OpenEMR Foundation as active, certified on 30 January 2026, with 32 criteria (CHPL listing). The project wiki says the 7.0 certification was retired on 27 February 2026 and users had to move to 8.0.0 to stay certified (OpenEMR wiki). The listing belongs to the Foundation's product and version. If you fork and change it, ask an ONC-authorized certification body what your changes mean before you promise certification to a customer.

Customising. Light changes are quick: most settings sit under Administration, Globals (architecture page). Deeper changes go through the module system. Changes to core screens or the database are the ones to plan carefully, because each one is carried forward through every upgrade.

Best fit when you need a complete US clinic EHR soon, your team is comfortable owning a PHP codebase, and your distribution model works with the GPL.

Look elsewhere when you would rewrite most screens for a very different workflow, you plan a closed-source distributed product, or you want FHIR as your internal data model from the start.

OpenMRS: A Modular Platform for Health Systems

OpenMRS describes its mission as improving care "in resource-constrained environments" (README). Its newest frontend, O3, is a set of TypeScript and React modules loaded at runtime, with shared configuration and extension systems (O3 frontend core).

Licence. MPL 2.0 with a healthcare disclaimer (LICENSE). MPL is file-level copyleft: files you modify stay under MPL, while your wider product can use other terms. The disclaimer says the code does not replace a provider's standard practice and limits contributors' liability.

Customising. OpenMRS was designed to be extended. Backend modules add or remove features for a site, and the O3 frontend has its own configuration, extension and feature-flag systems. In our view that makes it a strong base for program-specific builds.

Best fit when you serve health programs or systems outside US certification, and you want a large, established community and a modular design.

Look elsewhere when you sell to US practices that expect certified technology, or your team wants a FHIR-first data model. We found no active OpenMRS listing on CHPL on 27 October 2026.

Medplum: A FHIR Platform You Build Screens On

Medplum is a headless EHR platform: a FHIR backend, sign-in with SMART on FHIR, an SDK, server-side bots and React components. You build the clinical app (README). The stack is TypeScript, with PostgreSQL for data and Redis for jobs and caching.

Licence. Apache 2.0, a permissive licence with an express patent grant. You can build a closed product on it.

Certification. CHPL lists Medplum version 5 as active, certified on 31 December 2025, with 25 criteria including (g)(10), the standardized API criterion (CHPL listing). Medplum's ONC page lists the same certification. As with OpenEMR, what the certificate means for your product built on top is a question for your certification body.

Self-hosting. Medplum's Ubuntu guide lists PostgreSQL 16, Redis, Node.js 22, Nginx and at least 4 GB of RAM (install guide), and its overview says the guides are for engineers "who have experience managing production healthcare systems" (self-hosting).

Best fit when your team writes TypeScript, you want your own screens on a certified FHIR backend, and you value frequent releases from a company-led project.

Look elsewhere when you need a ready clinical UI in weeks, or you need full control of your core platform's roadmap. The README says outside code changes must link to an issue the maintainers have opened.

HAPI FHIR: The Java Server Toolkit

HAPI FHIR is a Java library and a full FHIR server, the JPA server, backed by a database you choose (JPA server docs). It is a toolkit for building an EHR backend in Java; the EHR is yours to build. Its docs list PostgreSQL, Microsoft SQL Server and Oracle as supported (database support).

Security. HAPI FHIR gives you building blocks such as interceptors, and you design the security architecture (security docs). For an EHR, sign-in, roles, consent rules and audit logs are your team's work. We compare it with managed FHIR stores in our FHIR data store comparison and cover scaling in our HAPI FHIR performance guide.

Best fit when you have Java engineers, want a widely used FHIR server, and can design healthcare access control yourself.

Look elsewhere when you want a finished EHR or a ready access model.

EHRbase: openEHR When the Data Model Is the Product

EHRbase is an open source openEHR clinical data repository. It stores data as openEHR compositions defined by archetypes and templates, and you query it with AQL through the openEHR REST API (README). Our openEHR developer guide explains archetypes, templates and AQL, and our openEHR CDR comparison covers the alternatives.

Why product teams pick it. In openEHR, clinical content lives in archetypes and templates apart from the application code. In our experience that makes new clinical structures, such as long-term care plans or research registries, easier to add as a specialty product grows.

US fit. US certification includes a FHIR-based API criterion, (g)(10), so a US product on openEHR also needs a FHIR layer.

Best fit when rich, evolving clinical models are your main product value and your team can learn openEHR modelling.

Look elsewhere when your clinical data is simple, your main need is US interoperability, or you need a UI soon.

Other Projects You Will See in Lists

Ottehr. A patient portal and a staff-facing EHR with telemedicine, from MassLight, the company behind the Oystehr platform. Its licence starts from MIT terms and adds conditions: you must keep attribution to Oystehr, Ottehr or MassLight, and you may not use the software to create a "Competing Product". Read it carefully before building an EHR product on it.

LibreHealth EHR. Its GitHub repository shows its last code push on 9 September 2023, so check the project's current status before you rely on it.

How to Choose an Open Source EHR Base

Three questions settle most choices: what you sell, how you distribute it, and what your team already knows. The flowchart and checklist below turn those into a decision.

Five Common Ways to Build on Open Source

Teams combine these projects in a handful of patterns. The trade-offs below are our judgement from building EHR products, not measurements.

In the last pattern, a team keeps a certified EHR for general documentation and billing, and build only the specialty workflow on an open source FHIR or openEHR base, connected through APIs. Certification stays with the vendor, and the team spends its effort where the product differs.

Questions to Ask Before You Fork

1. Licence: does it allow how we plan to distribute, host or white-label the product?
2. Certification: do our customers need certified health IT, and does this base help or do we start from zero?
3. Data model: can our specialty's data live in this model without fighting it?
4. Activity: when was the last release, and who maintains the code we depend on?
5. Team: do we have engineers who know this language and healthcare standards?
6. Changes: can we keep our changes outside the core, so upgrades stay cheap?
7. Running it: who hosts, secures, supports and tests it after launch?

The Real Cost of Running an Open Source EHR

The licence is free; running a production EHR is not. In the r/healthIT thread that ranks first for this search, a physician asked about a free EMR on one hard drive. The top reply said OpenEMR could run in a container on one machine, then warned that keeping all your data on one machine is risky and urged regular backup tests. For a product team, that warning covers five costs.

• Hosting. Someone runs the database, servers, backups, restores and monitoring. If a cloud provider stores patient data for you, HHS says it is a business associate even when it holds only encrypted data without a key, so you need a business associate agreement (HHS cloud guidance).
• Security. The licence gives you code, not a risk assessment, testing or incident response. No open source project makes you HIPAA compliant; compliance comes from how you run the system.
• Upgrades. Every project here ships often. Keep your changes in modules, extensions or your own services wherever the project allows it, so upgrades stay cheap.
• Support. Forums are free; help during an outage is not. OpenEMR lists paid support vendors on its wiki. For the others, plan your own on-call team or a support contract.
• Certification upkeep. An ONC listing comes with yearly real world testing and attestations (CHPL). If you certify your own product, those duties become yours.

What We Build On

We keep our own open source base. Our headless EHR with a FHIR R4 API and SMART App Launch passed 47 of 47 (g)(10) SMART App Launch tests in Inferno on 11 June 2026. Passing Inferno tests is not the same as holding an ONC certificate, and we do not claim one. Our client builds include a FHIR-native provider platform that runs on a FHIR server with no private database, and an offline-first screening EMR with device integration.

If you are weighing these bases for a real product, we can review your requirements and recommend one, with a fixed price after a short discovery. Our published prices start at $45K to $70K for a Launch MVP in 10 to 12 weeks and $90K to $160K for a specialty EHR in 4 to 6 months. See our EHR development services.

If You Are a Small Clinic, Not a Product Team

Many people searching for an open source EMR run a single practice. For them the trade-off is simpler: a certified, maintained product with someone on call is usually safer than running your own server. If you do self-host OpenEMR, back up every day, keep a copy off site and test a restore every month.

Building a custom EHR on an open source base? Explore our custom healthcare software development and healthcare interoperability services. Talk to our team to choose the right base.

Sources

1. CHPL listing 11757: OpenEMR 8 (checked 27 Oct 2026)
2. CHPL listing 11745: Medplum 5 (checked 27 Oct 2026)
3. OpenEMR wiki home page
4. OpenEMR system architecture
5. OpenMRS core repository and README
6. OpenMRS O3 frontend core
7. Medplum repository and README
8. Medplum self-hosting documentation
9. HAPI FHIR JPA server documentation
10. HAPI FHIR security documentation
11. EHRbase repository and README
12. Ottehr licence
13. Nirmitee headless EHR repository and Inferno results
14. choosealicense.com licence summaries
15. HHS guidance on HIPAA and cloud computing
16. r/healthIT: free open source EMR for private practice (March 2023)