OpenCare

A personal health-records assistant: patients keep their own health profile and ask an AI questions about it, with answers grounded in their records and in current medical sources.

Database Systems course project (CS 3600), University of Idaho, Spring 2026 · Built with Chetanna Amadike 📄 Paper: OpenCare (ACM format)

---

Why we built it

Medical information about a patient is scattered across providers and written for clinicians. Generic AI chatbots answer health questions without knowing anything about the person asking.

We implemented the PerHL (Personal Health Library) architecture from a published research paper: a patient-owned record store, an open web retrieval layer, and a conversational interface that combines the two. We documented the system in an ACM-format paper.

How it works

1. The patient's record: vitals, conditions, medications, and allergies are stored as a structured health profile in PostgreSQL.
2. Personalized answers: the patient chats with Gemini. Their health profile is injected into each query, so answers are about them (for example, a question about a new medication takes their existing medications and allergies into account).
3. Current medical sources: when a question needs outside information, the app retrieves it with live web search (Tavily), and responses stream back in real time.
4. Document uploads: files the patient uploads go through an automated redaction service that removes their sensitive terms before anything is stored.

---

Engineering highlights

Semantic caching with pgvector

Web searches are slow and cost money per call. Every search query is embedded and stored with its results in PostgreSQL with pgvector. When a new question is semantically close to one already answered, the cached results are reused instead of searching again: faster responses and fewer API calls.

We kept the cache in the same PostgreSQL database as the rest of the data rather than adding a dedicated vector database, so there's one system to run and back up instead of two.

Protecting health data

• Server-side sessions (not JWTs) with bcrypt-hashed passwords, so a session can be revoked immediately.
• Automated redaction: a separate Flask + PyMuPDF microservice strips each patient's sensitive terms from uploaded PDFs and images before storage.
• The redaction terms themselves are sensitive. A list of the diagnoses and names a patient wants hidden reveals as much as the documents, so the terms are protected with double-layer AES-256-GCM encryption.

Architecture

React chat UI  →  Node.js / Express API  →  PostgreSQL (health profiles, pgvector cache)
                          │                 Object storage (MinIO)
                          ├──→ Flask redaction service (PyMuPDF)
                          └──→ Gemini + Tavily

PyMuPDF is a Python library, so redaction runs as its own small service while the main API stays in Node.js.

---

Limitations and what we'd do next

• Not medical advice: OpenCare helps patients understand and query their own records. It is not a diagnostic tool.
• Redaction is term-based: it only removes terms the patient lists. Adding named-entity recognition would catch identifiers they forget.
• Evaluation: the next step is measuring cache hit rate and answer quality systematically instead of by inspection.

Stack: React · Node.js/Express · PostgreSQL/pgvector · Flask · PyMuPDF · Gemini · Tavily · Docker

Running locally

The project uses Git submodules (app/, server/, python-server/).

git clone --recurse-submodules <repo-url>
docker compose up -d   # PostgreSQL + MinIO
psql postgresql://postgres:postgres@localhost:5432/postgres -f server/db-migrations/generate-tables.sql

Copy each service's .env.example to .env, then run npm install && npm run dev in app/ and server/, and pip install flask pymupdf && python run.py in python-server/.