ClaimReady: a local-AI claims workbench for hospital front desks

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

ClaimReady is a claims workbench for hospital front-desk and billing staff. It puts three jobs in one place: checking a claim before it goes out, tracking the insurer's follow-up questions, and reconciling what the insurer actually paid.

Here is how it works for Rachael, a front-desk staff member, and Ritu, a patient she is helping:

1. Claim Check. Rachael uploads Ritu's claim form, hospital bill and discharge summary. ClaimReady flags anything that may need attention, such as a missing document or an amount that differs between files, and shows the exact text from each file. Rachael checks the findings, gets anything missing, and sends the claim to the insurer herself.
2. Query Desk. The insurer asks for the discharge summary and the admission and discharge dates. Rachael records the request and its due date. ClaimReady finds the matching lines in the uploaded documents, shows which file each came from, notes that the summary is missing, and prepares a draft reply. Rachael edits it, sends it herself, and updates the status (Open, Waiting for documents, Ready to review, Responded).
3. Payment Tracking. The insurer pays ₹40,000 on a ₹45,000 claim. Rachael records the claimed, approved and received amounts. ClaimReady shows the ₹5,000 difference and keeps it visible until she records what explains it.

Who would pay: small and mid-size hospitals and clinics whose front-desk or billing staff chase claims across folders, spreadsheets and messages. The cost of that is missed documents, forgotten insurer deadlines and shortfalls nobody explains. I have not tested pricing with a real customer yet, so I'm not claiming a price or a savings figure.

What it does not do: it does not decide coverage, approve or reject claims, send claims or replies, or connect to insurers. Staff stay in charge of every decision.

Demo

Code

shristi005 / ClaimReady

ClaimReady

A claims workbench for hospital front-desk and billing teams. ClaimReady brings claim checks, insurer follow-up, and payment reconciliation into one place.

ClaimReady is a hackathon prototype that supports staff review. It does not decide coverage, approve or reject claims, or send claims or replies to insurers.

The problem

Staff helping with health insurance claims often need to coordinate forms, bills, insurer messages, deadlines, and payment records. When that work is scattered across folders, spreadsheets, and messages, it is easy to miss a missing document, forget a response deadline, or overlook a payment difference.

ClaimReady gives staff one workflow to review a claim, manage insurer questions, and account for settlement amounts.

Who it is for

The prototype is designed for hospital front-desk and billing staff who help patients prepare and follow up on insurance claims.

Features

Claim Check — review a claim before submission

Staff upload documents such as a…

View on GitHub

Fictional sample claims are in backend/eval/testClaims/ and demo-assets/, so you can try it without any real data.

How I Built It

• Frontend: React + Vite.
• Backend: Node + Express, with a local SQLite database and built-in accounts, hospital workspaces and roles. No cloud database or external login service is needed.
• Open-source AI: an open-weight model, Qwen2.5 3B, running locally through Ollama. An optional Groq provider exists, but it is off by default and sends text to a hosted service.
• Document reading: text is read from PDFs and OCR handles images. Regular matching rules run first.

What the model does, exactly:

Feature	Where the model is used
Claim Check	Only when the rules cannot find a required field or the bill's line items. The model's answer must include a quote that appears in the document, otherwise it is rejected and the item goes to "Check manually".
Query Desk	Not used. Evidence search and draft replies come from matching logic and a template.
Payment Tracking	Reads an uploaded remittance advice (PDF, PNG or JPG) and suggests the settlement amounts and any stated deductions, with the supporting text. Nothing is saved until staff review it and save.

All comparisons, such as amounts, dates, IDs and the settlement balance, are plain code. The model reads messy text. It does not judge anything.

Results on my own test set (9 fictional claim packets with planted errors, qwen2.5:3b on a Windows laptop with a GTX 1650 and 4 GB of GPU memory, run with npm run eval):

Planted issues caught	False alerts	Items sent to manual check	Average time per packet
9 of 9	0	4	2.3 s

The 4 manual checks all came from the two packets written in unusual wording. The model could not confirm a field, so the app asked a person instead of guessing. These packets are small, text-based and made by me, so this is not a real-world accuracy benchmark. Real hospital paperwork will be messier.

Why Does Open Innovation Matter?

• Documents stay on the machine. Claim papers contain sensitive health and financial details. With Ollama, the model runs on the computer hosting the app, so the AI step needs no third-party model API.
• No per-document cost. A small clinic can run it without paying for every claim it checks. A 3B model runs fully on a 4 GB laptop GPU, as ollama ps showed on my machine.
• Control over behaviour. Because I run the model myself, I could force structured JSON output, require a quote for every extracted value, reject answers that are not in the document, and swap the model by changing one setting.
• Where it was weaker. The small model missed fields on unusual wording, and early on it reformatted dates in ways my first checker rejected. I fixed the checker, and the design now sends anything uncertain to a human. I did not benchmark closed APIs, so I'm not claiming open models are more accurate. My claim is about privacy, cost and control.

Honest limits: this is a hackathon prototype, not a certified billing or compliance system. The local database is not encrypted by the app. OCR and extraction can miss or misread things, so staff must verify every suggestion. I used only fictional data.

AI Assistance

Built with assistance from Claude and Codex.