OpenMRS: The Free, Open-Source Medical Records Platform

Hospital software is usually a procurement decision made behind a sales call, priced and licensed on the vendor's terms. OpenMRS is built against that model entirely: a free, open-source electronic medical records (EMR) platform whose code, license, and commit history sit in public on GitHub instead.

That's the part worth checking rather than taking on faith — plenty of "built for underserved health systems" projects exist mostly as a pitch deck. OpenMRS's own repositories are where that check actually happens: license text, release notes, and a commit graph that was still moving the day before this was written.

What this open-source medical records platform is, in the project's own words

OpenMRS's GitHub organization bio describes the project in one line: "Open source Medical Records by and for the entire planet, starting with the developing world." The flagship openmrs-core README frames the same goal more operationally, stating the project exists "to improve health care delivery in resource-constrained environments."

That README also carries a "Verified-DPG" badge linking to digitalpublicgoods.net/r/openmrs — the registry run by the Digital Public Goods Alliance, a UN-linked initiative that vets open-source software against a published standard. This piece could not independently load that registry page this session (the domain was unreachable), so the claim is reported exactly as it appears — a badge the project displays on its own README — rather than confirmed against the registry itself.

The license has its own Healthcare Disclaimer

OpenMRS ships under a modified Mozilla Public License 2.0, tagged in its own repo metadata as "MPL 2.0 w/ HD." The "HD" is a literal added section called the Healthcare Disclaimer, which states that "additional disclaimer of warranty and limitation of liability are hereby incorporated" on top of the standard MPL terms.

The practical effect is specific, not boilerplate: the license spells out that "use of the covered code is not a substitute for a health care providers standard practice or professional judgment," and that contributors and distributors carry no liability for indirect harms tied to clinical or privacy failures. For software that ends up inside real patient charts, that's the license doing something a generic MIT or Apache grant doesn't — explicitly routing clinical responsibility back to the provider using the software, not the open-source maintainers who wrote it.

Not one app — a stack of repos

OpenMRS isn't a single downloadable program. The organization's pinned repositories split the product into layers: openmrs-core is the Java API and web application engine (2k stars, 4.5k forks); openmrs-distro-referenceapplication is "the reference distribution of the OpenMRS EMR application," built to run via Docker Compose rather than a manual server install; openmrs-esm-patient-chart is the newer "O3" frontend, described in its own README as a set of "microfrontends that constitute widgets in a patient dashboard"; and openmrs-module-fhir2 is a standards module whose README states it's "intended to be a replacement for the current OpenMRS FHIR module, initially using FHIR R4" — the interoperability standard that lets an OpenMRS instance exchange records with other health systems rather than becoming its own data island.

One pattern shows up across every one of those repos: forks outnumber stars, often by a lot. The reference-application distro sits at 122 stars against 650 forks; the REST web-services module shows 109 stars against 597 forks; even the flagship core repo has more forks (4.5k) than stars (2k). On most GitHub projects that ratio runs the other way — people star something to bookmark it, and only a fraction ever fork it to actually run or modify. A reference EMR distro with five times more forks than stars reads less like a tool people admire from a distance and more like one people are actually taking home to stand up their own instance — though this piece can't say how many of those forks represent a live hospital deployment versus an abandoned experiment, since GitHub's fork count doesn't distinguish the two.

Real deployments run on top of it

The clearest evidence that OpenMRS gets deployed rather than just forked for show is that other open-source projects are built directly on top of it. Bahmni, a separate GitHub organization, describes itself as an "Open Source Hospital Management System & EMR built on top of OpenMRS, OpenELIS and Odoo." Its repos split into a clinic-config distribution explicitly aimed at "Clinics and Small Hospitals" and a heavier standard-config for larger facilities, both shipped through Docker, and the org's own GitHub topic tags include hospital-management-system, emr, and social-impact.

Bahmni isn't part of the OpenMRS organization itself — it's an independent downstream project choosing to build its hospital software on OpenMRS's core rather than writing a medical record engine from scratch. That's a stronger signal of real-world reliance than any stat OpenMRS could put on its own homepage, precisely because it comes from a separate team with no reason to inflate OpenMRS's usage.

Still shipping, not a museum piece

An open-source medical records platform is only as good as whether it's actually maintained, so it's worth checking the commit history directly. As of this check, the master branch had commits dated October 29, 2026 — the day before this was written — including tickets like "TRUNK-6859: Make domain object collection setters update Hibernate-managed collections in place," with more dated commits running back through the preceding week.

The ticket-number prefixes (TRUNK-####) aren't a GitHub feature — they're references to an external JIRA tracker. That also explains why the repo's own Issues tab shows zero open issues: OpenMRS doesn't triage bugs on GitHub at all. Its CONTRIBUTING.md walks contributors through claiming a "Ready for Work" issue in JIRA first, then opening a GitHub pull request against it — which is also why that same Issues tab shows 346 open pull requests sitting against zero open issues, a split that looks odd until you know the bug tracker lives somewhere else entirely.

The releases page shows the project maintaining two version lines in parallel: 2.8.10 (October 6) and 2.7.6 (September 12) both shipped within the same month, following 2.8.0 (August 15) and 2.7.4 (May 21). Running a current branch and a legacy-compatible branch side by side is typical of software that can't just force every deployed hospital to upgrade on the maintainers' schedule — a constraint that mostly shows up in infrastructure people depend on, not in a hobby project.

Where the honest limits are

This piece can verify exactly what GitHub shows and nothing past it. OpenMRS's own marketing site, openmrs.org, and the Digital Public Goods registry page it links to were both unreachable during this session's fact-checking, so no country count, patient-record total, or deployment figure appears anywhere in this piece — those numbers exist on OpenMRS's own site, but this piece isn't going to repeat a number it couldn't open and check itself.

What is checkable cuts both ways. The 346 open pull requests against a project still merging commits daily is a real backlog, not a dead one — but it's still a backlog, and a contributor's PR sitting unreviewed for months is a plausible outcome at that volume. And forks beating stars is a reasonable signal of real deployment, not proof of it; GitHub doesn't report which forks are live hospital systems and which were abandoned after a weekend.

What this generalizes to

The useful habit here isn't specific to health records: when software claims to serve "under-resourced" or "developing world" users, check whether that claim shows up anywhere falsifiable — a license that explicitly allocates clinical liability rather than staying silent on it, a commit log that's still active, and, ideally, an independent downstream project choosing to build on top of it rather than the vendor's own case-study page. That's the same discipline worth applying to checking whether an accessibility tool is actually still maintained or whether a donation platform's transparency promise is backed by a public ledger you can actually read — and it's the same instinct behind reading a spaced-repetition algorithm's own source code instead of trusting a feature list. A platform built for people who have the least room to absorb software that fails them is exactly the one worth checking yourself, rather than taking its pitch at face value.