Recourse

Inspiration

The initial inspiration came from an incredibly frustrating stat: insurers reject about 1 out of 5 claims, while less than 1% file appeals. The reason for this disparity is not the accuracy of the rejections; the problem lies in how intentionally complicated the appeals process is designed to be: convoluted insurance jargon, arcane coding systems, obscure deadlines, and a lopsided balance of legal representation versus stacks of forms. And again, the recurring question remained the same: if the friction that kept individuals from filing those appeals was the only thing stopping them from obtaining funds that were already rightfully theirs, wouldn't removing that friction using AI give them access to something they were entitled to all along?

What it does

Recourse takes a denial letter and turns it into a battle in about three minutes. You upload either a picture or PDF of your denial letter or Explanation of Benefits – Recourse uses AI to read the letter itself, without needing to send it to a separate OCR vendor. Recourse translates the legal language, decodes any CPT/ICD-10 or denial reason code, identifies the type of denial, and calculates your chances of prevailing in an appeal so you know whether or not the appeal is worth pursuing before spending time on it. Then it prepares a formal appeal letter referencing relevant policies for you to copy or download, pulls out the appeal date and actually sends you a calendar reminder document so you can't let it fall through the cracks, and even creates an executive summary if your insurance plan is provided by your employer.

How we built it

The entire pipeline is a one-page application which interacts with Claude directly at each stage: transcription of the uploaded document via computer vision, extraction of structured JSON with the diagnosis (plain language summary, codes interpretation, denial classification, weaknesses, success rate, deadline), and creation of the appeal letter, follow-up email and HR memorandum. For the uploaded PDF, the rendering into pages is done client-side with pdf.js to make sure that both scanned and true PDF documents behave identically. Deadline reminders are implemented as downloadable .ics calendar files created client-side only. Our design is based on a “case file” paradigm – folder-tab navigation from Intake to Diagnosis, Appeal Letter, Deadline and HR Escalation to make it feel more like an advocate sitting across from you rather than an ordinary chatbot.

Challenges we ran into

It proved tricky to get useful structured data out of a single prompt; initial attempts either put the relevant fields in prose or hallucinated billing codes which were not present in the letter, so we needed to strengthen the system prompt to prevent code-making and require a valid JSON format. The calibration of the probability score was problematic in its own right; a raw number without any explanation is useless information, so we required the model to give a justification for every single score with respect to the denial type (high scores go for clerical errors, low scores for plan exclusions). Finally, we needed to decide what not to lie about; while adding an actual "Pay now" button would not be very difficult for the concierge-mail and contingency fee tiers, they lack any sort of payment processor or API for sending email so that is just misinformation.

Accomplishments that we're proud of

The pipeline works perfectly fine from the start all the way through to the very end using real and random input. The system takes in any random EOB letter, scans and scores it, and then writes an actual, relevant appeal letter based on that input. This is particularly notable when speaking about the OCR part of the pipeline, which makes use of the model’s inherent vision capabilities without adding a dedicated OCR system to make the final product more simple and precise. In addition, the HR escalations briefing is the truly unique element of the project since no other players in the market use the employer’s plan as an advantage of the employee.

What we learned

The key takeaway is that trust, not intelligence, is the true value of the product. Those who have been sent a denial letter are frustrated, and some are even afraid of money; the decision in terms of design made in every aspect, whether explicitly differentiating between "live" and "concept," to not allowing for any emotionality in letters generated by the model, were more important than any particular feature. Another takeaway is that one good structured JSON extraction is worth way more than many weak model calls — it provided a reliable source of truth for all subsequent features.

What's next for Recourse

The most leveraged next step would be the creation of the precedent layer that we did not get around to in the current version of the project: a database that links up denial reason codes with won-appeal arguments, insurance department decisions, and ERISA case decisions, ensuring that the "weak point" identified by the model is based on precedents that have actually worked against that particular insurer. In terms of additional steps, I would focus on real delivery (Stripe for the success fee and flat fee tiers, an API like Lob for certified delivery), a feedback loop for tracking wins, and expansion from health insurance to auto insurance, home insurance, and warranties.

Built With

• html