# MediBot — Hospital Patient-History Assistant **A retrieval-grounded chat assistant that returns a patient's full history at the hospital from a single ID, username, or phone number — over a record set that refreshes every 24 hours.** - **Role** — Team Lead: architecture design, RAG pipeline, backend, work distribution - **Team** — 3 engineers - **Scale** — 8,000+ patient records · 300-question request buffer · ~100 concurrent queries - **Stack** — Python · REST API · MongoDB · vector retrieval · OpenAI GPT-3.5 · scheduled refresh job - **Focus** — Retrieval-Augmented Generation · data pipeline design · grounded response guarantees When a patient walks into a hospital, the staff member in front of them needs one thing quickly: what has this person been treated for here before, and what requests are still open. MediBot answers that in a chat window. Staff type an identifier, and the system returns the patient's visit record along with their previous and pending requests — no navigating a records system, no calling another department. --- ## Project Brief I led a 3-person team to design and build **MediBot**, a retrieval-augmented assistant over live hospital patient data. I owned the architecture, the RAG pipeline, and the work distribution across the team. The system was built on real operational data: **8,000+ patient records** gathered from the hospital, held in a maintained sheet that serves as the source of truth. Rather than requiring staff to learn a records interface, MediBot exposes the entire history through natural-language chat, keyed on whatever identifier the front desk happens to have — patient ID, username, or phone number. --- ## Problem Statement Hospital front-desk and clinical staff need a patient's prior history at that specific hospital, and they need it while the patient is standing there. In practice that history is scattered across records systems, and retrieving it means either knowing exactly where to look or asking someone who does. ### Key Challenges 1. **Identifier Ambiguity**: The one piece of information staff reliably have varies by situation — sometimes a patient ID, sometimes a name, often only a phone number. The system had to resolve any of them to the same record. 2. **Grounded Answers Only**: In a clinical context, a fluent but invented patient history is worse than no answer. The system needed a hard guarantee that it only reports what it actually retrieved, and says so plainly when a patient has no file. 3. **Freshness Without Retraining**: New visits and requests are recorded continuously. Answers had to reflect current data without a costly retraining cycle every time the record set changed. 4. **Concurrent Load**: Multiple desks query the system simultaneously during peak hours, so the serving layer had to absorb bursts without dropping requests. --- ## Solution Architecture The system separates a **scheduled data-refresh pipeline** from a **real-time query path**, connected by a shared store. Each side can be changed without touching the other.  *End-to-end flow — the scheduled pipeline re-indexes new records every 24 hours; the live path resolves an identifier, retrieves, and branches on whether a record was actually found.* ### Key Components * **Source Layer**: Maintained patient sheet holding visit history and raised requests, appended as new activity is recorded. * **Refresh Pipeline**: Scheduled job that picks up new rows, normalizes them into structured records, embeds them, and re-indexes the vector store. * **Retrieval Layer**: Cache-first lookup, falling through to MongoDB and the vector index. * **Generation Layer**: GPT-3.5 phrasing an answer strictly from retrieved records, with a deterministic fallback when retrieval returns nothing. * **Serving Layer**: Python REST API with a buffered request queue sized for 300 questions and roughly 100 concurrent users. --- ## Technical Execution ### 1. Data Foundation * Gathered and structured a real patient dataset of **8,000+ records** directly from the hospital. * Normalized inconsistent sheet rows into a consistent record schema covering identity fields, visit history, and raised requests. * Established the sheet as an append-only source of truth so new activity flows into the system without manual intervention. ### 2. RAG Pipeline * Built the retrieval pipeline that reads the record set, chunks and embeds each patient record, and indexes it for semantic lookup. * Implemented identifier resolution so a patient ID, username, or phone number all resolve to the same underlying record. * Wired generation so the model receives only retrieved context — its job is phrasing, not recall. * Designed the **no-match path** as a first-class outcome: when retrieval returns nothing, the system responds that the patient has no record or booking at the hospital rather than attempting an answer. ### 3. Backend and Serving * Developed the backend in **Python** with a REST API surface and **MongoDB** as the record store. * Added a caching layer so repeat lookups on the same patient skip retrieval entirely. * Sized a buffered request queue to absorb **300 questions**, holding throughput steady for roughly **100 concurrent users** during peak desk activity. * Owned the end-to-end pipeline: request handling, retrieval orchestration, generation, and response formatting. ### 4. Scheduled Refresh * Built a **24-hour scheduled job** that appends newly recorded activity, re-processes the delta, and refreshes the index. * Kept the refresh at the index layer rather than the model layer, so a patient admitted today becomes answerable on the next cycle with no retraining cost. * Result: staff query a record set that is never more than one cycle behind the hospital's own books. --- ## Results & Impact * **Single-question patient lookup**: Staff retrieve a full history from one identifier, in a chat window, without touching a records interface. * **Grounded by construction**: Every answer traces to a retrieved record; patients with no file produce an explicit miss rather than a fabricated history. * **Operational data scale**: Built and deployed against **8,000+ real patient records** rather than synthetic data. * **Sustained concurrency**: Buffered serving layer holding **300 queued questions** and roughly **100 concurrent users**. * **Always-current answers**: 24-hour refresh cycle keeping responses aligned with the hospital's live record set. --- ## Key Learnings * **Retrieval quality sets the ceiling.** In a RAG system the model is the last and least consequential step — almost all answer quality is decided by how records are structured, chunked, and indexed before generation is ever reached. * **A confident wrong answer is the real failure mode.** Designing the no-match branch as an explicit, deliberate path — rather than leaving the model to improvise — was the single most important decision in a healthcare context. * **Refresh the index, not the weights.** Separating data freshness from model training is what made a 24-hour cycle affordable; conflating them would have made the same feature impractical. * **Leading three people is an architecture problem.** Clean boundaries between the refresh pipeline, retrieval layer, and serving layer were what let three engineers work in parallel without blocking each other.