Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/sputhenofficial/claimjumper/llms.txt

Use this file to discover all available pages before exploring further.

This walkthrough uses samples/eob-001.png, the demo remittance screenshot included in the repository root. The sample is purpose-built to exercise all five denial routing lanes in a single upload — appeal, corrected claim, patient bill, write-off, and human review — and it is the same file used by the Vitest regression suite to validate invariants and pipeline behavior. Work through the steps below for a repeatable, end-to-end view of everything ClaimJumper does between receiving a PNG and producing an approved-drafts download.
1

Start the app

Start the Next.js development server from the project root.
npm run dev
Once Next.js prints the local URL, open it in your browser. You will see the ClaimJumper upload interface — a drop zone and a Triage button. The app has no login, no database, and no persistent state; everything lives in the current browser session.
2

Upload the sample EOB

Click the drop zone or drag samples/eob-001.png onto it, then click Triage.The browser sends a multipart/form-data POST request to POST /api/triage with the file attached as the eob field. The route handler validates that the file is a PNG (checking the eight-byte PNG signature), then runs the full server-side pipeline:
  1. Ingest (lib/pipeline/ingest.ts) — GPT-5.6 Sol receives the PNG bytes via the OpenAI Responses API with a structured vision prompt. It returns a Zod-validated list of claims and service lines. If the same image has been processed before, the cached result in samples/parsed/ is returned immediately.
  2. Triage (lib/pipeline/triage.ts) — GPT-5.6 Sol receives each extracted AdjustmentLine and returns a structured decision: lane, rationale, evidence needed, confidence score, and recovery probability. Code-enforced invariants run immediately after the model — a CO group code can never produce a patient_bill recommendation, and a CARC 197 denial is escalated to human_review.
  3. Prioritize (lib/pipeline/prioritize.ts) — a deterministic function (no model calls) computes the appeal deadline from the notice date, an urgency score from days remaining, and a priority score from billed amount × recovery probability × urgency. Lines are sorted by appeal deadline first, then priority score descending.
  4. Draft (lib/pipeline/draft.ts) — GPT-5.6 Terra drafts cited appeal letters and corrected-claim worklists. Citations are validated against the extracted data before the artifact is returned. Human-review lines receive a deterministic safety brief built entirely from the triage record — no model call required.
The assembled TriageResponse is returned to the browser as JSON and rendered as the ranked denial queue.
3

Review the ranked queue

The denial queue renders one row per denied service line. Each row shows:
  • Billed amount — the dollar amount billed for the service line.
  • Lane badge — a color-coded label: appeal, corrected_claim, patient_bill, write_off, or human_review.
  • Appeal deadline — computed as the remittance notice date plus a five-day receipt presumption plus a 120-day redetermination window.
  • Priority score — billed amount × recovery probability × urgency. Higher scores surface first within each deadline group.
Lines are sorted by appeal deadline ascending, then by priority score descending. Lines with imminent deadlines always appear at the top regardless of dollar value.
4

Expand a line

Click any row to expand it. The expanded view shows the full triage detail for that service line:
  • Rationale — the model’s plain-language explanation of why the line was routed to its lane.
  • Evidence needed — a list of supporting documents or data points required to act on the denial.
  • Routing confidence — the model’s routing confidence displayed as a percentage.
  • Override reasons — shown when a safety invariant fired and escalated the line to human_review.
For appeal and corrected_claim lines, the expanded view also shows the draft artifact body. For human_review lines, it shows the safety brief — a deterministic summary of the override reasons that caused the line to be escalated, built without a model call.
5

Inspect an appeal draft

Expand an appeal line and read the draft body. The draft is a cited appeal letter produced by GPT-5.6 Terra. A few things to look for:
  • Denial codes — the draft body must include the group code, CARC, and RARC (when present) for the service line. The pipeline enforces this; a draft that omits a required code is rejected before it reaches the UI.
  • Citation chips — each factual claim in the draft is backed by a citation chip showing source → value. The source is either parse (a value extracted from the remittance) or legend (a CARC/RARC code description from the reference data). Both are validated against the actual extracted data before the artifact renders.
  • No submission language — the draft does not contain phrases like “we have submitted” or “this appeal has been filed.” The pipeline rejects any draft containing prohibited submission or automation language.
6

Approve eligible drafts

When you are satisfied with an appeal or corrected_claim draft, click Approve on that row. The row is marked as approved and the Download approved drafts button counter increments.Lane-specific approval rules:
  • appeal and corrected_claim — eligible for Approve. Clicking Approve adds the artifact to the export queue.
  • human_review — cannot be approved or exported. The safety brief is for decision support only; the billing team must take the next action manually outside ClaimJumper.
  • patient_bill and write_off — no draft is generated. These rows show a Mark handled disposition control only, which records that the line has been acknowledged in the current session.
7

Download approved drafts

Once one or more lines are approved, click Download approved drafts (N) — where N is the count of approved items. The browser downloads a plain-text file named claimjumper-approved-drafts.txt.The bundle contains one section per approved artifact. Each section includes:
  • The artifact title (e.g., Appeal Draft or Corrected Claim Worklist).
  • The claim ID, patient name, and service-line context.
  • The full draft body.
  • The complete citation list with every source: field_path = value reference.
Downloading the bundle does not submit, file, email, or otherwise send anything to a payer. The 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 in the bundle is used.

​
Sample EOB lane breakdown

samples/eob-001.png contains service lines that cover every routing outcome. The table below summarizes what each lane produces when triaged by ClaimJumper.
LaneArtifact typeNotes
appealCited appeal draft letterBody includes group code, CARC, and RARC. Citations validated against extracted remittance data.
corrected_claimCited corrected-claim worklistNames the specific fields to correct. Citations validated against extracted remittance data.
patient_billDisposition onlyNo letter generated. Billing team verifies patient responsibility per organization policy.
write_offDisposition onlyNo letter generated. Billing team obtains required internal approval per organization policy.
human_reviewDeterministic safety briefLists explicit override reasons. Cannot be approved or exported. Built without a model call.
For a detailed explanation of what each lane means, when invariants fire, and how the routing decision is made, see Denial Lanes.

Build docs developers (and LLMs) love

Get started for freeTalk to us