340B Compliance Software: How a Covered Entity Proves Every Accumulation Was Eligible

Why 340B software is a compliance system, not a pharmacy tool

The 340B Drug Pricing Program sits in section 340B of the Public Health Service Act and is administered by the Health Resources and Services Administration. The mechanics sound simple. Buy covered outpatient drugs at the ceiling price, dispense them to eligible patients of the covered entity, and keep the difference to fund care. Every word in that sentence is a compliance test, and your software has to answer each one for every dispense, thousands of times a day, in a way that survives an audit two years later.

Here is what the failure actually looks like. A manufacturer audit letter arrives asking for supporting documentation on a sample of accumulations at one contract pharmacy over a named quarter. The 340B director pulls the vendor report, which shows the dispenses qualified. The manufacturer wants the underlying evidence: the encounter that made the patient a patient of the covered entity, the location where that encounter occurred and whether it was a registered site on the date of service, the prescriber's relationship to the entity on that date, and proof the claim was excluded from Medicaid rebate. Three of those four live outside the 340B vendor. They live in the electronic health record, in the credentialing system and in a spreadsheet of clinic registrations someone maintains by hand.

Verity Solutions, Sentry Data Systems, Macro Helix and SUNRx all do the arithmetic well. Accumulation, virtual inventory replenishment and ordering against a wholesaler account are solved problems. What they do not own is the qualification evidence, because that evidence is a fact about your organisation, not about the drug. The gap between the vendor's calculation and your organisation's evidence is where audit findings and repayment obligations live.

Problem 1: patient definition is a judgement your software has to encode

Whether a person is a patient of the covered entity for a given prescription is not a field in any system. It is a determination built from an encounter at a registered location, a prescriber with an appropriate relationship to the entity, and responsibility for care that the entity actually holds. Every health system reads the boundaries of that determination slightly differently, and every policy committee revisits it after the last audit.

Off the shelf tools implement this as a set of configurable filters over the prescription feed: department codes, location lists, prescriber lists. That works until your organisation acquires a practice, opens an infusion suite in a leased building, adds a telehealth clinic whose location code is a virtual department, or starts a co-management arrangement with a specialty group. Each of those breaks a filter, and the break is silent. Nothing errors. Accumulations simply keep going against a location that is no longer what the filter assumed.

What a custom build does: express qualification as versioned, dated rules rather than filter lists. A rule knows the registration effective dates for each child site, so a dispense on a date before the site was listed does not qualify, and the system says so at the time rather than during an audit. Every qualification decision writes an explanation record naming the encounter, the location, the prescriber relationship and the rule version applied. That record is the artefact an auditor wants, and it costs almost nothing to produce if you write it as you go and almost everything to reconstruct if you do not.

Problem 2: the prescriber roster is stale the day you build it

Eligible prescriber determination depends on the prescriber's relationship to the covered entity on the date of service. Employed physicians, contracted physicians, residents rotating through, locums covering a week, and referral relationships all sit at different points on that spectrum, and every one of them changes constantly.

The common practice is an exported list refreshed monthly. That list is wrong within days. A physician who terminated on the fifteenth keeps qualifying until the next export, and every dispense in that window is an overstated accumulation you will eventually repay.

What a custom build does: read prescriber status from the source that already knows, which is the credentialing or provider enrollment system, and hold it as a time series rather than a snapshot. Qualification then asks whether this prescriber held a qualifying relationship on this date of service, and answers correctly for retroactive corrections too, which matters because provider data is routinely backdated. When the roster changes, prior accumulations affected by the change are flagged for reversal instead of quietly staying wrong.

Problem 3: contract pharmacy accumulation and the duplicate discount trap

The duplicate discount prohibition is the sharpest edge in the program. A unit cannot carry both the 340B price and a Medicaid rebate. Preventing that requires knowing, per claim, whether the payer was Medicaid fee for service or a managed Medicaid plan, and how your entity has declared itself in the Medicaid Exclusion File for that state and that billing number. Carve in and carve out decisions differ by state, by entity type and sometimes by site.

The contract pharmacy layer makes it worse, because the claim data arrives from the pharmacy through a switch or a third party administrator, the payer identification is inconsistent, and managed Medicaid plans frequently present under a commercial looking payer name. Vendors apply a payer mapping table. Those tables age, and nobody owns them.

What a custom build does: keep payer classification as a maintained, testable rule set with a review queue for unrecognised payer identifiers, rather than a static lookup that fails silently to a default. It also runs the reverse check: reconcile accumulations against the Medicaid claims your billing system actually submitted, so a mismatch surfaces as an exception the same month rather than in a state audit. Add explicit handling for the group purchasing organisation prohibition where it applies to your entity type, because a covered outpatient drug bought on a group purchasing contract at a disproportionate share hospital is a finding regardless of intent.

Problem 4: manufacturer restrictions change the rules faster than a vendor releases

Since 2020 manufacturers have imposed a shifting patchwork of conditions on contract pharmacy arrangements, many of them requiring claims data submission through a designated third party platform as a condition of continued 340B pricing. The specific conditions differ by manufacturer, change with little notice, and interact with your own contract pharmacy footprint.

Packaged platforms respond by adding a connector when enough customers ask. That is a reasonable commercial decision and a poor operational one for you, because in the gap your entity is either submitting data it does not have to submit, or losing 340B pricing on products it could have claimed.

What a custom build does: model manufacturer policy as data with effective dates, so you can answer which products at which pharmacies are currently restricted and what the financial exposure is, and generate the required submissions per manufacturer format without waiting for a vendor release cycle. Because the underlying claim data is already in your system for qualification, adding a submission format is days of work rather than a roadmap conversation.

Problem 5: an audit asks for one claim, and you have days

An audit does not ask for your policy. It picks specific accumulations and asks you to prove them. If assembling that proof means one person joining a vendor export to an electronic health record report to a credentialing spreadsheet, you will spend a week per sample and you will find inconsistencies you did not know about while an auditor is watching.

What a custom build does: store the qualification decision as an immutable, append only record at the moment it was made, with the inputs, the rule version and the outcome. An audit sample becomes a query. Self audits, which HRSA expects covered entities to perform, stop being a quarterly project and become a scheduled job that samples, checks and reports on its own.

What a 340B build costs and how long it takes

A first release covering qualification rules with dated site and prescriber logic, split billing accumulation, Medicaid exclusion handling and an audit evidence store runs $70,000 to $150,000 and ships in 12 to 18 weeks in our experience. A full platform adding contract pharmacy reconciliation across multiple third party administrators, virtual inventory and ordering, manufacturer submission formats, savings analytics by service line and self audit automation runs $180,000 to $450,000 phased over 6 to 12 months.

What drives cost up for covered entities specifically: the number of registered child sites and how messy their location coding is inside the electronic health record. The number of contract pharmacies and third party administrators, because each brings its own claim file format. Mixed entity types under one parent, for instance a disproportionate share hospital that also operates a grant funded clinic, since the group purchasing prohibition applies to one and not the other. Multi state operations, because Medicaid carve decisions and managed Medicaid identification differ per state. And retail and specialty pharmacy owned by the entity, which pulls dispensing system integration into scope.

What keeps it down: start with the owned pharmacy and the two largest contract pharmacies, one state, and the qualification and evidence layer only. Leave ordering and inventory on the incumbent for the first phase. The qualification and evidence layer is where the audit risk sits, and it is the part no vendor can do for you.

Build versus buy, and when the vendor is right

Buy if you are a single site health centre or a critical access hospital with one or two contract pharmacies and stable clinic registration. Verity Solutions, SUNRx, Sentry Data Systems and Macro Helix will run that program competently for a fee that is far below what a build plus ongoing maintenance costs you, and the compliance surface is small enough that spreadsheet evidence still works.

Build when the qualification determination has become genuinely organisation specific. In practice that means: more than roughly a dozen registered child sites, more than a handful of contract pharmacies, employed and contracted prescribers mixed together, operations in more than one state, or a history of an audit finding you fixed with a manual process that is still running today. Also build if program savings have become material enough to your operating margin that a percentage point of qualification accuracy is a real number, because at that point the difference between a filter list and a dated rule engine is worth engineering.

Our honest position: most health systems should not replace the vendor's ordering and inventory engine. They should build the qualification and evidence layer above it and keep the vendor for the mechanics. That split gets you the audit defensibility without rebuilding a wholesaler integration nobody needs to rebuild.

How to choose a developer for 340B software

Ask them how they would model a child site whose registration became effective in the middle of a quarter. If the answer does not immediately involve effective dating on both the site and the qualification rule, they will build you a system that is right today and wrong after the next registration cycle.

Ask how they will identify managed Medicaid claims arriving through a contract pharmacy file where the payer name looks commercial. A developer who has worked this problem will talk about payer identifier review queues and reconciliation against submitted Medicaid claims. One who has not will describe a lookup table.

Ask what they have integrated on the clinical side. Pulling encounters, departments, orders and prescriber relationships out of a specific electronic health record is the majority of the work, and the answer should name the system and the interface method, not the word integration.

Ask who owns the code, the infrastructure and the accumulated evidence data, and settle it in writing before kickoff. At Digital Heroes the client owns the repository from the first commit and the system runs in the client's own cloud account. Audit evidence that lives somewhere you cannot reach without a vendor's cooperation is not evidence you control.