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.

For appeal and corrected_claim lines, GPT-5.6 Terra produces a draft artifact — a structured work packet that the billing team can review, approve, and download. Every factual claim in the artifact body must be supported by a citation that points to either the parsed remittance data (parse source) or the code legend (legend source). Before the artifact can be displayed or exported, validateCitations() resolves each citation against the actual pipeline input and discards the draft if any citation is invalid. This grounding step ensures that the billing team is reading claims traceable to the real remittance data, not model confabulations.

​
Artifact types

ClaimJumper produces three artifact types, one per actionable lane:

Appeal Draft

Produced for the appeal lane. A letter body requesting payer reconsideration that includes the denial codes and a procedural argument grounded in the remittance data. Approvable and exportable.

Corrected Claim Worklist

Produced for the corrected_claim lane. A list of the exact fields to correct for resubmission. Uses no appeal language. Approvable and exportable.

Human Review Required

Produced for the human_review lane. A deterministic brief assembled from pipeline data — not model-generated. Lists override reasons. Not approvable, not exportable.
patient_bill and write_off lanes do not receive any artifact. Calling draft() for those lanes throws an error by design.

​
Citation structure

Every citation in a draft artifact has three fields: source, field_path, and value. 
type DraftCitation = {
  source: "parse" | "legend";
  field_path: string;
  value: string; // canonical string of the source field
};
The two citation sources correspond to the two places facts can be grounded: parse — parsed remittance data field_path is a dotted path from the DraftInput root. The model can cite any field that exists in the DraftInput object, which contains the full parsed claim, the specific service line, and the triage decision. Examples:
  • claim.claim.claim_id → the claim identifier
  • claim.remittance.payer → the payer name
  • service_line.group_code → the adjustment group code
  • service_line.billed_amount → the billed dollar amount (value stored as String(number))
legend — code legend field_path is a code-system path in the form CODE_SYSTEM:CODE.field, resolved against the code_legend array in the parsed remittance. Examples:
  • CARC:50.definition → the definition of CARC 50 from the remittance’s code legend
  • RARC:N115.definition → the definition of RARC N115
The value field must exactly equal the source field’s canonical string representation: field text unchanged for strings, and String(number) for numeric fields (e.g. "1250" for a billed_amount of 1250).

​
Citation validation

Before any artifact can be displayed in the UI or included in an export, validateCitations() walks every citation in the model’s output and resolves it against the actual DraftInput that was passed to the model: 
export function validateCitations(input: DraftInput, citations: readonly DraftCitation[]): void {
  for (const citation of citations) {
    const resolved = citation.source === "parse"
      ? resolveParseCitation(input, citation.field_path)
      : resolveLegendCitation(input, citation.field_path);
    if (resolved === undefined || String(resolved) !== citation.value) {
      throw new Error(`Invalid draft citation: ${citation.source}:${citation.field_path}`);
    }
  }
}
If any citation resolves to undefined (the path does not exist in the input) or the resolved value does not match citation.value, the function throws. The draft is discarded and the line remains visible in the queue but without an artifact. The billing team sees the triage result and can still work the line manually, but no unverified draft is surfaced.

​
Draft content rules

After citations are validated, validateArtifact() applies two additional content checks to the draft body: Prohibited phrases check Drafts cannot contain language that implies the work has already been performed or that the process is automated. The following regex matches are prohibited:
  • "we have submitted" / "we have filed" / "we have appealed"
  • "this appeal has been submitted" / "this appeal has been filed"
  • "approved"
These phrases would misrepresent the draft as a completed action rather than a human-reviewed work product. Denial codes must appear For appeal and corrected_claim artifacts, the exact group_code, carc, and rarc (when present) from the service line must all appear somewhere in the body. This ensures the billing team can immediately identify which denial the draft addresses and that the draft is not a generic template. CARC 50 special rule For appeal drafts on medical necessity denials (carc === "50"), the body cannot assert that medical necessity was established, that documentation meets criteria, or that any criterion was met. Specifically, these patterns are prohibited:
  • “medical necessity is/was/has been established/demonstrated/proven”
  • “record/documentation meets/satisfies/establishes/demonstrates the (LCD) criteria”
  • “criterion/criteria is/are/was/were met”
  • “meets a/the (LCD) criterion”
The correct approach — following the draft prompt — is to make a procedural request: ask the payer to identify the specific LCD and criterion, and request reconsideration upon review of provider documentation. The clinical determination belongs to the billing team and their clinical staff, not to the AI-generated draft.

​
Approval and export

Only appeal and corrected_claim artifacts with valid citations are eligible for approval. Human-review briefs are never approvable.
1

Review the draft

The billing team reads the artifact body and its citations in the queue UI, verifying that the factual claims match the source remittance.
2

Approve the draft

One-click approval marks the line as ready for the next controlled step. Approval state exists only in the current browser session — it is not persisted.
3

Download approved drafts

formatApprovedDrafts() filters to only approved appeal and corrected_claim lines and produces a plain-text bundle. Each entry contains a header, the claim and line identifiers, the draft body, and the full citation list:
CLAIMJUMPER — APPROVED DRAFTS
DRAFTS FOR HUMAN REVIEW — This download does not submit, file, or send anything to a payer.
Verify payer-specific requirements, required forms, supporting records, and signer information before use.

=== Appeal Draft ===
Claim: <claim_id>; Patient: <patient_name>; Line: <line_number>
Service date: <service_date>; Procedure: <procedure_code>

<draft body>

Citations:
- parse: claim.claim.claim_id = <value>
- legend: CARC:50.definition = <value>
The download does not submit, file, email, or otherwise send anything to a payer. It is a human-review work packet that the billing team carries into their organization’s approved payer workflow.
Drafts are for human review only — they are not universal filing-ready forms. The billing team must verify payer-specific requirements, required forms, supporting records, signer information, deadlines, and submission instructions before using any artifact from ClaimJumper.

Build docs developers (and LLMs) love

Get started for freeTalk to us