Using LLMs to Combat Health Insurance Claim Denials

fight_health_insurance · Healthcare · 2026 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Health insurance appeal generation

Fight Health Insurance needed to help individuals generate effective appeals for denied health insurance claims without requiring legal, medical, or insurance-process expertise.

Constraints:

The project targets high-stakes claim denials affecting individuals who may lack time, money, or procedural knowledge.
Training data comes from independent medical review appeals with inherent third-level-appeal bias.
The system must run as both an open-source Python package and a free hosted service.
Training is constrained by rented GPU economics and network bottlenecks.
Inference must fit on affordable consumer-grade GPUs and include human validation of extracted facts.

Architecture

Fight Health Insurance trains fine-tuned language models on independent medical review appeal data to generate denial-appeal letters. The system extracts structured facts from denial letters, asks users to confirm the extracted information, collects medical-history context, and generates an appeal. Training runs on rented GPUs with checkpointing and persistent storage, while inference uses owned consumer GPUs to keep the hosted free service sustainable.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  independent-medical-review-dataset["Independent medical review dataset"] --> training-data-processor["Training data processor"]
  training-data-processor --> gpu-fine-tuning-jobs["GPU fine-tuning jobs"]
  gpu-fine-tuning-jobs --> checkpoint-storage["Checkpoint storage"]
  gpu-fine-tuning-jobs --> fine-tuned-appeal-model["Fine-tuned appeal model"]
  hosted-service-and-python-package["Hosted service and Python package"] --> denial-letter-extractor["Denial letter extractor"]
  denial-letter-extractor --> user-confirmation-step["User confirmation step"]
  user-confirmation-step --> fine-tuned-appeal-model
  hosted-service-and-python-package --> fine-tuned-appeal-model

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Independent medical review dataset`	Provides historical appeal records for model fine-tuning.	`Training data processor`
`Training data processor`	Transforms public appeal records into fine-tuning examples.	`Independent medical review dataset`, `GPU fine-tuning jobs`
`GPU fine-tuning jobs`	Train appeal-generation models on rented GPU infrastructure.	`Training data processor`, `Checkpoint storage`, `Fine-tuned appeal model`
`Checkpoint storage`	Persists model state so interrupted training can resume.	`GPU fine-tuning jobs`
`Hosted service and Python package`	Expose the appeal-generation workflow to end users and self-hosters.	`Denial letter extractor`, `Fine-tuned appeal model`
`Denial letter extractor`	Extracts denied procedure, insurer rationale, and relevant facts from denial letters.	`Hosted service and Python package`, `User confirmation step`
`User confirmation step`	Asks users to verify extracted information and add medical history.	`Denial letter extractor`, `Fine-tuned appeal model`
`Fine-tuned appeal model`	Generates appeal letters from confirmed denial facts and user medical history.	`GPU fine-tuning jobs`, `Hosted service and Python package`, `User confirmation step`

Data flow

Historical independent medical review records are transformed into fine-tuning data and used to train appeal-generation models with checkpointed GPU jobs. At inference time, a user uploads or enters a denial letter, the system extracts the denied treatment and insurer rationale, asks the user to confirm the facts and provide medical history, then generates an appeal letter through the hosted service or Python package.

3 supporting quotes

“The training dataset contains tens of thousands of records, which the creator processes and transforms to produce suitable training data for fine-tuning operations.”summary, stated

“The production system implements a multi-stage workflow. First, it processes the denial letter to extract structured information about what was denied and why.”summary, stated

“prompts the user to confirm that the extracted information is correct, providing a human-in-the-loop validation step that improves reliability.”summary, stated

Why this architecture

The project separates expensive training from cheaper inference because its free/open-source mission cannot absorb unlimited cloud inference cost. It also inserts human confirmation before generation because denied-claim appeals are high stakes and extraction errors could weaken or misdirect an appeal.

“The creator made a deliberate architectural decision to rent GPUs by the hour for training operations while using owned GPUs for inference.”summary, stated

“The system's approach of extracting structured information from denial letters and then asking users to confirm accuracy represents an important pattern for production LLM systems in high-stakes domains.”summary, stated

Models used: Fine-tuned large language models · Axolotl fine-tuning workflow

Scale

The training data contains tens of thousands of independent medical review records.
“The training dataset contains tens of thousands of records”summary, stated
The creator had approximately a decade of distributed data-processing experience.
“an Apache Spark developer with a decade of experience in distributed data processing.”summary, stated
The project runs as both a Python package and a hosted service.
“The project is available both as an open-source Python package and as a hosted service at fighthealthinsurance.com.”summary, stated

Alternatives considered (roads not taken)

Use cloud GPUs for both training and inference

Rejected because: Ongoing per-request costs would make a free service harder to sustain.

“training happens on powerful rented resources while inference uses more cost-effective dedicated hardware.”summary, stated

“the ongoing per-request costs can become prohibitive for services that need to remain accessible and free to end users.”summary, stated

Ask users for open-ended complete medical history

Rejected because: Most people cannot recall complete medical histories accurately.

“An identified limitation of the current approach is that it relies on users to provide their complete medical history, which most people cannot recall accurately.”summary, stated

Assume non-preemptible GPU jobs will not fail

Rejected because: Even nominally non-preemptible jobs were interrupted, so checkpointing and persistent storage were necessary.

“Even when renting non-preemptible GPU instances, the creator observed that jobs can still be interrupted”summary, stated

Patterns

`fine-tuning-adaptation` (model customization)

The project fine-tunes models on historical independent medical review appeal records to learn appeal language and structure.

“using fine-tuned language models trained on successful historical appeals from independent medical review board data.”summary, stated

“teaching it the language, structure, and argumentation patterns that have proven successful.”summary, stated

`human-in-the-loop-gate` (safety)

Users confirm extracted denial facts and supply medical history before appeal generation.

“prompts the user to confirm that the extracted information is correct, providing a human-in-the-loop validation step that improves reliability.”summary, stated

`durable-execution` (training infrastructure)

Checkpointing with persistent storage protects long-running fine-tuning jobs from GPU preemption and hardware failures.

“Checkpoints capture the model state periodically during training, allowing the process to resume from the last saved state rather than starting over completely.”summary, stated

“provisioning persistent storage attached to rented GPU instances to ensure checkpoints survive preemption events.”summary, stated

`cost-aware-routing` (infrastructure)

Training uses rented GPUs while inference runs on owned consumer GPUs to control ongoing service cost.

“The creator made a deliberate architectural decision to rent GPUs by the hour for training operations while using owned GPUs for inference. This approach balances the high computational demands of training against the need to control costs for ongoing inference operations.”summary, stated

“The creator's approach of using owned hardware for inference reflects a careful cost-benefit analysis. While cloud-based inference offers scalability advantages, the ongoing per-request costs can become prohibitive for services that need to remain accessible and free to end users.”summary, stated

Tradeoffs

Training/inference hardware split

Chose Rent GPUs for training and use owned GPUs for inference over Use the same cloud GPU infrastructure for all workloads.

Rationale: The split balances heavy training requirements against ongoing free-service inference costs.

“This approach balances the high computational demands of training against the need to control costs for ongoing inference operations.”summary, stated

Dual open-source and hosted distribution

Chose Offer both a Python package and a free hosted service over Require users to self-host or use only the hosted web service.

Rationale: Self-hosting supports developers while the hosted service removes technical barriers for denied-claim users.

“This dual distribution model reflects a common pattern in open-source LLMOps projects where both self-hosted and managed service options coexist.”summary, stated

Human validation before appeal generation

Chose Ask users to confirm extracted denial facts over Trust the extractor output automatically.

Rationale: The domain is high stakes and a wrong denial fact could weaken an appeal.

“Rather than assuming the model's extraction is perfect, the system incorporates human validation at a critical juncture.”summary, stated

Gotchas (what bit them)

Checkpoint storage can grow without bounds during fine-tuning.

Root cause: Training checkpoints are large and accumulate over time.

Resolution: Provision persistent storage and plan checkpoint retention/cleanup.

“Checkpoints are not small, and they accumulate over time as training progresses. The creator emphasizes the importance of provisioning persistent storage attached to rented GPU instances to ensure checkpoints survive preemption events.”summary, stated

“Production LLM training pipelines need strategies for checkpoint retention and cleanup to avoid unbounded storage growth”summary, stated

Rented GPU network bottlenecks can dominate training workflows.

Root cause: Data sources and rented GPUs may sit behind slow, geographically separated links.

Resolution: Tune data movement and configurations around actual bandwidth constraints.

“The network bottleneck between rented GPU infrastructure and data sources presents a classic distributed computing challenge.”summary, stated

“This necessitates different configuration strategies compared to typical enterprise deployments, with much more conservative data movement patterns.”summary, stated

Open-ended medical-history collection is unreliable.

Root cause: Users may not remember complete medical histories or know what context is relevant.

Resolution: The project plans to move toward targeted interview-style questioning.

“The creator plans to evolve this to an interview-style interaction where the system asks targeted questions about medical history”summary, stated

Free hosted LLM services face sustainability pressure.

Root cause: Training and inference have non-zero GPU and compute costs without a clear revenue model.

Resolution: The project currently uses careful resource management but has an explicitly uncertain business model.

“The hosted service deployment presents ongoing cost challenges since training and inference both have real dollar costs in terms of GPU time and compute resources.”summary, stated

“The business model is explicitly uncertain, following what the creator describes as the underpants gnomes approach: step one is building and deploying the service, step two is uncertain, and step three is hopefully profit.”summary, stated

Evaluation

The source describes model experimentation with Axolotl and domain-specific evaluation, but does not provide detailed public success metrics for appeal outcomes.

Metrics: Tens of thousands of training records · Model selection across base models · No disclosed appeal success-rate metric · No disclosed hosted-service cost metric

“Axolotl made it much easier to experiment with different base models to evaluate their performance on the specific task of generating insurance appeals.”summary, stated

“The ability to systematically evaluate different models on the specific task domain allows for data-driven decisions about which base model to use.”summary, stated

Outcomes

The project provides an open-source package and hosted service for appeal generation.
It automates denial-letter fact extraction and appeal drafting.
It uses fine-tuned models trained on independent medical review appeal data.
Its sustainability and medical-history collection workflows remain evolving.

The project trains on tens of thousands of appeal records and is deployed as both fighthealthinsurance.com and an open-source Python package.

“The current production deployment at fighthealthinsurance.com represents a functional but evolving system.”summary, stated

“The hosted service removes technical barriers for end users who simply need help with a denied claim rather than wanting to manage their own deployment.”summary, stated