Event-Driven RAG System for Healthcare Benefits Using MCP

daisy_health · Healthcare · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: healthcare benefits document ingestion and employee search

Daisy Health needed to keep PDF-based healthcare benefits information current and searchable for employees without manually reindexing entire vector stores whenever providers sent updated documents.

Constraints:

Healthcare benefits documents are usually PDFs and often arrive by email or provider updates.
Documents become outdated and require frequent updates.
Employees need plan-specific answers, comparisons, and recommendations.
The platform must preserve authentication and tenant context.
The system needs real-time vectorization and targeted retrieval across plan status, employer, and benefit type.

Architecture

Daisy Health built an event-driven RAG system around MCP. Providers can send documents through REST endpoints or scheduled scraping, PDFs land in S3, Lambda triggers an MCP server to parse and vectorize plan data with AWS Titan, vectors are stored in LanceDB, and the employee chatbot uses MCP tools plus elicitation and app context to search the right plan documents. API Gateway, Cognito, and JWT tokens carry authentication into tool calls.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  provider-document-intake["Provider document intake"] --> s3-document-store["S3 document store"]
  s3-document-store --> aws-lambda-trigger["AWS Lambda trigger"]
  aws-lambda-trigger --> mcp-server["MCP server"]
  mcp-server --> lancedb-vector-store["LanceDB vector store"]
  mcp-server --> benefits-chatbot["Benefits chatbot"]
  benefits-chatbot --> elicitation-and-app-context["Elicitation and app context"]
  elicitation-and-app-context --> mcp-server
  cognito-and-jwt-auth["Cognito and JWT auth"] --> mcp-server

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Provider document intake`	REST endpoints or scrapers that receive healthcare benefit PDFs and updates from providers.	`S3 document store`
`S3 document store`	Source of truth for uploaded PDFs.	`AWS Lambda trigger`
`AWS Lambda trigger`	Runs on S3 document events and calls the MCP vectorization tool.	`MCP server`
`MCP server`	Hosts vectorization and search tools for ingestion and chatbot retrieval.	`LanceDB vector store`, `Benefits chatbot`
`LanceDB vector store`	Stores vectorized benefits-plan data.	`Benefits chatbot`
`Benefits chatbot`	Employee-facing interface for benefit questions, comparisons, and recommendations.	`Elicitation and app context`
`Elicitation and app context`	Supplies plan status, employer, and user context for targeted retrieval.	`MCP server`
`Cognito and JWT auth`	Carries authenticated user context through API Gateway into endpoint calls.	`MCP server`

Data flow

Provider documents are uploaded or pulled into S3. S3 events trigger AWS Lambda, which calls the MCP server with the S3 key, plan ID, and MIME type. The MCP server parses, vectorizes with AWS Titan, and stores vectors in LanceDB. The chatbot sends employee questions and context to MCP search tools, optionally using elicitation for plan status and employer, then returns grounded plan answers and recommendations.

“our AWS Lambda is able to you know serve basically on event uh as documents are being dro dropped in trigger an event”transcript, stated

“the MCP server is responsible for parsing that file uh vectorizing the d a uh the data with AWS titan and then storing that uh vectorzed data into our vector store”transcript, stated

Why this architecture

Daisy used an event-driven MCP architecture because provider documents change continually and whole-store manual reindexing was painful. S3/Lambda handles real-time ingestion, MCP packages reusable ingestion and search tools, and elicitation plus app context narrows retrieval to the employee's employer and plan status.

“I have to currently reindex the whole vector store every time I I get a new new document because that process isn't so um ironed out.”transcript, stated

“use the MCP tools to be able to you know do real time document ingestion and vectorization”transcript, stated

Models used: Anthropic MCP · Anthropic Sonnet 4 · AWS Titan embeddings · LanceDB · AWS Lambda · S3 · AWS Cognito

Scale

Daisy Health has about 50,000 employees on the platform.
“we have about 50,000 or so um employees on the platform with a wide range of health care options.”transcript, stated
The platform offers telemedicine and generic prescriptions under $30 per month per employee.
“we're providing tele medicine and generic prescriptions for under $30 a month per employee.”transcript, stated

Alternatives considered (roads not taken)

Manual vector-store reindexing for each new document.

Rejected because: Updates were frequent and the current process forced whole-store reindexing.

“I have to currently reindex the whole vector store every time I I get a new new document”transcript, stated

Ask customers for updated provider information manually.

Rejected because: Daisy wanted to stop pestering customers and integrate directly with providers.

“we often have to pester them for that information and instead integrate directly with the providers.”transcript, stated

Have Lambda call the vector store directly instead of MCP.

Rejected because: The team valued MCP's reusable modular tool boundary for both ingestion and retrieval.

“what's interesting with MCP is this modularity thing where it's like it's kind of helping people put these reusable”transcript, stated

Patterns

`rag-retrieval` (benefits search)

The chatbot retrieves vectorized benefits-plan data from LanceDB through MCP search tools.

“integrate with our chatbot to um to do searches against our our LLM”transcript, stated

`tool-use-orchestration` (MCP tools)

MCP exposes vectorization and search tools used by Lambda, inspector demos, and the chatbot.

“the first tool I discussed was the vectorzation of the plan data.”transcript, stated

`data-quality-loop` (ingestion)

S3 upload events trigger Lambda-driven vectorization of plan documents.

“provide that event driven um S3 integration.”transcript, stated

`query-rewriting` (targeted retrieval)

Elicitation gathers plan status and employer context before the MCP server performs targeted retrieval.

“we're using elicitation to uh ask more details. Uh in this case we're just doing the plan status and the employer.”transcript, stated

`safety-policy-enforcement` (auth and tenant context)

API Gateway and Cognito JWT tokens pass authenticated context into MCP endpoint calls.

“grab the JWT token out of Cognto and uh send that along when we're when we're calling these endpoints.”transcript, stated

Tradeoffs

Wrap ingestion and retrieval in MCP.

Chose Reusable MCP server tools over Direct Lambda-to-vector-store integration.

Rationale: MCP made the same vectorization and retrieval capabilities reusable across workflows and clients.

“I'm going to reuse this MCP server and grab data instead of like having the AI call it or whatever.”transcript, stated

Use event-driven ingestion.

Chose S3 upload events and Lambda over Manual batch reindexing.

Rationale: New PDFs can be vectorized as they arrive rather than waiting for manual store refresh.

“as documents are being dro dropped in trigger an event and then this is the magic that now calls our MCP server”transcript, stated

Gotchas (what bit them)

PDF benefits documents go stale quickly.

Root cause: Healthcare providers send updates in PDF form, while the vector store previously required manual reindexing.

Resolution: Use provider endpoints or scrapers plus event-driven ingestion and vectorization.

“PDFs are like ubiquitous in the healthc care space. They're often emailed to us”transcript, stated

The assistant needs employer and plan context for useful answers.

Root cause: Benefit eligibility and plan options depend on the employee's employer and enrollment status.

Resolution: Use elicitation or app context to pass plan status and employer to MCP retrieval.

“elicit data from the user and then send that information um back to the MCP server so it can go do a more targeted retrieval”transcript, stated

Recommendations require more user detail than simple plan lookup.

Root cause: Plan recommendation depends on family, coverage, therapy, and other personal constraints.

Resolution: The chatbot asks for additional context before recommending a plan.

“we ask it like, "Hey, can you recommend a plan for me?" And on that plan uh or on this types of questions”transcript, stated

Evaluation

The talk demonstrates the MCP vectorization and search tools through MCP inspector and chatbot flows rather than describing a formal offline eval suite.

Metrics: Successful vectorization response · Search result relevance · Plan comparison answer quality · Recommendation usefulness · Auth context propagation

“it should say, "Yep, successfully vectorized the plan data."”transcript, stated

Outcomes

Daisy demonstrated real-time vectorization of plan PDFs through MCP.
Employees can ask natural-language questions about available benefits plans.
The chatbot can compare plans and generate personalized recommendations with additional user context.
The architecture supports future elicitation and semantic filtering flows.

The platform serves about 50,000 employees and targets benefits offerings under $30 per employee per month.

“combining Lambda functions triggered by S3 uploads for real-time document vectorization and a chatbot interface for employees to query their benefits.”summary, stated

“it's recommending the HMO plan, lower upfront cost, therapy coverage, medical coverage and family considerations”transcript, stated