Skip to main content
ClaimJumper is an AI-assisted denial triage tool built for medical billing teams. It accepts a PNG EOB or remittance screenshot, extracts every denied service line into structured data, routes each line to the appropriate resolution lane, ranks the resulting work queue by deadline and recovery priority, and prepares cited draft artifacts for eligible lines — all before a human touches a single code. The core problem it solves is the triage overhead that accumulates when working a remittance: moving between the ERA/EOB, the billing system, payer guidance, and internal notes just to decide what to do next. ClaimJumper reduces that first-pass triage and preparation work. It does not replace coding, billing, compliance, or payer-specific judgment.

​
What ClaimJumper does

ClaimJumper runs a four-stage server-side pipeline on every uploaded remittance. Each stage is purpose-built to keep AI work inspectable and deterministic controls testable.

Structured ingest

GPT-5.6 Sol reads the PNG remittance with vision and extracts claims and service lines into a strict Zod-validated schema. Results are cached in samples/parsed/ by SHA-256 of the image bytes so repeated uploads skip the model call.

Denial routing

GPT-5.6 Sol recommends a lane for each denied line — appeal, corrected claim, patient bill, write-off, or human review — along with a rationale, required evidence, confidence score, and recovery probability. Code-enforced invariants run after the model decision.

Priority ranking

A deterministic scoring function (no model calls) computes an appeal deadline from the remittance notice date, an urgency score from days remaining, and a priority score from billed amount × recovery probability × urgency. Lines are sorted by deadline first, then priority score descending.

Draft artifacts

GPT-5.6 Terra drafts cited appeal letters and corrected-claim worklists for eligible lines. Citations are validated against the extracted remittance data and CARC/RARC legend before any artifact can render or export. Human-review lines receive a deterministic safety brief instead.

​
The five resolution lanes

Every denied service line is routed to exactly one of five lanes. The lane determines what ClaimJumper prepares and what the billing team must do next. In every lane, ClaimJumper prepares and organizes work. It never performs the payer-facing action.

​
Safety and human control

ClaimJumper is AI-assisted, not autonomous. Several layers of deterministic enforcement sit between the model’s output and any artifact that reaches the billing team. CO group code invariant. A CO (contractual obligation) adjustment code can never map to a patient_bill recommendation. This rule is enforced in code after the model decision, not only in the prompt, and is covered by regression tests. CARC 197 invariant. A CARC 197 denial (payer-responsibility denial) is escalated to human_review rather than routed to write_off automatically, because write-off eligibility depends on contract terms a model cannot verify. Confidence threshold escalation. Low-confidence routing decisions are escalated to human_review with explicit override reasons so the safety brief remains meaningful and auditable. Citation validation. Every citation in a draft artifact is resolved against the extracted remittance data and the CARC/RARC code legend. If a citation cannot be resolved to the expected value, the artifact is rejected before it renders or exports. Human approval gate. No artifact reaches the download bundle until a human reviewer clicks Approve on that line. Human-review lines cannot be approved. Patient-bill and write-off lines have a Mark handled disposition only — they are never eligible for the approved-drafts download.
ClaimJumper is AI-assisted, not autonomous. It never submits, files, emails, or otherwise sends anything to a payer. The downloaded bundle is a human-review work packet. A human must verify payer-specific requirements, supporting records, signer information, deadlines, and submission instructions before any artifact is used.

​
Architecture at a glance

The server-side pipeline processes every upload in a single request through five ordered stages.
Key modules and their responsibilities:
  • lib/pipeline/ingest.ts — Sends the PNG bytes to GPT-5.6 Sol via the OpenAI Responses API with a structured vision prompt. Parses and validates the response against the IngestOutputSchema with Zod. Caches results in samples/parsed/ keyed by SHA-256 of the image bytes.
  • lib/pipeline/triage.ts — Sends each extracted AdjustmentLine to GPT-5.6 Sol with a structured triage prompt. Validates the model output, then passes it through enforceInvariants to apply the CO and CARC 197 rules before returning the final DenialTriage.
  • lib/pipeline/invariants.ts — Non-negotiable routing safety rules. Runs deterministically after the model decision and adds override reasons to the triage record when a rule fires.
  • lib/pipeline/prioritize.ts — Deterministic deadline and priority scoring with no model calls. Computes the appeal deadline (notice date + 5-day receipt presumption + 120-day redetermination window), urgency score, and final priority score. Sorts the queue by deadline first, then priority score descending.
  • lib/pipeline/draft.ts — Calls GPT-5.6 Terra for appeal and corrected-claim drafts. Runs citation validation and artifact validation (prohibited phrases, required code inclusion) before returning. Produces a deterministic reviewBrief for human-review lines without a model call.
  • app/api/triage/route.ts — Server-side pipeline composition. Accepts a PNG upload via POST /api/triage, runs ingest → triage → prioritize → draft in sequence, and returns the fully assembled TriageResponse to the client.
  • app/lib/approved-drafts.ts — Client-side filtering and citation-preserving export. Collects approved queue items and assembles the plain-text download bundle.