Home / How It Works
The Pipeline, Step By Step

AI reasoning, human judgment, one continuous workflow — from denial letter to recovered revenue.

No black box. Here's exactly what happens between a claim getting denied and an appeal landing back on the payer's desk.

Step 1 — Ingest & Classify

Denial letters, EOBs (Explanation of Benefits), and payer correspondence arrive in dozens of formats — PDF, fax, payer-portal exports. The first layer parses these documents using OCR and structured extraction, then classifies the denial against its CARC/RARC reason code (the standardized codes payers use to explain a rejection).

  • Document parsing across PDF, scanned image, and portal-export formats
  • Automatic CARC/RARC code extraction and categorization
  • Routing to the correct payer policy library based on plan type

Step 2 — Reason & Draft

This is the core of the system: a retrieval-augmented generation (RAG) pipeline. Rather than relying on a model "memorizing" payer rules — which go stale the moment a policy updates — the system searches a continuously refreshed index of payer policies, LCDs/NCDs, and plan documents, and pulls the exact clause relevant to this specific denial reason.

The reasoning layer then evaluates whether the denial is contestable on documented grounds, and drafts an appeal letter that cites the specific policy language — not a generic appeal template with the patient's name swapped in.

Why this matters: a generic appeal gets challenged. An appeal that quotes the payer's own policy back at them, correctly, gets reviewed seriously.

Step 3 — Review & Recover

No appeal is auto-submitted. Every draft routes to a billing specialist for review, edit, and sign-off before it leaves the building. This isn't a limitation of the system — it's intentional design. The model's job is to remove the research and first-draft burden, not the accountability for what gets sent to a payer.

Once submitted, the claim is tracked through to resolution — paid, partially paid, or upheld — and that outcome feeds back into the system to sharpen future retrieval relevance and reasoning confidence.

The technical architecture, plainly

Retrieval Layer

Policies and plan documents are chunked, embedded, and indexed. Denial text is matched against this index dynamically — not a static lookup table.

Reasoning Layer

An LLM reasons over the retrieved clauses plus clinical documentation to determine contestability and the specific grounds for appeal.

Feedback Layer

Submitted appeal outcomes are logged and used to recalibrate retrieval relevance for similar future cases.

Human-in-the-Loop Layer

Every draft is reviewed by a specialist before submission — the system assists, it doesn't decide.

Why RAG instead of a trained classifier

Payer policy changes quarterly, sometimes more often. A model trained end-to-end on historical denial data goes stale the moment a payer updates a coverage determination. A retrieval-grounded approach lets the policy index refresh independently of the reasoning model — accuracy keeps pace with policy changes, not with retraining cycles.

Want to see this pipeline run against your own denial samples?

We're onboarding a small group of pilot hospitals before general availability.

Request a Pilot Conversation