08 Sep What 340B ESP Asks For and How to Submit Without Losing Discounts
A pharmacy director asked us recently why a manufacturer had restricted their contract pharmacy access when nobody at the entity had done anything differently. The answer was a submission that had quietly stopped running four months earlier, when the analyst who owned it changed roles. That is the shape of most 340B ESP problems. Not a disagreement about policy, an unowned process.
What 340B ESP Is and Who Runs It
340B ESP is a platform operated by Second Sight Solutions through which covered entities upload de-identified 340B claims data originating from contract pharmacies. The platform links that data against Medicaid and commercial rebate data supplied by pharmaceutical manufacturers in order to identify duplicate discounts, and notifies covered entities of duplicate Medicaid rebates so they can correct them.
It is a data-sharing mechanism, not a regulator and not a HRSA system. Manufacturers make their own participation conditions.
Where Manufacturer Conditions Come From, and Why We Are Not Listing Them Here
Individual manufacturers set their own 340B contract pharmacy policies and change them, sometimes several times a year. 340B ESP’s own front page currently carries notices of policy updates from multiple manufacturers, which tells you how often this moves.
We deliberately do not publish a manufacturer-by-manufacturer table of requirements. Any such list is wrong within a quarter, and an entity that acts on a stale table has a worse problem than one that had no table. Check the current notice for each manufacturer you purchase from, on that manufacturer’s own published policy or through 340B ESP, and record the date you checked. That date is the thing an auditor or a finance lead will ask you for later.
The Submission Workflow, Step by Step
Getting an account configured
340B ESP describes registration as free for covered entities, taking roughly fifteen minutes, using a work email address on the covered entity’s own domain. Configuration is where the decisions actually sit. You set preferences, invite users, and identify the contract pharmacies for which you will provide data. Get the pharmacy list wrong at this stage and every downstream submission is incomplete in a way nobody notices.
What claims data is requested
The platform takes 340B claims data originating from contract pharmacies. Per its published description, protected health information is removed or de-identified and the data is encrypted before it leaves the entity’s system, with the resulting data set intended to meet the HIPAA de-identified standard. The mapping step, where your file columns are matched to the platform’s fields, is the point at which most first submissions fail validation.
The mapping step, in more detail
Mapping is the point where an entity’s file columns are matched to the fields the platform expects, and it is where the institutional knowledge lives. Whoever does it makes a series of small decisions about which field in your dispensing system corresponds to which requested value, and those decisions are rarely written down anywhere afterwards.
Write them down. A one-page mapping specification naming the source system, the source field for each mapped value, the transformation applied if any, and the date it was last validated is the difference between a fifteen-minute reconfiguration after a system upgrade and two weeks of guessing. It is also the document that lets a successor take the process over without reverse-engineering it.
Frequency and deadlines
Cadence is set by manufacturer conditions rather than by the platform, which is precisely why it needs an owner. Uploading is quick once mapping is done. Remembering to upload is the hard part, and it is an operational problem with an operational fix.
Where entities most often break the chain
Four failure modes account for nearly everything we see. A staff change with no documented handover, the case at the top of this post. A new contract pharmacy added to the arrangement but never added to the submission list. A pharmacy data feed that changes format after a system upgrade, so files silently fail validation. And a submission that runs but excludes a location, because the original configuration predates a service line that has since moved.
Every one of those is invisible until a manufacturer acts on it. Testing for them is a defined, repeatable check rather than a project, and it is one of the things our compliance monitoring covers on a schedule so nobody has to remember to look.
The common thread is that none of them produces an error message anybody reads. A submission that stops running looks exactly like a submission that has nothing to report, and a submission missing one location looks exactly like a complete one. Whatever monitoring you put in place has to test for the presence of expected data rather than for the absence of failures.
If you have inherited an existing submission
Entities frequently ask us to review a process that has been running for years and that nobody currently in post has ever configured. The sequence we use is the same every time. Establish which contract pharmacies are registered in your OPAIS record, then which are listed in the platform configuration, then which appear in the last submitted file, and compare all three. Divergence between any two of those lists is the finding. Then confirm who receives the platform’s notifications, because that address is often a person who has left.
None of this requires access to the claims data itself, which is why it is a sensible first hour rather than a project.
What Happens When You Do Not Submit
The consequence is not a HRSA finding. It is a manufacturer restricting contract pharmacy access or declining to extend 340B pricing through those arrangements, and the loss lands on the entity’s savings rather than on its compliance record.
That distinction matters more than it first appears, because it decides who owns the process. A task with a compliance consequence attached gets a named owner, a policy and a review cadence. A task whose only consequence is financial tends to fall to whoever has capacity, and then to nobody, and the loss surfaces months later in a purchasing variance that finance attributes to something else entirely.
It also changes how the problem gets found. Nobody sends you a notice saying your submissions stopped. You find out when a pharmacy cannot obtain a product at 340B pricing, at which point the gap you are trying to explain is historical and the savings for that period are simply gone.
ESP and the Rebate Model Are Not the Same Thing
These are two distinct manufacturer mechanisms and they get conflated constantly. ESP is claims-data submission for duplicate discount resolution. The rebate model changes when an entity realizes the 340B benefit, converting an upfront discount into a payment after the fact. Different mechanism, different operational exposure, different internal owner. Our 2026 rebate model briefing covers that one, and this post stays out of it.
Building Submission Into a Compliance Calendar
Treat it exactly like recertification. A named owner and a named deputy, a recurring date that is not the last working day of anything, a documented mapping specification so a successor can rebuild it, a quarterly re-check of the contract pharmacy list against what is actually registered, and a log of the date you last verified each manufacturer’s conditions.
That last line is the one that pays for itself. It converts “we think we are compliant” into a record with dates on it, which is the same standard our compliance monitoring work applies to everything else in a 340B program.
Entities standing up the process from scratch usually want implementation support for the mapping and the ownership design rather than for the uploading, which is the easy half. If your third-party administrator sits between you and the claims data, our note on 340B TPA software covers what to ask them for.
And because the whole mechanism exists to resolve duplicate discounts, the submission process is only as useful as the Medicaid billing practice underneath it. Our explainer on Medicaid duplicate discounts is the companion read, and our full 340B services set out where submission support sits alongside the rest of a program.
FAQ
What is ESP in 340B?
340B ESP is the platform covered entities use to submit de-identified 340B claims data from contract pharmacies so that duplicate Medicaid and commercial rebates can be identified and resolved. Manufacturers use participation in it as a condition attached to their contract pharmacy policies.
Who owns 340B esp?
340B ESP is operated by Second Sight Solutions. It is a private platform rather than a HRSA system, which is why its requirements are set by the participating manufacturers and not by the 340B statute.