Turning denied infusion claims into recovered revenue with an automated denial-management pipeline

Healthcare EHR Integration Engineering

65%

of denied claims are never resubmitted, recoverable revenue lost to manual rework capacity, not to unrecoverable claims

BACKGROUND

About the client

The client is a chain of oncology infusion centers, delivering infusion therapy across multiple sites in a corner of healthcare billing that is far more complex and far more denial-prone than general outpatient care. They were leaving real money on the table, and not because the claims were lost causes.

The pattern was consistent: denied claims piled up faster than their billing team could work them. Most were recoverable, a lapsed authorization here, a code mismatch there, but recovering each one takes time, and manual rework capacity simply could not keep up with the volume. Revenue that should have been collected was quietly written off because no one had the hours to chase it.

They came to us to fix the bottleneck at its source, inside their own revenue-cycle platform: an automated denial-management pipeline that ingests every denied claim, identifies exactly why it was denied, and routes it down the right resolution path, so recoverable revenue stops slipping through for want of manual capacity.

Domain

Oncology infusion centers

Compliance

HIPAA

Platform

Web

Integrations

Stedi: 835, 837, 278, 270/271

Tech stack

Node.js, PostgreSQL (Supabase), internal rules engine

The challenges

Infusion billing is uniquely complex

Every infusion claim carries a drug component (a J-code mapped to an NDC), an administration component (the CPT 96365 to 96417 series), and often a prior authorization that varies by payer and by drug. Three moving parts on every claim, each with its own way to fail, is what makes this domain so denial-prone.

Denials come from many different triggers

Lapsed prior auth, a J-code that does not match the payer formulary for its NDC, incorrect administration-code sequencing (initial versus subsequent hour), medical-necessity documentation gaps, and eligibility lapses between scheduled sessions. Each trigger needs a different fix, so there is no single resolution that works for all of them.

Manual rework capacity could not keep up

The revenue was recoverable; the hours were not there to recover it. As claim volume grew, the gap between denials received and denials worked widened, and recoverable dollars were written off by default rather than by decision.

Classification was the real bottleneck

Before anyone can fix a denial, they have to read the CARC and RARC reason codes and decide what actually went wrong. Done by hand across thousands of claims, that triage step alone consumed the capacity that should have gone into resolution and resubmission.

What we built

Denial ingestion and code-based classification

Denied claims flow back automatically through Stedi's ERA / 835 endpoint. The system parses each CARC and RARC reason-code combination and maps it to a defined taxonomy of denial reasons, so every denial is identified the moment it arrives instead of waiting in a queue for a human to triage it. An internal rules engine owns the classification and routing logic, which keeps it transparent and easy to extend as new payer behaviors appear.

A resolution workflow for each denial reason

Each denial type is routed to the workflow that actually fixes it.

Prior auth expired or missing: the system checks current authorization status through Stedi's 278 endpoint.

J-code / NDC mismatch: it cross-references the J-code to its NDC relation against the payer formulary.

Eligibility lapse: it triggers a real-time 270/271 eligibility re-check.

Medical necessity: it flags the claim for the clinical team to attach supporting documentation, then resubmits it as a corrected claim or a formal appeal.

Automated and semi-automated routing

Where a denial can be resolved by data the system can fetch and verify itself, it runs end to end automatically. Where a human judgment is genuinely required, such as attaching clinical documentation for medical necessity, it routes the claim to the right person with everything they need already assembled. The result is that staff time goes to the handful of claims that truly need it, not to triaging every one. Built on Node.js with PostgreSQL on Supabase.

Achieved results

The results

Recoverable revenue stops being written off

Denials that manual capacity could never reach are now classified and routed the moment they arrive, so recoverable dollars get worked instead of quietly lost to the backlog.

Every denial follows a defined, repeatable path

Instead of ad hoc rework, each denial reason has a known resolution, automated where possible, routed to the right person where not, so outcomes are consistent and nothing falls through the cracks.

Recovery that scales with claim volume

Because classification and the data-driven fixes run automatically, growing claim volume no longer demands a proportional increase in billing headcount. Staff focus on the few claims that need human judgment, and the pipeline absorbs the rest.

Book a live demo to see it in action

Book demo

RELEVANT CASES