Health Insurance Policy Assistant

The chat interface

Inspiration

I recently learned that if your family uses the Affordable Care Act, and you are eligible for Medicaid, you must use Medicaid. So I was kicked off my family's ACA insurance and forced to use Medicaid that I didn't want. This got me thinking about the health insurance industry and how confusing it was. I remembered a video I'd seen a while ago about using vector search to provide grounded answers based on a document, and I connected that with an app I heard about where you could use an AI chatbot to ask about the instruction manuals of your appliances. So we applied this idea to health insurance to create a personalized assistant that can provide cited answers to your insurance questions.

What it does

First the user uploads the Summary of Benefits and Coverage (SBC) document. There is a default policy already loaded, which is the standard policy for Medicare. Then the user can ask general insurance questions or questions about their specific policy. The chatbot will use specific context from your policy to ground its answer and break down complex insurance concepts.

How we built it

We used a RAG model using a vector database to provide specific knowledge from the document. This step is modular and the specific database used can be configured. You can either run the database locally using the Python Chroma package or use our Vultr hosting option. If you create the vector database locally, you can also use any embedding model. The default is a local model from HuggingFace called MiniLM v6. Then you can use the AI chat. When you ask a question, your prompt will be analyzed and processed in 3 categories - General Knowledge (about insurance), Specific Policy Knowledge (found using vector search) or Out of Scope. If the question is general knowledge, it will be sent directly to an LLM. The LLM used is also configurable. The default option is using Deepseek v4 hosted on Vultr. If the question is specific, the vector database will be queried and the result will be added to the prompt sent to the LLM. Finally the result will be formatted and presented to the user.

Challenges we ran into

We had issues using the Vultr vector database. We were able to solve this using a clever abstraction - we abstracted away the details of the vector store into an interface (abstract class in Python). Then we created 2 classes - LocalVectorStore and VultrVectorStore. However the VultrVectorStore cheats a little. It will create a private LocalVectorStore using the default settings and use it while the Vultr API returns errors. Once it gets a 200 response from the API, it will delete the local store and switch to Vultr. These details are all hidden from the rest of the program. Another issue we dealt with was that the vector store doesn't have any context about what falls under different medical categories. So if you asked about "appendectomy", the vector store would return bad results because the word "appendectomy" is not similar enough to "surgery". We solved this by using an LLM to expand specific words into general insurance terms to make them understandable to the vector store.

Accomplishments that we're proud of

Due to our modular object-oriented design it was very easy to switch to Vultr midway through development. It would be very simple to add more privacy features like more local models or to self-host your own vector database and LLM. This also makes it easier for to achieve good compliance with things like HIPPA if necessary. You can even change models or vector databases while the program is running if you hide the details inside the vector store class. As noted, we do this as our default behavior.

What we learned

We learned about the architecture of vector search based RAG chatbots and health insurance. This was our first experience making an AI-focused project and AI was used throughout the development process as well. It was one of our team members first experiences using Python as well as API keys and cloud APIs.

What's next for Health Insurance Policy Assistant

Our next step would be to add a feature where a user can compare different policies at the same time to help them decide which would be best for them. Implementing this would mean changing how the vector stores work to either have multiple stores, each for one document, which would increase the code complexity. We could also putt multiple documents into one store, but the user needs to know which document a detail came from and we currently don't know how to do that with all documents in one store. We would also like to hook up a database where the AI can look up typical prices for common procedures, then apply the rules from the user's policy to calculate an out-of-pocket cost estimate.