The problem nobody talks about
Picture this: you're already stressed after a hospital stay, and then a letter arrives rejecting your insurance claim. It's full of phrases like "sub-limit applied," "waiting period not completed," or "excluded under policy clause 4.2." This is language written for adjusters, not for someone trying to figure out if they just lost thousands of rupees for good.
Most people don't know if a rejection is worth appealing. Many give up on claims they were fully entitled to, simply because the letter is too confusing to act on, and insurers have little incentive to make it clearer. This isn't a hypothetical problem. It's one I've seen up close. I work in healthcare claims analytics, and the gap between what a rejection letter says and what a patient actually understands is real, common, and costly.
That gap is exactly what I set out to close for Meet the Builders, using Gemini to give patients back the one thing a rejection letter never gives them: clarity.
Why not just paste it into a chatbot?
Here's the honest starting point: you could paste a rejection letter into any LLM and ask "explain this." It would probably give you a reasonable-sounding answer. That's exactly the trap I wanted to avoid. A thin wrapper around a single prompt isn't a build, it's just usage.
The real question I asked myself was: what can I add that raw prompting can't give you? The answer came from my own domain background. I know the common patterns behind claim rejections, the ones that don't always show up clearly in a single generic prompt. So instead of trusting an LLM's raw guess every time, I built a grounded pipeline: a structured dataset of real rejection categories that every answer gets checked against before Gemini explains anything.
How it works
Multimodal input with Gemini. A patient can either upload a photo of their rejection letter or paste the text directly, whichever is easier for them in the moment. Gemini reads either format and extracts the key fields: rejection reason, claim type, amount, and any policy clause cited. This flexibility matters in practice. Some people have a printed letter or a WhatsApp photo of one, others have it as an email they can copy-paste. A tool that only accepts one format quietly excludes the other half of real users. This one doesn't.
Grounding, not guessing. The extracted reason is classified against a structured dataset of ten common Indian health insurance rejection categories I built from domain experience: pre-existing disease exclusions, waiting periods, sub-limits, non-disclosure disputes, and more. Each category carries real guidance on whether it's typically appealable and what the patient should actually do next. Gemini is constrained to only pick from this fixed list, or say "none confidently apply." It can't invent a category, and it can't invent the guidance either. That's what makes it grounded rather than a bare guess.
Native multilingual generation. Once matched, Gemini generates the final explanation directly in the patient's chosen language, English, Hindi, or Telugu, rather than writing it in English and translating afterward. Generating natively in the target language produces far more natural, fluent output than a translate-after-the-fact approach.
Knowing what it doesn't know. This was the most important lesson of the whole build. Early versions of the tool would confidently generate a specific-sounding explanation even from vague input like "it was rejected, out of pocket," inventing a plausible reason that was never actually stated. I fixed this by adding explicit validity and specificity checks before any explanation is generated. If the input is gibberish, empty, or too vague to confidently match a real category, the tool says so honestly instead of fabricating an answer. A tool that admits uncertainty is more trustworthy than one that always sounds confident.
Drafting the appeal itself. Understanding the rejection is only half the problem. The other half is knowing what to actually write back. So the tool goes a step further: with one click, it drafts a formal appeal letter grounded in the same matched category and recommended approach, ready to edit and send. It leaves clear placeholders for details it shouldn't guess, like name, claim number, and policy number, rather than inventing them. This turns the tool from "explains your situation" into "helps you actually act on it."
Grounded vs. raw: a direct comparison
The app includes a side-by-side comparison mode: the same input run through my grounded pipeline versus a bare "explain this rejection" prompt to Gemini with no structure behind it. The difference isn't always a dramatic wrong answer. Raw Gemini is often quite good on well-known scenarios. The real difference is consistency and accountability. My version always draws from the same defined set of categories and guidance, every time, and clearly flags when it isn't confident. Raw prompting has no such guarantee.
Putting a number on it
Claims like "it's grounded" and "it knows its limits" are only useful if they hold up under testing. I built a 15-case evaluation set covering all 10 rejection categories, plus deliberately tricky edge cases: vague input ("it was rejected, out of pocket"), gibberish, empty input, and an ambiguous case that could plausibly fit more than one category.
The pipeline scored 100% (15/15). It correctly matched every clear case to its right category, and correctly flagged every vague, invalid, or ambiguous case instead of guessing. That result only came after an important fix. My first version used simple keyword overlap to match categories, which got 86.7% (13/15) and missed documentation-related language that didn't share exact words with the category descriptions. Switching to a Gemini-assisted classification step, constrained to only pick from my fixed category list, closed that gap completely while keeping the grounding intact.
Why this matters beyond one tool
Insurance claim confusion isn't a niche problem. It affects millions of policyholders across India every year, and the pattern repeats across APAC wherever insurance paperwork outpaces plain language. A tool like this doesn't replace an insurer's grievance process or a lawyer's advice, but it does something insurers themselves rarely bother to: it meets patients exactly where they are, in the language they're comfortable in, with a straight answer instead of jargon, and now, a starting point for what to say back.
That's the real promise of Gen AI applied to a lived problem. Not a flashier chatbot, but genuinely better access to information and agency for people who are otherwise stuck.
Try it
The tool is live and publicly usable: https://claim-rejection-translator-tool.streamlit.app/
Code: https://github.com/Anushka-ece/claim-rejection-translator
Where this goes next
This weekend build is a starting point, not a finished product, and there's a clear path to make it genuinely more useful:
- Expand the grounding dataset. Ten categories cover the common cases, but real rejection letters carry more nuance. The next version would grow this dataset with more categories and finer-grained sub-cases, ideally validated against real, anonymized claim patterns rather than general domain knowledge alone.
- More regional languages. English, Hindi, and Telugu are a start, but India alone has many more languages where this kind of clarity is needed. Tamil, Bengali, and Marathi are natural next additions.
- Track real outcomes. Right now the tool tells a patient whether an appeal is likely worth pursuing. A meaningful next step would be closing the loop: letting users report back whether their appeal succeeded, and using that anonymized, aggregated feedback to make future guidance more accurate over time.
- Beyond health insurance. The same grounded-explanation approach applies to other jargon-heavy rejection letters people struggle with, like loan application denials, visa rejections, and insurance claims outside health such as motor or travel. The architecture doesn't change, only the dataset does.
- A more robust appeal letter flow. Right now the tool drafts one version of the letter. A stronger version would let the patient attach specific documents they have and tailor the letter's argument accordingly, rather than using a single generic template per category.
None of this needs to happen before this counts as a real, working tool. It already is one. But it's worth being upfront about where the edges are, because that honesty is part of what makes a grounded system trustworthy in the first place.
Closing thought
The most useful thing I learned building this wasn't about prompting Gemini. It was about being honest with myself about what actually makes something a "build" versus a wrapper. Domain grounding, multimodal input, native multilingual output, a system that knows its own limits, and going one step further to help patients act: these turned out to matter far more than clever prompt engineering alone.
