Endear DSCSA Module — proposing for core inclusion

Hi all — we released the Endear DSCSA Module last week: an open-source (GPL-3.0) module that adds DSCSA-required serialized inventory tracking, GS1 scan-and-trace, and EPCIS/AS2 connectivity directly into OpenEMR, with no core-file patches required. An optional DSCSA+ layer adds CSA/controlled-substance compliance on top.

Source is on GitHub at GitHub - endearai/oe-module-endear-dscsa: DSCSA serialized-inventory integration for OpenEMR with CSA option for controlled substance · GitHub , and it’s also available via Composer as endear/oe-module-endear-dscsa.

Given that other modules have shipped as part of the core codebase before, registered and installed the same way any custom module is, we’d like to propose the same path for this one.

The small-dispenser DSCSA deadline is November 27, 2026, so there’s a real, dated reason OpenEMR practices would benefit from having this available directly rather than finding it separately.

Happy to open a PR against interface/modules/custom_modules/ if that’s the preferred path, or to discuss on the Tuesday call. What’s the right next step?

Hi @endear ,

I have a question regarding physician clinics. For a clinic that purchases and administers medications, is it necessary to maintain an internal inventory that tracks the serialized product identifiers for every package received? Or is it sufficient to receive the serialized transaction data from the wholesaler and have access to it through the wholesaler’s portal when needed?

In other words, does the clinic itself need to store and manage the serial numbers locally, or is maintaining access to the wholesaler’s electronic records considered compliant?

I’d appreciate any clarification or references to guidance. Thank you!

Moussa, good question. Though I would disclaim that I am not a lawyer so the definitive answer rests with your compliance officer, my answer actually depends on whether the clinic is dispensing (patient walks out with the product) or administering it in-office (buy-and-bill infusions, injectables, in-office chemo, etc.) — DSCSA treats those two situations differently.

If the clinic only administers product in-office and never sends it home with a patient, there’s a specific practitioner exemption in the statute (21 U.S.C. 360eee-1) for licensed practitioners administering product in the usual course of professional practice. That exemption removes the product tracing and verification requirements — you’re not required to capture or maintain Transaction Information and Transaction Statements the way a pharmacy dispenser is. It doesn’t remove everything, though: you’re still required to only receive serialized product and to only transact with authorized trading partners. So even under the exemption, most practices end up wanting some record of what came in and from whom, just not the full TI/TH/TS package a pharmacy has to keep.

If the clinic dispenses in the pharmacy sense (fills a prescription the patient takes home), the exemption doesn’t apply and full dispenser obligations kick in: six-year retention of transaction records, verification obligations for suspect or illegitimate product and for saleable returns, and the ability to produce transaction information within two business days if the FDA or a state official requests it as part of a recall or investigation.

On your actual question — does the clinic need to store the serialized data itself, or is wholesaler portal access enough — for that second, full-dispenser case: a wholesaler’s portal can absolutely be part of a compliant setup, and DSCSA doesn’t say the data has to live on your own server. But the legal recordkeeping, verification, and quarantine obligations stay with the dispenser, not the wholesaler. The wholesaler storing the data on your behalf doesn’t transfer your obligation to produce it — so if that portal access lapses, the wholesaler relationship ends, or the data isn’t retrievable fast enough when FDA actually asks, that’s a compliance gap on the clinic’s side, not the wholesaler’s. That’s the practical risk a lot of practices are weighing when they decide whether “I’ll look it up in the portal if anyone ever asks” is good enough for six years, versus keeping their own copy.

Primary sources worth reading directly rather than taking my summary as the final word: 21 U.S.C. 360eee-1 for the statutory requirements and the practitioner exemption, and FDA’s DSCSA guidance page (fda.gov/drugs/drug-supply-chain-integrity/drug-supply-chain-security-act-dscsa) for the current guidance documents, including the waivers/exceptions/exemptions page. Since which bucket a given clinic falls into (administering-only vs. dispensing) genuinely changes the answer, and there’s real money/compliance risk either way, I’d run your specific setup past whoever handles your regulatory counsel rather than relying solely on a forum reply.

1 Like

If I may, this is actually the exact gap our free Endear DSCSA Module was built to close. Instead of leaning on a wholesaler portal you don’t control, the module scans in each serialized unit as it arrives, keeps that transaction/verification record locally in your own OpenEMR database, and handles the point-of-care verification and suspect/illegitimate product workflow directly inside your existing scan-in/scan-out process — so the record is yours, retrievable on your own timeline, and not dependent on a vendor relationship staying intact for six years. It allows you to scan each item into the Drug Inventory inside OpenEMR so it saves you time avoiding any manual entries. It allows you upload the CSVs containing serialized data from wholesalers and scan and verify against, identifying any discrepancies in scan time. It’s open source and free to install from GitHub: GitHub - endearai/oe-module-endear-dscsa: DSCSA serialized-inventory integration for OpenEMR with CSA option for controlled substance · GitHub . Happy to answer questions here if anyone wants to see how it maps to the administering-vs-dispensing distinction above for their specific setup.

1 Like

Hi @endear ,

We’re trying to actively remove the packaged-as-core modules from core, in favor of having them be separately installable, so this is not something we would likely accept as a PR into core. Installation through Composer is the preferred method going forward.

Relatedly, we are looking at overhauls to how modules work in general and would value your feedback! Please see feat(plugins): RFC: Plugins (a.k.a. modules 2.0) by Firehed · Pull Request #12643 · openemr/openemr · GitHub for examples and links to related discussion. Long term, we want to have a clear listing of verified modules; it sounds like what you have here may be a good candidate when that time comes.

Feel free to join the call on Tuesday either way though! Modules are a very frequent topic and a fresh set of eyes are welcome.

Thanks for the quick answer, and for the RFC link — read through it.

A few observations: it’s still early/draft stage (the “Still To Do” list includes activation tooling, DB uninstall handling, docs, auth strategy, and a certification process). So there’s no verified-module listing to join yet — that’s infrastructure that doesn’t exist yet, not something we’re missing today. The direction is clear though: plugins as Composer/Packagist packages versioned against a stable interfaces package, with an installer plugin generating a runtime manifest. That’s structurally the same model we’re already using (endear/oe-module-endear-dscsa via Composer), just with formal interfaces eventually replacing the current custom_modules/ convention.

Given that, we’ll keep shipping via Composer and won’t pursue a core PR — makes sense to align with Modules 2.0 once it lands rather than today’s pattern.

Two things we’d raise on Tuesday, and happy to comment on the PR directly too:

  1. The three hook types (API, CLI, migrations) don’t obviously cover a scheduled/background job — e.g. periodic EPCIS/AS2 outbound polling, which is core to how DSCSA connectivity runs day to day. Curious whether that’s meant to ride on the CLI hook plus external cron, or if a fourth plugin type is planned.
  2. We’d be glad to be a second real-world test case for the plugin API alongside sjpadgett’s Institutional module — a compliance/integration module with outbound network calls and its own migrations is a different shape of stress test than most examples so far.

We’ll join Tuesday either way — thanks for the steer.

1 Like

Sounds good, looking forward to your feedback. I may nor may not be able to make the next call, but others there should be reasonably familiar with what we’ve been discussing for this infra.

We’d likely steer the background polling you mention towards CLI tools and cronjobs; there is existing background services infrastructure, but it may get reshaped eventually too through modernization efforts. It’s a near-certainty that we will add other plugin types in the future, but probably under a v1.1 interface.