How to Vet an RCM Vendor for Combined Infusion Billing Software and Specialist Support

Vetting an RCM vendor for infusion billing is not the same exercise as vetting one for primary care or multi-specialty billing, and treating it that way is how practices end up with predictable, avoidable revenue problems. Infusion and buy-and-bill billing sits at the intersection of pharmacy benefit rules, medical benefit rules, specialty payer policy, and drug-level coding, and general RCM workflows were never built to handle that combination. Benefit investigation, prior authorization tied to a specific biologic, J-code unit validation, ASP-based reimbursement, and ongoing reauthorization each create a failure point that a generic billing platform treats as a rare exception, even though it occurs as daily business in infusion. Before a single sales call, you need to know that the standard checklist won't catch what actually goes wrong in infusion. That's the premise behind every criterion covered here: this evaluation needs its own bar, built around the workflows unique to infusion, not borrowed from a general RCM scorecard.

Your revenue cycle baseline before interviewing any vendor

A vendor conversation that opens with the vendor's pitch, rather than the practice's own numbers, tends to produce a generic shortlist dressed up as an infusion-specific one. Before any interview, a practice should pull its current denial rate broken out by payer and by CARC/RARC code, because a blended figure hides the patterns that matter. The authorization-to-claim match rate, and how often authorizations lapse before a claim is filed, tells a practice how much risk is already baked into its current process. With that baseline in hand, every question asked of a vendor can be checked against a real number from the practice's own history.

Whether the vendor's scope covers the full infusion revenue cycle, not just the claims portion

Infusion RCM vendors range from full-cycle partners to narrow billing specialists, and that scope mismatch is one of the most common sources of disappointment after a contract is signed. The full infusion revenue cycle runs through eligibility verification, benefits investigation (including the pharmacy-versus-medical benefit call), prior authorization, clinical documentation support, charge capture, coding and claims submission, denial management, payment posting, underpayment identification, AR follow-up, and reporting. For infusion, the steps before a claim is even filed, benefits investigation, prior authorization, and documentation alignment, are where most recoverable revenue problems start. A vendor that begins its work at claim submission has already given up the point in the process with the most leverage. That's why an infusion-focused platform like Ruby RCM structures its scope to cover eligibility, benefits investigation, prior authorization, and documentation support ahead of submission, rather than picking the relationship up after the fact. Any vendor should be able to map its scope against the full cycle and say directly where its job ends and the practice's begins, so gaps are known before signing instead of discovered after a denial has already piled up. If a vendor calls itself full-service but leaves out authorization management or benefits verification, it isn't full-service for infusion. Those exclusions mark the exact spots where revenue will leak.

Whether the vendor can demonstrate infusion-specific prior authorization lifecycle management

Prior authorization in infusion is a lifecycle that has to be tracked continuously through reauthorization windows, payer policy changes, and updated clinical data, rather than a single step completed at the start of treatment. Because a high-cost biologic is typically administered before the claim is adjudicated, a lapsed authorization means the drug has already gone into the patient and the practice is left absorbing the cost. Authorization tracking is a cash-flow protection function, not paperwork. CMS tightened prior authorization decision timelines effective January 1, 2026, under the CMS-0057-F rule, requiring affected payers to respond within 72 hours on expedited requests and seven calendar days on standard ones, which raises the stakes on how closely a vendor tracks payer turnaround. Vendors fluent only in primary care or multi-specialty billing tend to answer infusion-specific questions in generalities, while vendors built exclusively for infusion billing, Ruby RCM among them, answer in specifics: which payers require step therapy proof, how reauthorization windows get tracked, how the charge master update cycle runs. A vendor that only manages prior auth at initiation, with no ongoing reauthorization tracking, isn't equipped for any practice with a recurring infusion population.

Whether the vendor has a verifiable J-code validation and charge master update process

J-code billing doesn't generalize from other specialties the way a lot of coding work does. It demands drug-specific unit mapping, a quarterly HCPCS update process, and NDC-to-J-code reconciliation, and most general RCM platforms don't support that out of the box. Unit-count errors are a common failure point: J-code units are defined by the J-code descriptor itself, not by dose or by vial, and a vendor that doesn't enforce that distinction will systematically underbill or overbill high-dose infusions. Starting January 1, 2026, CMS rejects claims submitted with discontinued HCPCS codes, so if a vendor has no quarterly charge master update protocol, it will start generating automatic denials the moment a code it's still using gets retired. ASP-NDC mismatches cause their own damage: when the National Drug Code on a claim doesn't line up with the CMS quarterly pricing crosswalk, the result is a denial, a reimbursement discrepancy, or an audit inquiry. Wastage reporting adds another layer, since CMS has required the JW modifier since 2017 and the JZ modifier since July 2023, both with tightening validation of units billed against vials actually opened. New biosimilar launches require a charge master update before the first claim goes out, so if a vendor lags here, every claim submitted in that window is wrong. The right questions to ask: how does the vendor update its J-code and HCPCS charge master when CMS releases its quarterly pricing files, and who owns that workflow? A vendor with no charge master update protocol and no pharmacy reconciliation step is a claims submission vendor that happens to touch J-code claims, and the financial fallout lands on the practice, not the vendor.

Whether the vendor segments denial data by payer, code, and drug (not just by total rate)

A blended denial rate may be the least useful number an infusion vendor can hand over. Denial rates swing widely by payer, and a low average can hide a serious problem concentrated in a single payer or a single drug category. A vendor built for infusion should be able to break denials down by payer, so a payer running an outsized denial rate becomes visible instead of buried in an average. It should break denials down by CARC and RARC code, the adjustment and remark codes that explain the actual reason behind each one, because without that detail a team is treating symptoms instead of causes. It should segment by drug category or J-code, surfacing which biologics are generating a disproportionate share of denials, and by denial type, since medical necessity, prior authorization, coding, and timely filing each call for a different resolution path. For practices running multiple sites, the vendor should be analyzing denial patterns across all locations together: a pattern present at two of eight sites is visible only in a cross-site view, not in any single site's report. Denial management, done right, is an intelligence function that drives changes upstream, not just a queue that gets worked down. CMS's 2026 audit environment leans on targeted medical review and automated claim edits, so understanding denial patterns at the code level is a compliance posture as much as a revenue one. A practice should ask to see a denial trend report segmented by CARC/RARC code, payer, and drug category from a current client, and should ask the vendor how it tells apart denials that need an appeal from denials that signal an upstream process needs to change, what its defined appeal workflow and escalation timelines look like by payer, and how its denial patterns actually feed back into changes in authorization, documentation, or coding.

Whether the vendor identifies underpayments, not just denials

A reimbursement error can occur without a denial at all, appearing instead as a quiet underpayment. Payers can pay below a contracted rate, or below ASP + 6%, without the claim ever being rejected, so if a practice isn't reconciling actual payment against expected reimbursement, it will never know the difference. Medicare Part B reimburses most physician-administered drugs at ASP + 6%, and that figure gets recalculated every quarter, so if a practice doesn't update its expected reimbursement numbers each quarter, it won't notice when payments start drifting below that benchmark. The 835 remittance advice is where underpayment detection actually happens, and a vendor that isn't analyzing remittances at the line level, by CARC/RARC code, against contracted and ASP benchmarks, isn't managing underpayments at all, whatever else it calls its service. A vendor with no underpayment workflow isn't saving the practice money by avoiding the issue. The practice is losing that money, quietly, on every claim the vendor processes.

Whether the vendor's AR management is built for high-dollar, high-complexity infusion claims

AR management for infusion carries a different weight than it does for a primary care or multi-specialty practice. A single infusion visit can generate charges running from several thousand dollars to tens of thousands, so each aging claim is a real financial exposure, not just a line in a report. Top-quartile ambulatory infusion centers keep denial rates below 7% and days in AR under 30, but mid-market centers run 35 to 50 days in AR with denial rates above 7%, so they are sitting on recoverable revenue that just isn't moving. A capable infusion vendor needs prioritization logic that surfaces high-dollar claims first, rather than working a queue in the order claims arrived or alphabetically. It needs payer-specific follow-up timelines with clear escalation paths for when a payer goes quiet past its normal adjudication window, and it needs to separate denial-driven aging from clean claims still waiting on a payer, because those two situations call for completely different handling. None of that matters to a practice if it can't see the results. A practice should be able to view AR aging by payer, by drug category, and by claim status without running a manual report or tracking down the vendor for an update. And what can the practice actually see, in real time, about where its AR stands? That visibility question is the hinge point: a practice shouldn't have to manage AR itself to know where it stands.

Whether the vendor's operating model keeps practice staff out of billing workflows

An infusion RCM vendor that still requires practice staff to chase authorizations, pull denial reports, escalate underpayments, or monitor AR aging hasn't delivered an RCM operation. It has handed the practice a billing service that needs its own billing manager just to function day to day. The right division of labor puts authorization tracking and reauthorization, claim submission and follow-up, denial identification and appeal, underpayment detection and escalation, payment posting and reconciliation, and AR aging prioritization squarely on the vendor's side. The practice should see status and outcomes: authorization status by patient, claim status by payer, denial trends by category, AR aging summaries, without needing to manage the process generating any of it. The practice's job is treatment scheduling, clinical documentation, and the financial decisions that call for operator judgment, and that work should not require understanding the billing workflow underneath. Automation alone doesn't get a vendor to this point. It handles volume and consistency well, but infusion billing throws up decisions a rules engine can't make on its own: a payer-specific authorization exception, a contested underpayment that needs escalation, a denial carrying an ambiguous CARC code that needs clinical context to resolve. That's the layer where human judgment catches what automation misses, and it's the combined model, software paired with experienced operators, that Ruby RCM builds its platform around, with automation handling the prep work and its team making the calls that require judgment. The practical test for any vendor: ask what practice staff need to do on a weekly basis to keep the RCM operation running, and what would happen if they did nothing for a week. The honest answer should be close to nothing.

Structuring the vendor conversation for verifiable answers

The most common mistake in evaluating an RCM vendor is treating its self-reported metrics as proof. Any vendor can quote a clean claim rate, a denial rate, or a days-in-AR figure. What actually matters is whether that number can be checked against a client that looks like the practice doing the evaluating. Request a denial trend report from a current client in the same specialty (infusion, rheumatology, oncology, or gastroenterology), broken out by payer and CARC/RARC code. Ask for an authorization-to-claim match rate drawn from a recurring biologic population, not a description of a one-time authorization workflow. Ask for a specific example of an underpayment that was caught and recovered, along with the contract variance logic that flagged it. Ask to see a sample AR aging report in the exact form the practice would actually view it, not an internal vendor report the practice never gets access to. Ask for a reference from a client of similar size and payer mix who can describe directly what the vendor's team handles versus what still falls on practice staff. Testing those answers against a practice's own baseline data, its denial rate by payer and code, its days in AR, its authorization-to-claim match rate, its underpayment identification method, separates vendors that understand infusion's cash-flow exposure from vendors selling general billing software with an infusion label on it. Infusion platforms like Ruby RCM are built around that exposure specifically, so those are the metrics worth asking about. If a vendor declines to share client-level data citing confidentiality, that's a reasonable position, but it should still be able to de-identify the data and show the shape of the report. If it can't produce even that, the report likely doesn't exist. The transition decision comes down to a simple comparison: once the cost of staying with a mismatched vendor, in denied claims, underpayments, staff hours, and authorization lapses, outweighs the cost of switching, the decision has already been made. The point of running this evaluation carefully is to reach that answer before signing, not after a year of losses that could have been caught in the interview.