infusion-only RCM platforms vs. general-purpose RCM vendors
Infusion billing runs on a different logic than most revenue cycle software assumes. General RCM platforms are built around a straight line: check eligibility, code the visit, submit the claim, get paid. Infusion doesn't work in a line. The steps that happen before a patient ever sits in a chair, how the drug gets sourced, what the authorization actually covers, which site of care the payer will pay for, all depend on each other. Get one wrong at the front end and the damage shows up weeks later as a denial nobody can trace back to its cause.
That's the real difference between an infusion-specific platform and a general-purpose one. What each system was built to assume about how billing happens either matches the way infusion actually works or it doesn't.
How fast infusion is growing and why that raises the billing stakes
Infusion therapy is set to grow at roughly 8.8% a year through 2035. Specialty biologics are driving a lot of that, along with chronic disease management and payers pushing more care out of hospitals and into outpatient clinics and homes. That's a long runway, and it's already showing up in deal activity: 2024 saw 11 announced infusion platform acquisitions, more than 2023 and 2022 combined. Investors are betting that scale and specialty pharmacy integration are where the value sits.
For a practice being acquired, or one just trying to grow, that means the billing infrastructure underneath has to scale without opening up new ways to lose money. Bigger volume on a broken foundation just means bigger losses, faster.
Zoom out and the pattern holds. The broader RCM market was valued at $172.24 billion in 2024 and is growing around 10.1% a year through 2030. In a 2024 Bain & Company survey of 200 healthcare leaders, RCM technology ranked as the top software investment priority, ahead of clinical systems. Yet in a separate survey of 226 medical groups, only 17% had automated more than 60% of their revenue cycle operations. That gap between investment appetite and actual automation matters more in infusion than almost anywhere else in medicine, because the claims are worth so much more per encounter and the coding has so much less room for error. Growth is accelerating right as payers are scrutinizing high-cost biologics more closely. Whatever platform a practice picks now is going to shape its numbers for years.
What prior authorization actually demands in a recurring infusion practice
In most of medicine, prior authorization is a single event. You get it approved, you do the procedure, you move on. Infusion doesn't work that way. The authorization isn't tied to a visit, it's tied to the drug, and the drug keeps getting administered on a schedule for months or years.
That means the authorization has to be in place before the first infusion. It has to spell out drug, dose, frequency, and duration, not just a diagnosis code. Payers usually require renewal every three to six months. And if the treating physician adjusts the regimen mid-course, a new authorization has to be triggered, even though the underlying diagnosis hasn't changed. Miss a renewal window and the denial lands on a claim where the drug has already been bought and given to the patient. There's no undoing that.
The trend line is not encouraging. Prior authorization denials climbed to around 31% in 2026, and specialty infusion and biologics, the highest complexity and highest cost categories, are driving much of that rise. Payers have every financial incentive to scrutinize this segment harder than almost anything else in their claims volume. Federal reform hasn't caught up either: recent CMS prior authorization rules don't touch recurring or continuation authorizations for ongoing biologic therapy. The burden of managing renewal calendars sits entirely with the practice, regulation or not.
Handling that well requires a few specific things, which is where platforms like Ruby RCM, a revenue cycle management tool built for infusion centers, focus their prior auth workflows. Submission, tracking, and renewal for every payer and every drug need to live in one workflow, not scattered across a dozen payer portals. Expiration alerts need to fire before the renewal window closes, not after a lapse has already caused a denial. And the system needs payer-specific intelligence: how long a given payer takes to turn around a request, what its first-pass denial rate looks like by drug category, how often appeals actually succeed. Platforms built specifically for infusion authorization, SamaCare is one example used by thousands of providers, exist because this is a distinct discipline within the broader prior auth landscape.
General-purpose platforms tend to treat prior authorization as a task with a status field: pending, approved, denied. Managing a lifecycle against a drug-specific renewal calendar and a payer-specific rulebook calls for something more granular than that. And the most common way this breaks down comes down to documentation. Missing clinical notes, an unclear diagnosis code, no step-therapy evidence on file. Any of those triggers a back-and-forth with the payer that eats the time between now and the scheduled infusion date.
The financial exposure built into buy-and-bill when billing is imprecise
Buy-and-bill means the practice buys the drug up front, at acquisition cost, before the patient is ever treated. The claim goes out after the infusion happens. The margin the practice earns lives entirely in the spread between what it paid for the drug and what the payer reimburses.
When that claim gets denied, the practice is still holding the bill for a drug it already bought and already gave to a patient, with no reimbursement coming. A single infusion encounter can run $5,000 to $50,000 in drug cost. That's a cash-flow event, not a rounding error in the back office.
Medicare Part B reimbursement for these drugs is tied to ASP-based pricing, and when drug acquisition costs rise faster than the periodic ASP updates that set reimbursement, the practice eats the difference. There's no mechanism to claw that back.
J-code precision sits underneath all of it. Every J-code maps to one specific drug and one specific unit of measure, per mg, per 10mg, per 100mg, or per vial, depending on the code. Get that math wrong and the practice bills for less than what it bought and administered, full stop. The NDC on the claim has to match the actual drug dispensed. Modifier rules shift depending on the payer and the acquisition model, and 340B modifier disputes alone are a frequent, well-documented category of denial. Units, NDC, J-code, and administration CPT all have to line up at once. One wrong field and the claim gets denied or underpaid.
General-purpose platforms usually don't have J-code unit calculators built around actual dose and drug, don't cross-reference NDC against J-code automatically, and don't flag when the billing pathway conflicts with how the drug was actually sourced. Underpayment carries its own risk, too: it doesn't announce itself the way a denial does. A claim paid at the wrong unit count still shows up as "paid." It just disappears into the remittance file quietly. Without reconciliation happening at the line level, that underpayment turns into a permanent write-off the practice never even notices happened.
How payer behavior on infusion denials differs from what general RCM denial logic handles
Denial rates industrywide have been climbing for years, from 30% in 2022 to 38% in 2024, and the initial denial rate across more than 2,100 hospitals and 300,000 physicians hit 11.81% in 2024. That's the backdrop. Infusion adds categories of denial that don't exist anywhere else in medical billing.
Multi-drug infusion encounters require correct sequencing, primary, concurrent, sequential, and push services all have to be coded in the right order. Get the hierarchy wrong and NCCI edits kick in, bundling the claim down to a single reimbursed service when several were actually performed. Payers also contest which drug counts as the "primary" infusion when more than one is given in the same visit, an argument that has nothing to do with clinical reality and everything to do with reimbursement math.
Then there's the authorization failure category covered above, showing up again at the claim stage: authorization expired, authorization didn't cover the actual dose given, authorization was tied to a physician who's no longer the one prescribing. Add NDC and J-code unit errors, 340B eligibility disputes, and site-of-care redirects, where payers push patients toward lower-cost settings and then deny or cut reimbursement for claims from the original site. White-bagging is its own problem: some payers require the drug to come from a designated specialty pharmacy rather than through the practice's own buy-and-bill, and practices that keep billing the old way on affected drug classes, oncology, rheumatology, and rare disease therapies among them, run into denials systematically, not occasionally.
The same denial reason code, the same CARC, can mean different things depending on which payer sent it, and the correct appeal path differs accordingly. A platform applying one uniform appeals process across every specialty is going to route infusion denials down the wrong path more often than not.
Well-run infusion practices treat denials as data, tracking why each one happened, where in the process it originated, and what operational fix actually prevents it from happening again, rather than as isolated paperwork problems. That only works with denial libraries broken out by drug class and therapeutic category. Aggregate the data into generic buckets and the signal needed to fix the root cause disappears into the noise.
Guidehouse's 2024 research found that 30% of healthcare leaders reported final denial rates between 3.1% and 5%, well above the 1% benchmark most revenue cycle teams should be aiming for. In infusion, where a single claim can be worth tens of thousands of dollars, the gap between a 1% and a 5% final denial rate is real money, every month, not a rounding difference.
What the platform architecture of each type actually produces in day-to-day operations
General-purpose RCM platforms are built for breadth. They're modular by design, meant to flex across specialties, which means infusion-specific needs, the PA lifecycle, J-code unit math, tracking the acquisition model, get handled through workarounds and add-ons that weren't built for this in the first place.
In practice, that pushes the exception-handling onto staff. Authorization expirations, NDC mismatches, CPT hierarchy conflicts, all things the system didn't anticipate, become manual catches instead of things the workflow prevents. Denial logic stays generic. Appeal templates aren't calibrated to how a specific payer treats a specific drug class. Reporting aggregates everything together in a way that buries the infusion-specific root causes. And underpayments get found, if they get found at all, because a staff member happens to notice something off in a remittance, not because the system reconciled it automatically.
An infusion-specific platform builds these functions in from the start. Authorization management lives inside the treatment schedule itself, with expiration calendars tracked by drug and by payer, rather than as a separate pre-service task. J-code unit calculation and NDC cross-referencing are functions the system performs, easing the burden on a biller working under deadline pressure. Denials get categorized by root cause, by payer, by therapeutic category, and appeals route accordingly. Remittances get reconciled line by line against billed units and contracted rates, so underpayments surface instead of quietly rolling into a write-off. Practice staff see outcomes and status; the system carries the actual mechanics of the workflow.
The operational difference comes down to where the complexity lands: on a general-purpose platform, infusion's complexity becomes manual work for staff to absorb. On an infusion-specific platform, the system absorbs more of that complexity, freeing staff to focus on judgment calls rather than routine processing.
One caveat applies to both. Automation only pays off when experienced people are behind it, making the calls that no rules engine can make on its own. An infusion-specific platform without knowledgeable oversight still misses edge cases. A general-purpose platform staffed by sharp infusion billers still runs into a ceiling the architecture itself put there.
How to evaluate whether your current platform is producing structural revenue loss
Some signs point to a system problem rather than a people problem. Authorization lapses that keep happening mid-treatment cycle, on claims where the drug's already been purchased and given, are one. So is a pattern of generic appeals, ones filed by CARC code rather than by actual root cause and the specific payer's appeal pathway. J-code or NDC errors that repeat consistently on claims for the same drug aren't random mistakes; that's a systemic unit calculation problem. Remittances posted without any line-level check mean underpaid claims are sitting there invisible, counted as paid when they aren't. AR aging past 90 days on high-dollar infusion claims because resolving the denial requires manual work the platform doesn't support is another. And if staff are spending large chunks of their week managing renewal calendars and logging into payer portals by hand, the platform isn't doing its job.
The distinction that matters here is between a performance problem and an architecture problem. Performance problems, staff bandwidth, training gaps, inconsistent process, can usually get fixed inside the current system. Architecture problems tend to resist that kind of fix. If the platform simply can't enforce the interdependencies infusion billing requires, no amount of staff skill closes that gap. Workarounds have a ceiling, and once a practice hits it, the losses become structural rather than occasional.
Practices evaluating an infusion-specific platform should ask a few direct questions. How does the system track PA expiration against the treatment schedule, by drug and by payer? Is J-code unit calculation automated against the actual dose, or is that still a field a biller fills in by hand? Are denials categorized by infusion-specific root cause with payer-level appeal routing, or just by generic CARC code? And does remittance reconciliation happen at the line level against contracted rates, or does the system just match aggregate payments and call it done?
The answers to those four questions say more about a platform's fit than any feature list or sales pitch ever will.
