ClaimBridge

The demo case flags a possible processing mismatch on a $4,200 claim and shows what the available records support.
ClaimBridge connects denial notices, plan terms, and medical records to show the evidence behind an insurance denial.
ClaimBridge identifies missing information and suggests concrete next steps, including requesting claim records
Each step in the finding links back to its source, so users can check the actual document before acting on it.

Inspiration

The idea for ClaimBridge came from how confusing health insurance claims can be. If a claim gets denied, you might have your insurance plan, a denial letter, medical documents, and other information, but it is still really hard to figure out what actually matters. A lot of the burden ends up on the person to read through everything and connect it themselves.

We wanted to see if we could make that process easier by taking all of those documents and connecting the relevant information in one place.

What it does

ClaimBridge lets a user upload documents related to an insurance claim and builds a structured view of what is going on.

It pulls out things like the reason for a denial, requirements from the insurance plan, and evidence from the other documents. It then connects those pieces and shows where there might be a conflict or where evidence supports the user's case.

One thing we cared about was not just giving the user an AI-generated answer. If ClaimBridge flags something, we want the user to be able to see why it was flagged and what information it came from.

How we built it

The main idea behind ClaimBridge is an evidence graph.

After documents are processed, we turn the useful information into structured facts and relationships. The system can then reason over those relationships to find things that are relevant to the claim.

For example, a denial might say that a procedure was not medically necessary. ClaimBridge can connect that denial reason to the actual requirement in the insurance plan and then look for evidence in the uploaded documents that relates to that requirement. Instead of only showing a final answer, we can show that chain to the user.

We built the frontend as a web app and the backend in Python. We also added a demo mode using preprocessed documents because parsing several PDFs during a live hackathon demo is both slow and kind of asking for something to go wrong.

Challenges

Probably the biggest challenge was figuring out what ClaimBridge should actually do with the documents once we had the text.

The easiest solution would have been to put everything into an LLM and ask it to explain the claim. We tried to avoid relying on that because it makes it harder to know exactly where an answer came from. A lot of our work ended up being around structuring the information and keeping track of the evidence behind each conclusion.

The other big challenge was the UI. There can be a lot of relationships between the documents, but dumping all of those onto the screen is not very useful. We had to figure out how to show enough information to explain the reasoning without making the user understand the entire underlying graph.

We also ran into the normal hackathon problem of processing taking longer than we wanted. That is why we added the preprocessed demo path while still keeping the actual document pipeline in the project.

What we learned

One of the more interesting things we learned was that an LLM did not necessarily need to be the main reasoning system.

Once the information was structured, a lot of the useful reasoning could come from the relationships between pieces of evidence. That also made it much easier to trace a result back to the documents that caused it.

We also learned pretty quickly that extracting text from insurance documents is only the first part of the problem. The harder part is figuring out which pieces from different documents are related and then presenting those connections in a way that makes sense to someone who does not know much about insurance.

What's next

We focused on health insurance for the hackathon because it gave us a specific problem we could actually build around.

If we kept working on ClaimBridge, we would want to add more sources of information beyond the documents a user uploads, especially insurance rules, regulations, and past claim information. We would also want to improve the document processing so users could upload their own claim and get the same experience without relying on anything being preprocessed.