ProjectARC

Payers deny. ARC fights back.

Comment

ProjectARC — Autonomous Revenue Cycle

"Payers deny. ARC fights back."

Inspiration

US hospitals lose an estimated $262 billion every year to denied insurance claims. Industry-wide, 5–10% of every claim submitted is denied on first pass — and the work of fighting those denials back is almost entirely manual.

What pulled us toward this problem wasn't the headline number — it was the shape of the work. When a claim is denied, a revenue cycle team can't just "appeal it." They have to first figure out why it was denied, and the answer completely changes what happens next. A coding error is fixed, nothing like a clinical-necessity dispute. A clinical-necessity dispute is fixed, nothing like an eligibility lapse. An eligibility lapse is fixed, nothing like a duplicate-billing error. Each one needs different evidence, a different system, and a different human to sign off — all racing a hard, time-limited filing deadline that, once missed, means the money is gone forever.

That's not a workflow. That's a case — dynamic, branching, exception-heavy, with humans in the loop at exactly the moments that matter. The instant we framed it that way, UiPath Maestro Case stopped being "a tool we had to use for the track" and became the obviously correct foundation. A denied claim is a living entity that should route itself to the right agent, the right automation, and the right person. Nobody had built that. So we did.

What it does

ProjectARC turns every denied claim into a self-routing case on UiPath Maestro Case:

  1. A Denial Classification Agent reads the EOB and CARC code and decides which kind of denial this is.
  2. A Denial Path Router dispatches the case to one of four resolution paths — automatically, with no human deciding where it goes.
  3. A purpose-built agent for that path builds the fix: corrected billing codes, an evidence-based clinical appeal letter, a HIPAA-compliant patient outreach message, or a duplicate/technical billing diagnosis.
  4. A human reviews at the exact point liability, clinical judgment, or compliance demands it.
  5. The resolution is submitted to the payer via RPA, with explicit success/failure handling.
  6. The case monitors the outcome asynchronously — waiting, polling, and resolving to approved, denied, or still-pending.
  7. Stakeholders are notified by email at every meaningful outcome.

The four paths

  • Path A — Coding Error: A Coding Correction Agent proposes corrected CPT/ICD codes → a Medical Coder approves → RPA resubmits → the case polls for the outcome and emails stakeholders the result.
  • Path B — Clinical Necessity: A Clinical Evidence Agent drafts an appeal letter → a Physician either signs it or sends it back for regeneration → on sign-off, RPA submits and the case polls and notifies.
  • Path D — Eligibility: A Patient Outreach Agent drafts a compliant message → a Patient Access Rep can regenerate it, hand-edit it (saved as a mail draft via RPA), or send it to the patient.
  • Path E — Duplicate / Technical: A Billing Review Agent decides whether the "duplicate" is a true duplicate (resolved internally, no resubmission needed) or a disguised technical error that must be corrected and resubmitted.

How we built it

We built ARC on the UiPath Platform as the orchestration and governance layer, with everything coordinated through one Maestro Case:

  • UiPath Maestro Case — the case definition, the denial path router, every exclusive gateway, timer events, human tasks, and the polling loops.
  • UiPath Agent Builder — five LLM agents: Denial Classification, Coding Correction, Clinical Evidence, Patient Outreach, and Billing Review. Each has a tightly-scoped system prompt, a structured JSON output schema, and temperature tuned to the task (0 for deterministic classification, slightly higher for letter drafting).
  • UiPath Studio (RPA) — deterministic actions: submitting to the payer, polling claim status, and drafting outreach mail. We kept these strictly separate from the agents.
  • UiPath Orchestrator — Task Catalog forms for the human checkpoints, plus process publishing, queues, and credentials.
  • Claude (Anthropic) — the reasoning engine behind every agent.
  • A FastAPI mock payer portal — simulates payer claim-status, appeal, and authorization behavior so the whole system runs reliably and repeatably for a demo.

A design principle ran through the entire build: the right tool for each job. Agents reason over unstructured information; RPA executes deterministic steps; humans decide where liability or compliance requires it. We never reached for an LLM where a rule or an API call would do — and Path E's "no resubmission needed" branch is deliberate proof of that discipline.

The asynchronous outcome monitoring is the pattern we're proudest of. After a successful submission, the case genuinely pauses on a timer, then polls the payer:

$$ \text{poll again} \iff (\text{status} = \texttt{pending}) \;\land\; (\text{poll_count} < 3) $$

When the payer resolves the claim, the case branches to approved, denied, or continued polling — and emails the relevant stakeholders with the outcome and the reason. It's a real wait state, not a timer that always succeeds.

What we learned

  • Maestro Case is a mindset shift, not just a feature. Once we stopped thinking in linear workflows and started thinking in cases that route themselves, the whole design fell into place. Gateways, timer events, and human tasks became natural expressions of how denial management actually works.
  • "The agent is wrong" is usually a data problem, not a prompt problem. Our Billing Review Agent kept misclassifying technical denials as true duplicates. We tightened the prompt repeatedly with no success — until we realized every duplicate claim was arriving with the same generic CARC description. The model literally didn't have the information to tell them apart. Feeding it the detailed issue description fixed it instantly. No amount of prompting can extract information that was never in the input.
  • Human-in-the-loop only matters if the human has real choices. Approve/reject is a rubber stamp. Letting a physician send a draft back for regeneration, or letting a patient access rep regenerate, hand-edit, or send — that's genuine human-in-the-loop, and it maps to how these decisions are actually made.
  • Graceful failure is a feature. Wiring an explicit status gateway after every API call — so failures send a notification and terminate cleanly instead of stranding a case — made the system feel production-real, not prototype-fragile.
  • Discipline beats density. We deliberately built four paths to a high standard rather than five at prototype quality. Knowing what to leave on the roadmap was as important as what we shipped.

Challenges we ran into

  • App Tasks wouldn't fire at first. Our earliest human task threw Failure in the AppTasks request. The cause: a Maestro User Task needs a published Task Catalog form and a linked Orchestrator folder before it can assign work. Once we built the form first and linked it back, the pattern clicked — and every subsequent human task went faster.
  • Maestro had no native HTTP activity. Our Maestro environment only exposed Task, User Task, and Agent Task nodes — no HTTP node. So Maestro couldn't call the payer API directly. We solved it by building small, reusable UiPath Studio processes that make the actual HTTP calls and hand results back to Maestro as outputs. One reusable submission process ended up serving multiple paths.
  • Localhost reachability. A Studio process that worked perfectly in standalone debug failed when triggered through Maestro — because the executing robot couldn't reach our laptop's localhost. Understanding where the robot actually runs, versus where the API lives, was a genuinely clarifying moment.
  • Unresolved prompt variables. An early agent debug run failed with every {{variable}} unresolved — because we'd hit debug without populating the Input panel. The placeholders were never being substituted. A small thing, but it taught us exactly how Agent Builder binds inputs at runtime versus design time.
  • Classification anchoring on the CARC code. As above — the hardest bug of the build turned out to be a missing input field, not a flawed prompt.

What's next for ProjectARC

  • UiPath Document Understanding at the front of the pipeline, ingesting raw payer EOB PDFs instead of structured input — so ARC starts from the same messy document a hospital actually receives.
  • Document Understanding for Path D — automatically extracting the patient's email reply and resuming the case for resubmission.
  • Path C — Authorization Issue — an RPA auth-lookup followed by agent-driven remediation (simple correction vs. retro-authorization with coordinator review).
  • Live payer portal RPA replacing the mock API for production-grade submission and polling.
  • An Escalation Agent with ROI-based legal-vs-write-off recommendations for the Revenue Cycle Director.

ProjectARC — Autonomous Revenue Cycle. Built on UiPath Maestro Case for AgentHack 2026. "Payers deny. ARC fights back."

Built With

Share this project:

Updates

Submission history