Your 340B clients should have a CMS reporting plan
A covered entity's 340B claims can sit with several partners at once. What a TPA can take on, and what still needs an agreement with each client.
In my conversations with TPAs and covered entities, and on message boards I follow, CMS's proposed mandatory reporting comes up constantly. CMS has proposed making repository participation a condition of continued Medicare enrollment for covered entities that are Medicare providers or suppliers. Submissions are voluntary in 2026, starting October 1, with required reporting proposed for claims dated from January 1, 2027.
Knowing the dates is the easy part. Working out who supplies which claims, who checks them, and what a TPA can take on for its clients is where teams need people who've done this work before. I've spent my career in 340B TPA sales, implementation, and audits, and that's the part of CMS reporting I want to help TPAs get right.
What a TPA can take on
For TPAs, CMS reporting is a chance to offer clients a service they'll need, and CMS's rules leave room for it. Under CMS's current guidance, a TPA with delegated authority can submit and certify data on behalf of covered entities, and one submission can cover multiple clients.
As a result, the TPA's platform is the natural place to build reporting. Fix something once there, and every client gets the fix, under your name. Each covered entity is still responsible for the accuracy of submissions. Agree on the scope with each client, including which claims come from your platform and which don't.
Before offering that service, a TPA needs to know which of its clients' claims it holds and which live elsewhere. The gaps start there.
How to get every claim into the report
To check for gaps, you need to establish what you should have received. The checks below walk through that process for each client, from identifying the records needed to checking delivery timing and who reviews them.
Start with the pharmacies. CMS wants every 340B dispense a Medicare Part D plan covered and paid for, and fills from in-house and contract pharmacies both count. A TPA file built around contract pharmacies can leave the client's own pharmacy out entirely. Hold the file up against the client's pharmacy list, and you'll see which feeds you're missing.
Summary reports from a contract pharmacy network won't support a claim-level submission on their own. And watch the timing, because a pharmacy that sends a spreadsheet once a month leaves you far less time to review than a feed that updates every day. Our audits start with a source-by-source review of what each partner sends and when.
Some of this work belongs in the TPA's platform. A missing field across several clients' exports may require one export change, while an in-house pharmacy outside that feed needs a separate arrangement with its covered entity.
Review is an easy gap to miss. Ask the TPA who checked last quarter's file, and you might hear the pharmacy director. Ask the pharmacy director, and you might hear the TPA. Pick one person to own the review, and put in writing who chases a missing record before anything goes to CMS.
Prepare during the voluntary period
Under CMS's proposed timeline, the first required report would cover January to March 2027 claims. A missing feed discovered in May could mean going back to another partner for January records. Testing the process during the voluntary period lets your team work out how to obtain and review those records before the proposed reporting period.
Our DevDocs Audit starts with your claims data to map coverage and identify missing information. Once we know what's there and what's missing, we plan the build and the client rollout with you, including who submits. You walk away with something concrete to offer each covered entity, like which pharmacies are covered and who follows up when a file doesn't show up.
Book a 20-minute call with me, and we'll look at where your clients' claims stand.
Related posts from the studio.
SOPsWill your SOPs hold up when your veterans retire?
When a veteran leaves the jobsite or plant floor, the crew inherits whatever SOPs exist. Why that knowledge stays unwritten, and how to build SOPs that work in the field.
Process DocumentationSOP documentation is necessary for SMB growth
When a business scales fast, undocumented processes become expensive problems. Learn why SOPs are the infrastructure that makes growth stick.
Process DocumentationYour GDPR-compliant software doesn’t make you GDPR-compliant
Software may promise GDPR compliance, but that doesn't protect your business from potential litigation. Learn why technical GDPR experts are necessary for safeguarding against regulatory penalties.
Join the DevDocs Brief
Receive occasional notes from the studio: new articles, case studies, and documentation strategy updates.
See selected emailsTell us about your documentation challenge.
We respond within one business day.