Three open-source clinical platforms already run in production, at national scale, outside Canada. An assessment of OpenMRS, Bahmni, and openEHR as candidate foundations, and why Canada should extend the interoperability work Infoway has already funded rather than build from zero.
An assessment of OpenMRS, Bahmni, and openEHR as candidate foundations, and why Canada should extend rather than replace the interoperability work Infoway has already funded.
Every conversation about a Canadian-owned clinical information system eventually runs into the same objection: build versus buy is a false choice, because nobody actually builds a hospital-grade CIS from a blank repository. That’s true, and it’s also not the choice on the table. There is a third option, and it already exists in production, running real patients, in more countries than Oracle Cerner, MEDITECH, and Epic combined have ever operated in as a single deployment: open-source clinical software, built collaboratively over two decades, governed by nonprofits and foundations instead of shareholders. The question this paper asks is narrower than “should Canada build its own EHR.” It’s: of what already exists, what is actually usable, what is missing, and what would still have to be built.
OpenMRS, Bahmni, and openEHR get lumped together in “open-source EHR” conversations as though they’re competing products. They aren’t. They solve different layers of the same problem, and conflating them is the fastest way to make a bad procurement decision.
OpenMRS is a clinical data platform — a way to capture, store, and structure patient encounters. Bahmni is a hospital application built on top of OpenMRS, wrapping it with registration, billing, pharmacy, and lab workflows so a facility can actually run its day on it. openEHR is neither of those — it’s a data-modeling standard, a specification for how clinical concepts should be structured so they outlive any particular vendor’s software. You don’t install openEHR the way you install Bahmni; you build (or buy) software that conforms to it. Understanding which layer each of these operates at is the difference between “Canada could extend this” and “Canada would be starting over with extra steps.”
Other open-source projects belong in a broader screening exercise. GNU Health combines electronic medical record, hospital-management, laboratory, and health-information-system functions, making it the closest additional hospital-oriented candidate. OpenEMR and LibreHealth EHR are also credible open-source EHR projects, but their public positioning is closer to ambulatory clinical and practice-management workflows than to a province-wide acute-care CIS. This paper therefore concentrates on the three foundations above while keeping those alternatives in view.
OpenMRS started in 2004 as a joint project of the Regenstrief Institute and Partners In Health, built initially to get HIV programs in Kenya off paper.1 Twenty-two years later it runs in an estimated 70-plus countries, across roughly 8,000 facilities, with implementers reporting more than 15.6 million patient records under management — figures that come from OpenMRS’s own reporting and a UNDP Digital Public Goods listing, not an independent audit, so they should be read as a credible order of magnitude rather than an exact count.2 Much of that scale was built on PEPFAR funding for HIV surveillance and care across sub-Saharan Africa and Haiti, and national programs like KenyaEMR, Rwanda’s HIV-care system, and Uganda’s Ministry of Health–mandated UgandaEMR are all OpenMRS distributions running at national scale today.3
It’s licensed under the Mozilla Public License 2.0, governed by a nonprofit — OpenMRS Inc. — with community-elected technical leadership rather than a single vendor’s product roadmap, and it has a maintained FHIR module (openmrs-module-fhir2) targeting FHIR R4.4 That module is real but not complete: it doesn’t yet cover every resource or every piece of OpenMRS data, and a critical security advisory against it (CVE-2025-46823) was disclosed as recently as May 2025 — a reminder that “mature” and “finished hardening” aren’t the same thing.5
The honest limitation: OpenMRS was purpose-built for resource-constrained primary care and disease-specific public health programs, not acute inpatient hospital operations. A 2021 functional review found it met roughly a third of the criteria typically expected of a full EMR, with billing and practice management requiring custom extension.6 Nothing in its deployment history — Kenya, Rwanda, Uganda, Haiti — resembles the volume or acuity of a Canadian regional or tertiary hospital. That’s not a disqualification. It’s a scope statement: OpenMRS is a strong candidate for the primary-care and community-health layer of a Canadian system, and an open question for the acute-care layer.
Bahmni takes OpenMRS as its clinical backend and bolts on Odoo (formerly OpenERP) for registration and hospital administration, OpenELIS for the lab, and DCM4CHE for radiology and DICOM imaging.7 Thoughtworks built it starting in 2013 and handed governance to the “Bahmni Coalition” in 2017, operating under OpenMRS Inc.'s nonprofit umbrella, with Thoughtworks still a major contributor.8 It has real hospital-scale mileage: Possible Health’s Bayalpata Hospital in Nepal runs inpatient, OT, ER, and outpatient departments on it, and Médecins Sans Frontières, working with Partners In Health and Interactive Research and Development, selected Bahmni as the EMR for the multi-country endTB drug-resistant tuberculosis trial, with MSF publishing its own field evaluations from deployments like Kabinda VIH Hospital in the DRC.9
The gap to flag plainly: Bahmni’s own documentation lists a meaningful set of inpatient features — drug charts, nurse dashboards, ward views, discharge summaries — as active development rather than long-settled capability.10 Nothing in the public record shows Bahmni running at the volume or acuity of a Canadian acute-care hospital, and no built-in support for ICD-10-CA or Canadian billing codes exists; it maps SNOMED CT to ICD-10 generically, and the Canadian-specific mapping work would be new. Bahmni is closer than OpenMRS alone to a deployable hospital system out of the box, but “closer” is not “there.”
openEHR is the odd one out, and arguably the most important one for a national architecture rather than a single facility’s software. It’s a two-level model: a small, stable Reference Model implemented in code, plus archetypes and templates — reusable, clinician-authored definitions of clinical concepts like a blood pressure reading or a discharge summary — that can be revised without touching the underlying software.11 That separation is precisely the property a federation of thirteen jurisdictions needs: a shared, versioned definition of what a lab result or a medication order means, decoupled from whichever province’s software happens to be rendering it on a given Tuesday.
It’s already running at national and regional scale elsewhere. Slovenia has operated an openEHR-based national interoperability platform since 2012, standing up a national COVID-19 screening service in fourteen days during the pandemic.12 Norway’s DIPS Arena, adopted by Helse Vest and other regional health authorities from a 2007 tender, is built on openEHR foundations, with cumulative investment reported above NOK 1.3 billion since 2013.13 Catalonia’s regional health system and London’s shared-care record — built on Better’s openEHR-based clinical data repository and reporting more than 100 million recorded “moments of care” since 2020 across a ten-million-person population — are both live, current examples, not pilots.14 Moscow’s EMIAS system is frequently cited as the largest openEHR deployment in operation, though the widely repeated “12 million citizens” figure traces to secondary market-research sources rather than a primary Moscow city release, and should be treated as directionally credible rather than verified.15
openEHR and FHIR are not competitors — the openEHR community’s own framing, echoed by FHIR implementers, is that openEHR is built for deep, longitudinal clinical data persistence, while FHIR is built for exchange between systems.16 Tooling to bridge the two — openFHIR, and Better’s “FHIR Connect,” expanded through 2024–2025 — lets an openEHR clinical data repository expose FHIR APIs to the outside world.17 There’s also a self-hostable, open-source openEHR server, EHRbase, built with contributions from Hannover Medical School’s PLRI and the German health-IT firm vitagroup, that can run entirely on Canadian infrastructure — directly relevant to data-residency requirements that matter to every provincial ministry of health.18
None of this is a case that Canada can download these three projects and go live. Three gaps are real and should be named rather than glossed over:
No Canadian precedent exists. A search of Canadian EHR literature — including recent interoperability environmental scans and provincial auditor-general reports — turns up no pilot, evaluation, or formal mention of OpenMRS, Bahmni, or openEHR by any province, regional health authority, or Canada Health Infoway.19 Whatever gets built here would be the first.
Localization is unfinished. OpenMRS’s French translation coverage sits at roughly half of interface strings; none of the three platforms has documented, built-in support for ICD-10-CA or Canadian provincial billing codes. This is real engineering work, not a checkbox.
No official CA Core+ mapping exists yet. OpenMRS’s FHIR module targets generic FHIR R4. openEHR’s FHIR bridging tools are general-purpose. Neither has a published implementation guide conformant to CA Core+, PS-CA, or CA:FeX — Infoway’s own pan-Canadian FHIR profile set, patient summary specification, and exchange standard, all of which are active, maintained, and tested annually at Infoway’s national Projectathon.20 That mapping work is exactly the kind of thing thirteen jurisdictions would otherwise each pay a vendor to redo, badly, in isolation.
This is the throughline the rest of this series builds on. Canada didn’t skip the interoperability homework — Infoway has spent years building CA Core+, PS-CA, and CA:FeX specifically so that clinical data can move between systems that were never designed to talk to each other. What Infoway hasn’t done, because it isn’t Infoway’s mandate, is fund a reference implementation: a real, deployable, open-source clinical system that speaks those standards natively, so that a province adopting it inherits interoperability instead of building toward it.
Canada doesn’t need to invent a clinical information system from nothing. It needs to finish connecting the open-source system that already exists to the interoperability standard it already paid for.
OpenMRS supplies a field-tested, nonprofit-governed clinical data platform with a two-decade track record at a scale no Canadian province has ever needed to hit on its own. Bahmni shows what a hospital wrapped around that platform can look like, with real (if still-maturing) inpatient deployment experience in humanitarian and mid-size hospital settings. openEHR supplies the thing a thirteen-jurisdiction federation needs most and has the least of today: a shared, versioned, vendor-neutral definition of what clinical data means, independent of whose software happens to be running it in any given province. None of the three is a finished product Canada can install. All three are further along, and more battle-tested, than a green-field build — and every gap identified here is engineering work with a known scope, not a research problem.
The next paper in this series takes that observation and turns it into an architecture: a system where each jurisdiction can own and operate its own module, every module speaks CA Core+ FHIR at the boundary, and no province is blocked waiting on another’s delivery schedule.
Own the Stack