ClaimRight

Reads your insurance denial, catches the contradiction, writes your appeal, and proves every fact.

Comment

Inspiration

Health-insurance denials are difficult to understand because the important information is often spread across several documents: a denial letter, Explanation of Benefits, bill, referral, and prior-authorization record. A patient may already have evidence that challenges the denial, but finding and connecting that evidence can take hours.

In 2023, HealthCare.gov insurers denied nearly 1 in 5 in-network claims (~19%) — roughly 73 million denied claims. Consumers appealed less than 1% of them (KFF, 2023).

We built ClaimRight to automate that administrative work. Our goal was not to decide whether an insurer is legally wrong or guarantee that an appeal will succeed. Instead, we wanted to help users organize their documents, identify possible inconsistencies, and prepare a reviewable appeal package.

What it does

ClaimRight turns a collection of denial-related documents into one structured case. It can:

  • Extract important facts such as the patient, provider, service date, denied amount, and denial reason
  • Normalize differently formatted names, dates, services, and monetary values
  • Compare information across documents
  • Detect a potential contradiction involving prior authorization
  • Build an evidence-linked timeline
  • Identify documents that may still be useful
  • Generate a reviewable appeal letter and downloadable PDF packet

The demo uses a fully fictional patient, Maya Rodriguez, and synthetic documents created only for testing and presentation. No real patient or medical information is used.

How we built it

We built ClaimRight with Next.js, TypeScript, React, and Tailwind CSS.

The document-analysis pipeline is deterministic rather than dependent on a language model for decision-making. Each document is processed separately, and pattern-matching logic extracts structured facts such as claim numbers, dates, providers, service descriptions, and authorization details.

We then normalize those values so that differently formatted information can still be compared. For example, variations such as “Knee MRI” and “MRI, Left Knee” can be treated as referring to the same service.

The rule engine checks whether:

  • The denial states that authorization was missing
  • An approved authorization exists
  • The patient, provider, and service match
  • The service date falls within the authorization period

A potential discrepancy is surfaced when the denial cites missing authorization and an approved authorization record exists. The engine then compares the patient, provider, service, and authorization dates to determine the finding’s severity and confidence.

Each fact also stores its source document, page, confidence state, and verification status so the user can trace conclusions back to the original evidence.

Low-confidence information remains marked as unclear and is excluded from the generated appeal unless verified. For example, the referral’s clinical reason is extracted with lower confidence and is not automatically included in the letter.

The interface includes the upload workflow, processing sequence, case dashboard, source citations, timeline, evidence checklist, editable appeal builder, and PDF export.

We used AI as a learning and development aid for project scaffolding, debugging, understanding architecture, and improving specific code. The core workflow, interface, normalization logic, contradiction rules, and document-processing behavior were manually implemented and tested by our team.

Challenges we faced

The largest challenge was keeping the scope realistic for a two-day hackathon. Insurance appeals vary significantly between plans and jurisdictions, so we focused on one specific scenario: a post-service MRI denial involving an authorization conflict.

Another challenge was comparing information that appears in inconsistent formats across documents. Dates, provider names, service descriptions, and currency values all required normalization before they could be compared reliably.

We also had to balance a polished demonstration with safety and accuracy. ClaimRight avoids declaring that an insurer violated the law, does not promise that an appeal will succeed, and does not submit anything automatically. It uses language such as “potential discrepancy” and requires the user to review the generated output.

For demo reliability, the current hackathon build includes a fictional Maya-specific fallback that supplies predetermined sample facts when a document does not match the supported extraction patterns. This fallback is intended only for the synthetic demonstration workflow and would need to be explicitly disabled or separated from normal uploads before the application could process real documents safely.

What we learned

Through this project, we gained practical experience with:

  • Structuring a multi-page Next.js application
  • Designing shared TypeScript data models
  • Extracting and normalizing information from documents
  • Building deterministic rule-based systems
  • Preserving citations and confidence states
  • Generating PDFs from structured application data
  • Designing human-in-the-loop automation for a high-stakes use case

The most important lesson was that automation does not always require a probabilistic model. For decisions involving deadlines, money, and medical paperwork, deterministic and auditable logic can provide a safer foundation.

What’s next

Future versions could support additional denial types, stronger document classification, improved PDF parsing, encrypted storage, multiple cases, and more detailed plan-specific guidance.

Before real-world use, ClaimRight would also require extensive security, privacy, legal, and accuracy review.

Built With

Share this project:

Updates

Submission history