Weekly Meetings:2026-09-22

← All meeting summaries | Join the call

Attendees: Stephen Waite, Eric Stern (OCE, departed partway), Simon Quigley (departed partway), Sherwin Gaddis, David Eschelbacher. Brady Miller and Stephen Nielson absent.

Italicized indented passages are background and clarification added after the meeting, not statements made on the call.

PDF version: 📄 OpenEMR Weekly Meeting Detailed Summary 2026-09-22.pdf

Opening

• Recording notice given verbally at the start, with the explanation that Google Meet's native recording requires a paid tier, so the meeting is captured separately for transcription.
• Brady Miller and Stephen Nielson were both absent. Stephen Nielson had been travelling to New York for a health-track meeting held alongside the United Nations General Assembly week, organized by a group based in Ireland with UK and European affiliates. His flight was cancelled after a major power outage at Newark, and after most of a day at the airport he did not make the trip.
• With both usual chairs absent, the meeting ran informally without a set agenda.

Simon Quigley — Context and Open Pull Requests

• Background clarified: Simon is the only software engineer at an IT support company. The OpenEMR client is a long-standing IT support customer that asked for OpenEMR development work, which is how he came back to the project. Same client as his earlier involvement.
• Deployment approach: the client runs a clean, unmodified OpenEMR as released. The explicit policy is to upstream everything; only if upstream declines a change would a local fork be considered. Production may still be on the 7.0 line; the issues he is fixing reproduce on both that version and current master.
• Current open PRs, all driven by the client's request list: the LBF statements module (13795), window-envelope patient statements (13852), a printable active medication list, and one further PR. A fifth is in progress — a Medicare billing fix for claims rejected when the service location does not match the billing location.

Simon's open pull requests: github.com/openemr/openemr/pulls — author:tsimonq2

• On review latency: from broader open source experience, waiting on review does not bother him. Stephen Waite's response: once CodeRabbit is satisfied and someone gives a PR a quick look, it is generally good to go, so these may start merging soon. No objection voiced to bringing them into core; the LBF module question is still being held for a module-policy follow-up with Brady.
• Stephen Waite offered to look at the Medicare billing issue, having worked extensively in the billing code, and would not be surprised to find an odd bug in that area.
• A question asked of Simon's client: would they ever want to hand statements to a print vendor via an export file rather than printing in-house? Answer: too small a practice for that to make sense. Noted that practices split between contracting statement mailing out and doing it themselves.
• Correction to a remark from the previous meeting: an earlier comment that Simon's PRs were practice-specific was queried. On inspection, the printable medication list and window-envelope statements look broadly useful, and the clarification was that there is no objection to them in core.
• More items expected from the client over the following days.

The Medicare issue Simon described is a known class of problem: on professional claims, the service facility location and the billing provider location are reported separately, and payers reject claims when these do not reconcile with enrollment records. Whether it is a code bug or a configuration issue will depend on how OpenEMR populates those loops for a given facility setup.

Release 8.4.1 and Versioning

• 8.4.1 went out on short notice. It carried fixes for broken features along with security items, and was used deliberately to exercise the patch-release workflow of the automation for the first time — prior releases had all been minor-version bumps. A couple of issues surfaced and are being smoothed out.
• Expectation: many more patch-level releases ahead, rather than climbing through 8.5.0, 8.6.0, and so on for security-only changes.
• Everything is effectively a full release now. With Docker integration, a patch is packaged the same as any other release. The goal remains getting users onto the containerized version, where upgrading is a matter of changing a version number.
• On versioning semantics: the project does not strictly follow semantic versioning, but the lowest number bumping implies bug fixes only. Versioning will matter more once the module system lets a module declare a minimum OpenEMR version.
• The certification wrinkle: certification is tied to the 8.x line, and downstream users need to upgrade quickly to stay certified. That was the one practical fallout noted.

Semantic versioning (major.minor.patch) signals intent: a patch bump promises no new features and no breaking changes, a minor bump adds features compatibly, and a major bump may break compatibility. Once modules can declare “requires OpenEMR 8.4 or later,” the project will effectively be making those promises to module authors, which is why the scheme was flagged as mattering more in future.

Architectural Themes Ahead

Asked what he sees as significant coming down the pipeline, Eric Stern outlined several large themes:

• Doctrine-based internals — fixing database access. Every raw query converted onto Doctrine eliminates SQL-injection risk for that path.
• Templating. Twig itself is fine; the work is moving the large body of code that does not yet use it. That addresses cross-site scripting as a class.
• The front controller — enables centralization, and pairs naturally with the Docker packaging.
• Session handling and a more API-driven front end, which fixes another large class of issues.
• Who each theme matters to: for administrators and sysadmins, packaging is the biggest change. For contributors, modules, templating, and Doctrine. The internal changes also carry substantial positive security implications.

The Session and Patient-Context Problem

Related issue: #2556 — Improve OpenEMR sessions/cookie management

• The patient ID pinned in the session was named as a real design challenge, easier said than done. The route out: as the UI becomes more API-driven — largely by moving to FHIR — patient ID becomes a parameter to each request rather than part of the session, and the problem drops away as the UI migrates incrementally.
• Scale exposes session weaknesses. At a very large installation, things fine at small scale burst at the seams — for example, code attempting to write to a read-only session. It is handled, but floods the logs. File-backed sessions were described as a very 2002 style of PHP; that deployment uses Redis-compatible storage (Valkey) to support horizontal scaling.
• Background: the issue was opened by Brady in 2019. A later session overhaul by Milan was a net positive, though a few edge cases were handled imperfectly and are being fixed as found and contributed back.

The cookie setting half-remembered on the call is HttpOnly, not SameSite. Per issue #2556, OpenEMR lets different patients be opened in different browser tabs without clashing, and it does this by letting JavaScript modify the session cookie. That requirement is exactly what prevents the main application from setting HttpOnly, which blocks JavaScript from reading the session cookie and so protects session IDs from theft via cross-site scripting. The patient portal, which handles only one patient, already sets it. The 2019 issue predicted browsers would eventually push this setting; moving patient context out of the session is what would let the main application adopt it.

Valkey is the Linux Foundation's open source fork of Redis, created in 2024 after Redis moved away from an open source license. It is protocol-compatible, which is why it was described as “technically the same thing.” Storing sessions there rather than on local disk is what lets multiple application servers share one user's session.

Modules and Upgrade Stability

• The biggest source of upgrade instability has been custom modules built against a specific OpenEMR version. When an API surface changes — and the project has no visibility into unpublished custom modules — operators must either patch the module to upgrade, or patch security fixes forward while leaving everything else as it was. Addressing that directly is the top priority of the next-generation module design.
• The design principle: the new module system explicitly defines its API surface as a contract. Stay within it, and upgrades will not break the module. Go around it, and the project cannot help.
• Why version 1.0 is narrow: the draft covers API endpoints, CLI commands, and database access only. Template overrides and conditional UI changes have many possible solutions and should not be rushed. Those can arrive in 1.1 or 1.2 as non-breaking additions. The immediate goal is unblocking simpler modules — a fax integration, SMS, email — that just need an endpoint to hit.
• On the event system: nothing in it is actually asynchronous; the naming implies it but everything runs synchronously. Whether to keep an event-driven model is one of the architectural questions deliberately left out of the first version.
• Shipping still depends on the front controller, which benefits from the Docker work. No feedback received on the module draft either way.
• The general tension restated: highly customizable software is hard to keep maintainable, which is why most SaaS products are opinionated and minimally customizable — it works for you or it doesn't.
• Real-world experience, in general terms: large deployments that modified core directly, and built modules depending on those modifications, face the hardest upgrades. The mechanical API changes are manageable; merge conflicts in modified core code are where the effort goes.
• Current work being upstreamed: error-handling fixes, developed upstream first and then pulled into a private build, and a batch of performance fixes.

Helping Operators Who Cannot Upgrade Immediately

• Proposal: a centralized list for operators who cannot upgrade immediately — for installations below a given version, the most significant published issues that can be mitigated by disabling a feature or changing a setting, as a stopgap until upgrading. Patching remains the best option, but not always the easiest: many practices would need to bring in a vendor, and many run set-and-forget until something breaks.
• Well received. The advisory process already asks whether a workaround exists — a setting to turn off, or a non-code change. If that information is captured consistently and published centrally, operators need not look through many individual advisories.
• A practical mechanism suggested: for each release containing security fixes — effectively all of them for the foreseeable future — have AI scan the published advisories and add a section to the release notes: if you cannot upgrade immediately, here are the settings you can change to reduce risk.
• Caveat noted: some operators will not be able to use a given workaround because they depend on the feature in question. In those cases the list at least makes it clear that action is required.
• On prioritization: published advisories vary widely in real-world impact, and ranking them by genuine severity would let the list lead with what matters most. The project can continue to edit severity on published advisories where the original rating does not reflect actual risk.
• The structural answer, restated: the front controller is in master and in the release, but not on by default. Once traffic runs through it in the distributed version, whole classes of problem can be addressed centrally through middleware rather than by finding and fixing individual locations one at a time.
• Why it is not on by default: the core works and has automated tests, but so many installations are customized — and not run consistently in Docker — that every edge case cannot be covered.

This builds on the suggestion from 8/25 to add a workaround section to published advisories. The difference here is aggregation: a single, version-scoped list in the release notes, rather than asking operators to read each advisory individually.

Sherwin Gaddis — Practice Work and UI

Current Work

• Most of his work is one-off, practice-specific development. He has around seven clients running entirely unmodified OpenEMR, trained on the stock product.
• A new client migrated away from Greenway, citing a desire to own their data rather than have it sold or used for AI model training.
• Also taking on a long-standing international installation still on version 5, which will need to be brought current before new work begins. Several rural hospital deployments completed, with another in progress.
• Moving all clients to 8.4 over the coming period, including Jerry's context manager as part of the upgrade.

UI Work — Left-Side Menu

• Working on cosmetics, on the theory that a more modern appearance may improve adoption. The main change so far moves the menu from the top back to the left side.
• Why: a more modern look, and it returns vertical space. With collapsible menus of the kind now common, the working area for the chart grows further.
• Jerry's context manager is shown to every client. Reaction is generally indifference, so in practice it is used to tailor the interface quietly — switching off panels a practice will not use — rather than something clients configure themselves.

E-Prescribing

Weno and Unlisted Pharmacies

• A recently migrated client tried Weno out of the box and asked for an alternative. The pharmacies they use in Washington state are not on Weno's network, which created more work for providers.
• How non-participating pharmacies are handled: Weno sends the pharmacy an enrollment package, delivering the prescription alongside it, but the pharmacy must set up a Weno account to receive electronic prescriptions going forward. Whether faxing is still used for non-participating pharmacies was uncertain on the call.

Weno Exchange is the e-prescribing integration bundled with OpenEMR. It operates its own pharmacy network rather than routing exclusively through Surescripts, the dominant US e-prescribing network. That lowers cost, but it means a pharmacy not enrolled with Weno cannot receive electronic prescriptions until it signs up — which is the friction described here, and a recurring complaint in regions where local pharmacies have not enrolled.

DoseSpot

DoseSpot: https://dosespot.com/

• Sherwin's current go-to alternative is DoseSpot. He built an integration module for a client earlier this year that went well, and the client permitted him to publish it.
• Where it is published: not on Packagist. It is listed on the third-party modules wiki page reached from inside OpenEMR. His only Packagist module is the PillPals one.
• Suggested as a candidate for priority attention: if Weno is causing problems and practices need options, a proven DoseSpot integration is worth a look.

DoseSpot is an embeddable e-prescribing service for EHR vendors, certified for electronic prescribing of controlled substances (EPCS) and routed through Surescripts, which gives it broad US pharmacy coverage. It is designed to be integrated into a host application via API, which fits the module model well. It is a commercial service with per-prescriber pricing.

Discoverability of Modules — Two Separate Pages

Website menu → Modules: https://www.open-emr.org/modules/

In-application Manage Modules → 3rd Party Modules button: https://www.open-emr.org/wiki/index.php/OpenEMR_Modules

• The third-party modules wiki page is reachable only from inside OpenEMR. It is not linked from the wiki itself or the website. Several people on the call did not know it existed until shown the route: Modules → Manage Modules → Visit third-party modules wiki.
• It was once linked more widely and was removed deliberately, according to Sherwin, though the reason was not known.
• The likely rationale: the website Modules page lists modules that have been through code review — in core, or on Packagist having originated in core. The third-party page lists modules that have not, and the project may not want to appear to endorse those.
• The counter-argument, put strongly: the project is pushing contributors to build modules and distribute them independently precisely so it does not have to maintain them. Then declining to link to them does not make sense. If contributors are being pushed there, users need to be able to find what exists.
• Proposed resolution: one integrated presentation. The website Modules page should point to the wiki, and the wiki should distinguish clearly between core modules and third-party modules, with a disclaimer that third-party modules have not been reviewed and are used at the operator's own risk. A link to Packagist should also be included. At present the wiki page does not even state that its modules are third-party.
• Sherwin's view on why the in-app route still matters: nearly everyone who installs OpenEMR visits the modules screen — some install every module just to see what they do. So the link from there is seen. Actual requests for his listed modules have been few, perhaps three or four.
• His expectation: module listings may matter less now that anyone can build a module with AI. The catch is that AI-built modules often work but do not follow OpenEMR conventions, and are not portable — installed elsewhere, they depend on things that were never there. That kind of development will get people into trouble.
• On wiki editing: anyone with an account can create a page by linking to it from an existing page and following the link. Sherwin said he tends to keep within what he considers his lane; he was encouraged not to feel limited.

This is the discovery half of the module-policy discussion from 9/15. That meeting clarified that modules can go to Packagist; this one found that the project's own in-application link to third-party modules points to a page most people cannot find by any other route. An aggregated listing — core, reviewed, and third-party, clearly labelled — would close the loop, and the module-registry idea raised on 9/15 is essentially the same thing.

The Project Website

• The homepage was described as crowded, with a lot of scrolling and a parallax background effect that was impressive when built in 2019 but is now distracting. The lecture series and blog sections are not especially active and might move to their own pages.
• Items flagged as outdated: the ONC certification wording and trademark notice, and the OSI certification badge. A privacy policy is also needed; rather than reviving a third-party policy-generation service, it could be drafted directly with AI assistance.
• The “Who Uses OpenEMR” section lists IPPF (International Planned Parenthood Federation, a large deployment from Rod's era), the Peace Corps, and Siaya District Hospital, among others — some of which may no longer be current.
• Sherwin's observation: enterprise users are underrepresented on the site even though a number of enterprises run OpenEMR.
• A broken link was spotted on one vendor listing during the call — a missing character in the URL.

A correction to the call: OSI is the Open Source Initiative, not Institute. Founded in 1998, it maintains the Open Source Definition and approves licenses as OSI-compliant. OpenEMR is licensed under the GPL, which is an OSI-approved license, so the underlying claim remains accurate, though the badge's styling may be dated.

Fundraising from Professional Support Providers

• Sherwin proposed writing to the listed professional support providers asking them to increase their financial contributions to the foundation. His reasoning: anyone making a living from OpenEMR should find ways to contribute more financially, and he has recently raised his own contribution.
• On persistence: people become desensitized to appeals, but organizations that keep asking keep receiving. People tend not to give when nobody is asking, on the assumption the need has been met.
• Support for the idea: it would also open communication with vendors who are generally quiet — very few attend these calls or reach out.

Node to PHP — Progress

• Jerry replaced the Node Schematron service with PHP, now merged. Initially thought on the call to be the CCDA service; checking the commits confirmed it was Schematron, the validator run on CCDAs after generation. It originated in its own repository, was brought into core, and has now moved off Node.
• Jerry is now working on the CCDA service itself, building on the branch Eric started, and on FHIR-related work. He also contributed a number of portal fixes to 8.4.1.
• Every Node dependency removed is one less thing to build into the Docker images and maintain.

This corrects the status given on 9/8, when the CCDA branch was described as stalled and open to anyone. Schematron was the smallest of the three Node services and has now landed; CCDA is actively being worked; CQM remains the harder port.

Items Discussed and Proposed

Recorded as topics raised and directions favored, not as assigned work or commitments.

Area	Discussed / Proposed
Release	8.4.1 released, exercising the patch-release workflow for the first time. Expect more patch-level releases for security-only changes.
Operator workarounds	A version-scoped list of mitigations for operators unable to upgrade immediately, generated from published advisories and included in release notes.
Front controller	In master and in the release but off by default. Turning it on in the distributed version is what enables centralized fixes.
Module system	Version 1.0 scoped to API, CLI, and database hooks. Template overrides deferred to later non-breaking versions. Feedback still wanted.
Simon Quigley	Four open PRs and a Medicare billing fix in progress. No objection to bringing them into core; LBF module still awaiting a policy follow-up.
Modules pages	Consolidate the website Modules page and the in-app third-party wiki page into one listing, clearly separating core and third-party, with a disclaimer and a Packagist link.
E-prescribing	Weno's pharmacy coverage is a recurring problem. A DoseSpot integration module exists and was suggested for attention.
Website	Homepage is crowded and partly outdated. Privacy policy needed. Enterprise users are underrepresented.
Fundraising	Proposal to ask listed professional support providers for increased contributions.
Node to PHP	Schematron converted and merged. CCDA conversion now in progress.

Notes

• A small meeting with both usual chairs absent, run informally. The conversation ranged widely as a result, and some of the most useful material came from practitioners describing what they are actually seeing in the field.
• Recurring theme: discoverability. The module listing reachable only from inside the application, the unanswered question of what is and is not endorsed, and the outdated homepage all point the same way — the project is asking contributors to build modules and asking operators to stay current, but the information needed to do either is scattered. Community members interested in helping consolidate the modules listing or refresh the website would be making a very practical contribution.