The listing is unchanged
The certified listing names the major version, so every 8.x release sits inside the same listing. We pin 8.2.0 rather than the newest point release for maturity, not compliance.
Core
Stock OpenEMR. Genuinely stock.
We host OpenEMR 8.2.0 exactly as the project publishes it — same files, same checksum, no patches and nothing dropped into its directories. Everything we build reaches it over its own APIs, from the outside. That single rule is what makes all the rest of this safe.
ONC certified, listing intact
Pinned by checksum
Upgrade when you choose
Why it matters
The moment somebody edits the core, it stops being the thing you certified
This is how most OpenEMR deployments end up stuck. A vendor adds a feature by editing a core file, then another, and eighteen months later the install cannot be upgraded without re-doing work nobody documented — and the certified version on the listing is not the version actually running.
So core/ here is replaced wholesale and only deliberately. A pin file names
the release and its checksum, one command verifies the tree against it, and another shows
what has shipped upstream since. If our copy ever differs from the published release by a
single byte, the check fails and says so.
The whole policy
bin/core verify does core/ match the pin? bin/core install download, checksum, install bin/core check-upstream what has shipped since bin/core routes the API surface we build on
Not a convention. There is no supported way to change
core/ other than replacing it.
Certification
Yours, and still yours afterwards
Nothing of ours runs inside it
Our code talks to OpenEMR across a network boundary. That is the right engineering answer, it is the OpenEMR project's own stated preference, and it happens to be the licensing answer too.
Upgrades stay boring
Because there is nothing to re-apply. Moving between releases is one line in the pin file, and a route check afterwards to see whether the API surface moved under us.
Three ways to have it
Run it as it comes, replace the front end, or neither
Just OpenEMR
Hosted, backed up, restore-drilled, monitored. The application your staff already know, run properly, with nobody's fingerprints on it.
OpenEMR plus ONEemr
Our own front end on the same database. Staff who prefer the original keep using it; the two coexist because they are reading the same tables.
Either one, plus Essentials
Reminders, referrals, booking, the patient app, payments — over the API, so they work the same whichever front end your staff are looking at.
See the modulesBring an existing install, or start clean.
Either way the record stays in a shape any OpenEMR can read — including one that is not ours.