Open-source EMRs in the United States have spent the last several years catching up to commercial peers on FHIR and SMART on FHIR support. In 2026 the gap is narrower than most procurement committees realize. The four platforms below have working SMART on FHIR launch stories, growing FHIR API coverage, and active communities that ship FHIR-related features on a real cadence. They are not the right pick for every practice, but they belong on the shortlist when a practice has the engineering depth to run an open-source stack.
You can also pull our healthcare data exchange index for context first.
What SMART on FHIR Support Means in 2026
A platform with real SMART on FHIR support handles three things.
- Standalone launch, where an app that lives outside the EMR can authenticate and pull patient context.
- EHR launch, where the app launches inside the chart with the patient and the encounter already known.
- Current OAuth2 scopes (patient/*.read, system/Observation.write, and the newer granular scopes from US Core 6.x).
The cornerstone overview lives in the complete guide to FHIR-ready EMRs for US outpatient practices.
The 4 Open-Source EMR Platforms to Know
The shortlist below sticks to what shows up in real US open-source EMR evaluations.
- OpenEMR. The most widely deployed open-source EMR in the United States. SMART on FHIR support is mature and the FHIR API surface covers the US Core resources. Active community and growing commercial support ecosystem.
- OpenMRS. Originally rooted in global health, with growing US adoption in safety-net settings. The OpenMRS FHIR module supports SMART app launch and exposes US Core resources, though the depth varies by deployment.
- Bahmni. Built on OpenMRS, with a sharper hospital-style workflow layer. SMART on FHIR support inherits from OpenMRS but is exercised differently in production.
- OSCAR Pro. A Canadian-rooted open-source EMR with a small but growing US user base, particularly in family medicine. SMART on FHIR support has been a focus of recent releases.
What Separates Them in Real Deployments
Three practical factors decide which platform fits a practice.
- SMART app launch reliability. The standard says a lot of things; only some platforms enforce all of them correctly. A pilot launch of two or three real SMART apps will surface the gaps.
- US Core conformance depth. Coverage of the required US Core profiles varies; a platform that misses Encounter or DiagnosticReport will hurt downstream apps.
- Commercial support story. Open source does not mean unsupported, but it does mean the practice needs to either build internal capacity or buy support. The four platforms above all have commercial support options; the depth varies.
For closely related procurement decisions, the OpenEMR vs OpenMRS for US outpatient FHIR workflows comparison covers the head-to-head, and the top 5 EMR systems for multi-specialty US group practices write-up frames the broader market context.
How to Pick for Your Practice
A six-week pilot is the test that matters. Stand up two candidate platforms, launch the same set of three SMART apps against each, and run a sample patient panel through the FHIR API. Check what the apps see, what the API returns, and how often the FHIR layer falls over under realistic load. Whichever platform held up and produced cleaner SMART app launches is the right pick. Open-source EMRs reward practices with engineering depth and patience; the right one fits the practice's shape, not the brochure.
Sources
- SMART App Launch v2.2.0 IG - HTML, HL7, evergreen
- OpenEMR FHIR publishing overview (FHIR R4 + SMART on FHIR settings) - PDF, OpenEMR community, undated
- SMART Health IT documentation hub - HTML, SMART Health IT, evergreen