I’d like the admins and foundation board to take a deliberate look at something: the work on the features and interface that end users rely on has thinned out — UI work especially has dropped to almost nothing — and I think the project should decide, on purpose, how it sustains this.
Underneath it is a larger question about how much of OpenEMR’s direction should rest on any single company’s priorities.
What Has Changed
At the last admin meeting, OpenCoreEMR (OCE) described its direction as API-first: continued investment in the FHIR and REST APIs. UI and calendar work would be deferred, to be approached later by building against those APIs rather than by improving the existing front-end. They consider the existing UI too difficult to overhaul in place. Separately, OCE has discontinued the UI and calendar overhaul work that had been underway.
Feature work does still happen — the fax feature is one example — but it’s thin, isn’t treated as a priority, and even substantial efforts can go months without landing. UI work, by contrast, has dropped to near zero now that OCE has stepped back, with very few PRs and essentially no one driving it.
Why This Matters for the Project
OpenEMR’s value to the clinics that run it is what they can actually do with it — the features they depend on, and how usable the system is day to day. The APIs are important plumbing, but on their own they don’t add a capability a practice can use or improve the screens people work in. For a project whose mission is to give practices that can’t afford commercial software a system they can genuinely use, letting this layer wither is a slow erosion of the thing that makes OpenEMR worth running. Features are the more pressing piece — they’re underweighted and need more attention and review priority than they get. The interface matters too, and right now almost no one is working on it at all.
One longer-term risk is worth naming, as a structural dynamic rather than anyone’s intent: if the open-source interface stays static while only the APIs advance, OpenEMR slowly becomes less usable on its own. For an API-driven OpenEMR to stay practical for a clinic to run, it would come to depend on outside layers to fill the gap — leaving OpenEMR itself as little more than a back end. That’s a pull any API-first project has to watch for; left unattended, it’s the direction the path tends, and it erodes what makes OpenEMR valuable: a complete system a practice can run on its own.
The Dependency This Exposes
This isn’t a knock on OpenCoreEMR (OCE) — their contribution to the project is large and genuine. That’s exactly why it matters. The UI and calendar work existed largely because OCE funded someone to do it; one staffing decision later, it’s gone, and nothing in the project’s structure replaces it. Because the project leans on OCE so heavily, when OCE reprioritizes, the roadmap moves with it. Michael has himself described his role as a single point of failure whose time follows company priorities. The more central OCE is, the more the project needs its own answer for the work OCE chooses not to do — otherwise the direction is set by one company by default, rather than chosen on purpose.
What I’d Like the Admins and Board to Take Up
Attention. Feature and interface development shouldn’t be left to wither just because no vendor is prioritizing it. Features especially deserve more weight and review priority than they get; UI shouldn’t be allowed to sit at zero.
Keep contributions moving. Use the new triage/review block to make sure feature and UI contributions get prompt review and actually land — so the people willing to do this work don’t give up after months without traction.
Grow the supply. Especially for UI, where contributions are near zero, actively welcome and recruit for them — a documented contribution path and a visible signal that the project wants this work, so more of it shows up.
Dependency. How the admins and board want to watch for and limit over-reliance on any single vendor’s roadmap going forward, so strategic direction is something the project decides rather than inherits.
A Realistic First Step
We don’t have funding to throw at this, and I’m not proposing we try. What we can do costs little: make sure feature and UI contributions get reviewed promptly and merged, and signal clearly that the project wants this work. For UI especially the supply is near zero — the cheapest way to change that is to make contributing this kind of work a path that visibly goes somewhere.