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.

ClaimJumper routes denials based on the combination of Group Code + CARC + RARC from each service line. The triage model reads these three fields together, never a CARC in isolation — a CARC 50 under group code CO means something different than the same CARC under PR, and the presence or absence of a paired RARC further shapes the routing decision. The code legend printed on the remittance is extracted verbatim during ingest and used as citation grounding for all draft artifacts; the system never substitutes a static external reference for what is actually printed on the document.

​
Group codes

X12 group codes classify who is financially responsible for an adjustment. ClaimJumper’s triage prompt and invariant rules treat each group code as a hard routing signal before the CARC is examined.
​
CO — Contractual Obligation
group code
Provider-absorbed adjustment arising from a contracted or legislated fee arrangement. The provider may not bill the patient for a CO adjustment. This constraint is enforced by a code-level invariant: if the model returns patient_bill for any CO line, the invariant overrides the lane and records the change in DenialTriage.overrides. CO lines route to write_off (contract ceiling, e.g. CARC 45) or appeal/corrected_claim (fixable denial, e.g. CARC 29 or CARC 16) depending on the CARC.
​
PR — Patient Responsibility
group code
Patient cost-share: coinsurance, copay, or deductible. Routes to patient_bill unless a paired RARC contradicts the patient assignment. The triage prompt explicitly instructs the model not to route PR lines into the denial workflow absent a contradicting RARC.
​
OA — Other Adjustment
group code
Adjustments that do not fit the CO or PR categories — plan-level coordination of benefits settlements, sequestration reductions, and similar payer-specific adjustments. Evaluated case-by-case by the triage model.
​
PI — Payer Initiated Reduction
group code
A reduction initiated by the payer without a contractual basis that the provider agreed to. Commonly seen with duplicate claim edits or bundling adjustments applied by the payer.
​
CR — Correction and Reversal
group code
Applied when a payer corrects or reverses a prior payment. Typically paired with a CARC identifying the original overpayment reason.

​
CARC codes covered by invariants

Three specific CARC and group-code combinations trigger code-enforced safety overrides in enforceInvariants(). These overrides are not guidance in the triage prompt — they are hard rules applied in code after the model responds, recorded verbatim in DenialTriage.overrides.
Invariants fire regardless of the model’s confidence score. A high-confidence model output that violates an invariant is still overridden.
Rule: If group_code === "CO" and the model returned lane === "patient_bill", the lane is forcibly changed.Why it exists: The CO group code means the provider absorbed the adjustment by contract. Billing the patient for a CO adjustment violates the payer contract and, in many jurisdictions, patient protections. This is a correctness invariant, not a conservative default — there is no scenario where a CO line should ever reach a patient statement.Effect in overrides: A message is appended, e.g. "CO invariant: lane changed from patient_bill to human_review".
Rule: If carc === "197" (precertification/authorization absent) and the model returned lane === "write_off", the lane is changed to human_review. This check applies regardless of group code.Why it exists: CARC 197 is an authorization-failure denial. The day-one model validation showed the model returning write_off at confidence = 0.96 for a CO-197 line — technically consistent with the prompt contract, but silently abandoning a potentially recoverable denial. Whether the provider wants to write off an auth-failure denial or escalate for a retroactive authorization attempt is a product decision that should not happen automatically. The invariant ensures a human makes that call.Effect in overrides: A message is appended, e.g. "CARC 197 invariant: lane changed from write_off to human_review".
Rule: If confidence < 0.6 on any line, lane is set to human_review regardless of the model’s original lane.Why it exists: The triage prompt instructs the model directly: “confidence below 0.6 → lane = human_review.” The invariant layer enforces this as a code guarantee so that the lane cannot be appeal or corrected_claim when the model itself signals low certainty. The original lane is preserved in overrides so the reviewer understands what the model was leaning toward.Effect in overrides: A message is appended, e.g. "Low confidence (0.47): lane changed from appeal to human_review".

​
Codes referenced in the draft prompt

The draft step applies lane-specific rules when certain CARC and RARC combinations are present. These rules govern what the draft may and may not say — they are defined in the triage and draft prompts, not in the invariant layer.
Combination: Any group code + CARC 29 (“The time limit for filing has expired.”) → appeal lane.Draft rules:
  • The appeal must include the original service_date, the claim_received_date, and any clearinghouse acknowledgment date present in the service line’s notes field.
  • The draft cites these dates from parsed fields — never from model knowledge.
  • The goal is to demonstrate that the original submission occurred within the payer’s filing window.
Evidence typically needed: Clearinghouse acknowledgment or confirmation number showing the original transmission date; remittance showing CO-29.
Combination: CO + CARC 50 (“not deemed a medical necessity”) + RARC N115 (“based on a Local Coverage Determination”) → appeal lane.Draft rules:
  • The appeal is a procedural request only. The draft asks the payer to identify the specific LCD and the criterion under which the service was denied.
  • The draft may quote the CARC and RARC definitions verbatim from the code_legend.
  • The draft must not assert that medical necessity was met or that clinical criteria were satisfied. The model has no access to the medical record and any such assertion would be fabrication.
Evidence typically needed: Clinical documentation supporting the medical necessity of the service; the specific LCD and criterion identified by the payer in their response.
Combination: CO + CARC 16 (“lacks information or has submission/billing error(s)”) + RARC M51 (“Missing, incomplete, or invalid procedure code(s)”) → corrected_claim lane.Draft rules:
  • The output is a corrected-claim worklist, not an appeal. It names the exact fields to correct (in this case, the procedure code) and directs the biller to resubmit.
  • No appeal language is used — “appeal,” “dispute,” and “challenge” are not appropriate here because the denial is a billing error with a defined fix.
  • RARC M51 is the authoritative signal for which field is missing; the definition from code_legend is cited directly.
Evidence typically needed: Corrected claim with the valid procedure code; supporting charge detail.

​
Code legend extraction

ingest() extracts every entry from the “Adjustment and Remark Code Legend” footer printed on the remittance image. The extraction is performed by the vision model using structured output against the IngestResponseSchema, which enforces code_legend as a non-empty array of CodeLegendEntry objects. Definitions are stored verbatim from the printed page — the model is explicitly instructed never to infer or substitute a definition from its own knowledge. This matters because:
  1. Payer-specific wording. Payers sometimes use slightly different wording than the national X12 standard definition. The citation grounding in draft artifacts must reflect what the remittance actually says.
  2. Auditability. Every claim in a draft artifact that references a CARC or RARC definition can be traced to a specific CodeLegendEntry with source: "legend" — not to a static lookup table that may have been updated since the document was issued.
  3. Schema coverage. Only codes that appear in the code_legend array are available as "legend" citations. If a code appears on a service line but not in the legend, the draft step cannot produce a legend citation for it and must flag the gap.
The code legend on the remittance is the canonical source. ClaimJumper never uses a static external code reference as a substitute for what is printed on the document.

​
Day-one model validation

Before implementation began, a pre-build validation run tested whether the model makes correct denial-routing decisions from the raw adjustment-line fields alone, with no reference data and no lookup tool. The run was conducted against six representative cases covering the full range of codes used in the demo fixture (eob-001). The model read Group Code + CARC + RARC together in every case rather than pattern-matching on the CARC alone. Recovery probabilities were well-calibrated: 0.90 on a RARC-specific correction, 0.35 on a borderline medical necessity appeal, and 0.03 on a dead auth denial. CO-197 open question. The model returned write_off at confidence 0.96 for the missing-authorization case (CARC 197) — technically correct under the prompt contract. However, silently writing off an auth-failure denial without a human decision is a product risk. The CARC 197 invariant was added after this run to ensure that write_off on a CO-197 line is always escalated to human_review, making revenue abandonment a deliberate human choice rather than an automatic outcome.

Build docs developers (and LLMs) love

Get started for freeTalk to us