Centralized vs Site-Level RCM Functions in an Infusion MSO

An infusion MSO doesn't get to pick "centralized" or "decentralized" as a single answer. Every revenue cycle function has to be assigned individually, and the wrong assignment becomes visible fast: a lapsed authorization surfaces, a coding error repeats at every site, or a payment lands short and nobody notices. The infusion therapy market is growing at 8.6% a year through 2030, and that growth doesn't fix structural mistakes, it multiplies them, because a denied infusion claim isn't like a denied office visit. The practice already bought and administered the drug. A single bad encounter can mean a significant dollar amount sitting on the books with no guarantee it ever gets recovered.

That's the core tension in any MSO model. The MSO owns the financial outcome. The site owns the clinical encounter and most of the decisions that determine whether a claim actually pays. Neither over-centralizing nor over-decentralizing is automatically the failure mode. The failure mode is putting a given function at the wrong layer, full stop.

Three things make this harder in infusion than in a general medical MSO. Authorization timelines are long, they recur constantly, and they're specific to the exact drug, dose, and frequency, so they can't be handled reactively at a single site without someone eventually missing a renewal date. J-code billing and administration hierarchy require coding judgment that most site-level staff were never trained to apply. And because infusion runs on buy-and-bill, the practice is holding drug cost before a claim ever gets paid, which means every denial is also an inventory loss.

The front-end functions where site-level execution and centralized oversight must intersect

Revenue cycle control starts at scheduling, not billing. By the time a claim goes out the door, most of what will eventually cause a denial already happened, usually weeks earlier.

The front end is a set of workflows that all have to line up at once: It's a set of workflows that all have to line up at once:

• Eligibility and benefit verification has to confirm site-of-care coverage, whether the drug falls under the medical or pharmacy benefit, and whether the patient qualifies for copay assistance.
• Prior authorization has to open before the first infusion date, and it has to name the drug, dose, frequency, and duration, which means it can't even start until benefit verification is done.
• Drug acquisition method, buy-and-bill versus white-bag versus specialty pharmacy, changes what the authorization needs to cover and which administration codes are billable at all.

Pure site-level execution breaks here because most site staff don't carry payer-specific knowledge deep enough to catch the edge cases. A drug that's actually covered under the pharmacy benefit instead of medical needs a completely different authorization pathway, and if nobody catches that upfront, it stays hidden until the denial appears weeks later.

But pure centralization breaks here too. Physician order changes, last-minute regimen swaps, schedule shuffles: that all happens at the site, in real time, and a centralized team that isn't plugged into the site's calendar will miss it every time.

So the split looks like this. Benefit verification stays centralized, because no single site can maintain payer-grid knowledge across every active payer. Authorization submission stays centralized too, since it depends on portal expertise and document tracking most sites don't have bandwidth to build. Authorization monitoring and renewal triggers work best centralized with site-level alerts feeding back in, so the MSO owns the calendar while the site confirms nothing clinical has changed. Scheduling handoff, though, has to live at the site. The site is the one that sees a cancellation or a regimen change first, and it needs to flag that to the central PA team before the appointment, not after.

High-performing infusion centers see authorization approval rates of 95% or higher. Industry standard is 85% to 90%. That gap comes down to structural factors. It's structural.

Prior authorization as a recurring lifecycle for MSO structure, not a one-time clearance

PA in infusion never really closes out. Each patient requires a standing calendar that has to be maintained for as long as they stay on therapy.

Every treatment cycle needs its own submission and approval. The authorization has to match drug, dose, frequency, and duration exactly, because an approval for the wrong dose isn't a valid authorization, it just looks like one until the claim bounces. Payers typically require renewal on a recurring basis throughout the course of therapy. And any regimen change, a dose bump, a switch to a biosimilar, a change in frequency, triggers the need for a brand new authorization under most payer contracts.

This workload tracks chair count, not site count. An MSO opening a new location isn't just adding infusion chairs, it's adding a proportional stack of PA volume that someone has to manage.

Prior authorization delays patient care, and the administrative weight of fixing that falls on the practice, not the payer. The usual culprits behind PA denials are mundane and preventable: missing clinical notes, vague diagnosis codes, no documented step-therapy history, thin medical necessity narratives. None of that requires more effort to fix. It requires a repeatable process.

A centralized PA hub gives an MSO things a site-level coordinator simply can't replicate alone: tracking of payer turnaround times so submission lead times can be built around the slow ones, a renewal calendar spanning every active patient across every site, denial-reason pattern tracking by drug and payer that lets documentation improve before submission instead of after, and one-click renewal paths for patients on stable chronic therapy.

None of that works, though, if the site goes quiet. The site still has to report regimen changes and updated clinical documentation in real time. A centralized team working off a stale chart will submit an authorization for treatment the patient isn't actually getting anymore. The PA function belongs in a central hub, but the hand-off protocol between hub and site has to be built on purpose. It won't organize itself.

J-code billing and administration hierarchy: why coding cannot be decentralized in a multi-site infusion MSO

Wrong billing units. Missing administration codes. Undocumented drug waste. Mismatched drug codes. Each of these is a J-code error, and each one multiplies across every drug encounter, at every site, every single day.

Industry data indicates that a significant share of outpatient claim denials involving J-codes come down to erroneous billing units. That's the single most trackable, most preventable failure point in the whole coding chain. Every drug claim needs three data elements present and accurate, namely the J-code, the CPT administration code, and the NDC. Missing NDC data alone drives a large share of outpatient claim rejections.

Then there's sequencing. Oncology and rheumatology encounters routinely involve three to five drugs in one visit, and the hierarchy of primary, concurrent, sequential, and push services has to be applied correctly, or the claim trips NCCI edits and gets bundled into a denial. CMS has sharpened enforcement around wastage modifiers, including JW and JZ, along with closer validation of billed units against actual vials opened.

Fee schedules update on a regular basis. A site running an outdated schedule risks either systemic underpayment or an overpayment audit, and keeping that current across every payer at every site is not something a site-level team can realistically manage. Layer on 340B pricing rules, Medicare Part B requirements, clinical trial billing, and state step-therapy exemption laws, and it's clear this isn't a coding task anymore, it's a compliance function.

Decentralized coding fails for a simple reason: site coders build expertise around their local payer mix, not the MSO's full portfolio. There's no consistency across sites, so the same edge case gets handled differently depending on who's sitting at which desk, and what looks like random denial noise in the aggregate is actually site-specific coding drift. Worse, there's no feedback loop. A denial resolved at one site teaches that site something. It teaches the other four sites nothing.

Charge capture, documenting what was administered, when, and at what dose, is rightly a site-level clinical function. Turning that into a billable, compliant claim is not. That belongs centrally, with people who do infusion coding and nothing else.

Denial management as a centralized intelligence function, not a location-level recovery task

By the time a denial appears on an aging report, the decision that caused it is already days or weeks old. Denial management that starts at the remittance is playing recovery, not prevention.

Infusion denials cluster by payer and by root cause, and lumping them together generically across sites buries the signal that would actually let anyone fix them. Authorization denials in infusion often stem from mismatches rather than a complete absence of authorization, such as naming the wrong site, formulation, or dose. Site-of-care denials are their own animal entirely: site-of-care denials reflect payer pressure toward lower-cost settings, and fighting that requires a standing clinical appeals operation, not a one-off letter. The range of infusion denial types, from coding and documentation issues to modifier conflicts, requires targeted resolution approaches rather than a single generic workflow.

Medicare Advantage plans have become a concentrated source of denials. Payers have expanded automated claim review processes, and some initial denials come back quickly after submission.

Centralized denial management catches things a single site never could: a pattern showing up across multiple sites at once that would look like isolated bad luck anywhere else, a standardized appeals library built once and reused everywhere instead of rebuilt from scratch per denial, and a feedback loop back into front-end and coding workflows so denials start functioning as a diagnostic signal instead of just a cleanup job. There's also accountability. When denial management sits at the site, all it takes is one overwhelmed coordinator or one resignation, and appealed denials quietly expire while nobody's watching.

Site-of-care appeals in particular need standing infrastructure, documentation templates, escalation protocols, that no single site can sustain on its own. That's a centralized clinical function, period. And the pattern backs up why this matters: faster payments don't automatically produce better net revenue. Underpayments and unworked denials eat into collections even as payments arrive faster.

Underpayment identification: the remittance review function that only works centrally

Underpayments aren't denials, and that's exactly what makes them worse. The claim pays, the remittance posts, the claim closes out in the patient accounting system, and the gap between what the contract says should've been paid and what actually landed just disappears into the noise.

A denial at least generates a work queue item. Somebody has to look at it. An underpayment generates nothing. It becomes a permanent write-off unless someone is deliberately hunting for it.

Infusion makes this worse because of J-code complexity. A payer can pay the right drug code and still apply the wrong unit rate, the wrong contractual allowable, or a site-of-care differential that quietly shaves down reimbursement without ever triggering a denial flag.

Site-level staff aren't equipped to catch this. Reconciling a remittance line by line requires the contracted rate for every payer, every drug, every administration code, and that data set lives at the MSO level, not the site. Posting workflows are typically designed to record what the remittance says, not to flag whether the amount is contractually correct. And across several sites, small underpayments from the same payer can each look negligible on their own while adding up to real money in aggregate.

Payment posting can be split between site and center depending on volume. Reconciliation against contracted rates can't be. That has to be centralized, with line-level review, not spot-check sampling. It also needs a current payer contract database at the MSO level, a systematic variance-flagging workflow built into the RCM platform, and a clear escalation path for disputing underpayments before the contract's dispute window closes.

AR management and aging prioritization across sites: what the MSO must own vs. what sites can work

Infusion AR doesn't age the way general medical AR does. One unresolved infusion claim can carry more financial weight than a week's worth of primary care billing combined, so aging has to get prioritized by dollar value, not by claim count.

The failure pattern here looks familiar: a site's billing coordinator gets buried or leaves, unpaid claims and denials pile up in a queue nobody's watching, and by the time the MSO catches it, timely filing deadlines or appeal windows have already closed on part of the balance.

Centralized AR oversight needs two things above all. Real-time visibility into aging, broken out by site, by payer, and by denial reason, since the MSO can't manage what it can't see across the whole portfolio. And escalation protocols for high-dollar claims approaching an appeal deadline, because that kind of decision is too costly to leave to whoever happens to be covering the desk that week.