Appeal — No Patient Left Denied

Inspiration

I read that 82% of prior-authorization appeals succeed when someone actually files them, but fewer than 1% of denied claims are ever appealed. That gap isn't a clinical problem — it's a workflow problem. The appeal process is manual, deadline-driven, and exhausting, so people give up before they even start. I wanted to build something that closes that gap by actually doing the work: triaging the denial, routing it to the right recovery path, and keeping a human in the loop only where a human judgment call actually matters.

What it does

Appeal runs the full prior-auth appeal workflow on UiPath Maestro BPMN. A case comes in, gets evaluated by an AI agent against clinical criteria, gets submitted to the payer, and if it's denied, a second agent classifies why — administrative error, medical necessity dispute, or missing info — and routes it accordingly. Administrative errors get resubmitted automatically. Medical necessity disputes go to a human clinician at a Human Gate, who reviews and decides whether to appeal. If the payer goes silent entirely, Maestro's timer fires and the case routes itself into triage without anyone having to notice it stalled. A real-time dashboard (an isometric diorama, a card view, and a command center) shows every case's actual journey through the process as it happens.

How we built it

The whole thing is built on UiPath Maestro BPMN — ten stations, two event-based gateways with timer and message catch events, two exclusive gateways for routing, two AI agents built in Agent Builder, and two API Workflows that connect Maestro to a small Node.js mock payer service over ngrok. The frontend is React/TypeScript/Vite, polling a real /api/cases endpoint that the BPMN process itself writes to as it runs. I built almost all of it with Claude Code across structured sessions, using Plan Mode before every architecture decision and a CLAUDE.md file with rules that had to survive context compaction — no process logic in the frontend, color only used for meaning, the data contract as the single seam between Maestro and the UI.

Challenges we ran into

UiPath's variable scoping across API workflows ate more of my time than anything else. The difference between $workflow.input.X, $input.X, and $context.outputs.X isn't documented clearly anywhere I could find, and I went through several rounds of the wrong syntax silently producing literal strings instead of resolved values — which created ghost entries in my data store that took real debugging to trace back to the actual BPMN task causing it. I also hit a wall trying to get Maestro's REST API to expose per-step execution data the way its own UI does; the standard Jobs API only gives you job-level state, not station-level. I ended up building a status-reporting layer myself — every BPMN task calls back to my own endpoint to report its current station — which turned out to be more honest anyway, since I could document exactly what's real and what's derived.

Accomplishments that we're proud of

Getting a real BPMN job to actually run end to end — agents reasoning, a gateway routing on a real determination, a human task pausing for Action Center, and the frontend updating from real Maestro data rather than a mock — was the moment this stopped being a frontend project with UiPath bolted on and became an actual orchestration system. I'm also proud of being explicit about the one part that's simulated: I don't have a real payer integration, so I said so, clearly, in the architecture diagram and the README, rather than pretending the whole thing is more real than it is.

What we learned

The honest simulation boundary matters more than I expected going in. It would have been easy to blur the line between what Maestro actually executes and what the frontend just renders nicely, and I think being precise about that — out loud, in the docs, in the demo — is what makes the technical claims defensible under questioning. I also learned that directing an AI coding agent at an architectural level is a different skill from being able to explain the resulting code line by line, and that gap is worth closing before a technical interview, not after.

What's next for Appeal

Replacing the mock payer with a real payer integration is the obvious next step, along with hardening the variable resolution issues I hit late in the build so the determination data is reliable on every case, not just the happy path. I'd also like to surface SLA urgency sorting in the case list — right now it sorts by recency, but a real case manager's priority is what's about to expire, not what just moved.

Built With

• agents
• claude
• javascript
• uipath