Building Chronic Disease Copilot
: A Privacy-First AI Health Companion That Never Phones Home
Building Chronic Disease Copilot
A Privacy-First AI Health Companion
That Never Phones Home
The Problem with Chronic Disease Management
If you've ever managed a chronic condition — diabetes, hypertension, an autoimmune disorder — you know the real burden isn't the disease itself. It's the bookkeeping. Tracking symptoms daily, remembering medication interactions, decoding lab reports full of jargon, and walking into every doctor's appointment hoping you remembered to mention the thing that happened three weeks ago.
Most "health AI" solutions solve this by routing your most sensitive data through a cloud API. That trade-off — convenience for privacy — felt wrong for a domain this sensitive. So I built Chronic Disease Copilot: a 24/7 health companion that talks to you, listens to you, and analyzes your symptoms — without your health data ever leaving your machine.
This post walks through the architecture, the technical decisions behind it, and why "local-first" isn't just a privacy slogan but a real engineering constraint that shapes everything downstream.
Design Philosophy: Privacy as a Default, Not a Setting
Before writing a line of code, I set one non-negotiable rule: the AI inference layer must run entirely on-device. This single constraint cascades into almost every architectural choice in the project:
- No third-party LLM API for symptom analysis → Ollama, running locally
- No mandatory persistent storage of raw health data → an opt-in Zero Retention Mode
- Voice interaction without uploading raw audio to a black-box service for interpretation → local speech processing paired with ElevenLabs purely for natural-sounding output, not analysis
The result is a system that can operate fully offline for its core intelligence, with cloud services involved only where they don't touch sensitive interpretation — closer to a HIPAA-conscious design pattern than a typical SaaS health app.
System Architecture
The application is split cleanly into three layers:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌─────────────────────────────┐
│ React 19 + Vite Frontend │ ← Dashboard, voice UI, trends
└──────────────┬───────────────┘
│ REST / WebSocket
┌──────────────▼───────────────┐
│ Node.js + Express Backend │ ← Orchestration, API routes
│ Better-SQLite3 (local DB) │
└──────────────┬───────────────┘
│
┌───────┴────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Ollama │ │ ElevenLabs │
│ (local LLM) │ │ (voice TTS)│
└─────────────┘ └─────────────┘
Frontend: React 19 with Vite for fast dev iteration, Tailwind CSS for styling, Framer Motion for the kind of subtle UI animation that makes a health app feel calm rather than clinical, and Lucide React for iconography.
Backend: A lightweight Node.js + Express server acts as the orchestration layer — routing voice input, talking to Ollama for inference, and managing the SQLite data layer via Better-SQLite3 (chosen specifically for its synchronous API and zero external dependency footprint — no database server to run, just a file on disk).
Inference: Ollama running models like
qwen3.5 or llama3 locally handles all symptom classification, severity scoring, and drug-interaction analysis. This is the crux of the privacy model — the model weights live on the user's machine, so a symptom log never has to leave the local network boundary to be understood.Feature Deep-Dive
1. Voice-Activated Symptom Logger
The logging flow is built around natural speech rather than forms. A user taps the microphone, describes how they're feeling in plain language, and the local LLM does two things simultaneously:
- Classifies severity against historical baseline
- Flags patterns that look concerning (e.g., a symptom cluster that historically precedes a flare-up)
Because this runs through Ollama rather than a hosted API, there's no round-trip latency to a remote server and no risk of a third party retaining a transcript of someone describing their chest pain at 2 a.m.
2. Zero Retention Mode (HIPAA-Conscious Operation)
This was the feature I spent the most design time on. When toggled on, the application processes input in-memory only — no row is written to SQLite, no log persists past the session. Functionally, this turns the backend into a stateless pass-through for that interaction: data goes in, an LLM response comes out, and then it's gone.
The technical challenge here isn't the toggle itself — it's making sure every code path respects it. That means audit-checking every database write call to confirm it's gated behind the same privacy flag, rather than relying on a single top-level check that's easy to bypass as the codebase grows.
3. Smart Lab Results & Drug Interaction Checking
Lab results are notoriously unreadable to non-clinicians. The copilot takes raw lab values and produces plain-language explanations alongside trend visualizations — for example, surfacing that a metric like HbA1c improved by a specific percentage over the tracked period, rather than leaving the user to interpret a table of acronyms.
The drug interaction checker runs the same way: locally, against the user's logged prescriptions, flagging potentially dangerous combinations without sending a medication list to an external service.
4. Appointment Preparation Coach
Possibly the most underrated feature from a "does this actually change behavior" standpoint. Before a doctor's visit, the system synthesizes recent symptom logs into a structured, shareable brief — plus a list of smart, personalized questions worth asking. It turns "I forgot to mention the headaches" into a one-page document the user can hand to their provider.
Why Local LLM Inference Was the Hard Part
Running inference locally via Ollama sounds simple in principle —
ollama pull, ollama serve, done. In practice, the engineering challenge is prompt design under hardware constraints. Cloud-hosted frontier models can absorb a sloppy, verbose prompt and still produce a good result. A locally-served model running on consumer hardware needs tighter, more deterministic prompting to reliably classify severity or catch a drug interaction without hallucinating.This pushed the system toward:
- Structured output prompting (asking the model to return classification in a constrained format rather than free text)
- Smaller, well-scoped tasks per LLM call instead of one giant "analyze everything" prompt
- Fallback logic for when local inference confidence is low, rather than presenting an uncertain answer as fact
Tech Stack Summary
| Layer | Technology | Why |
|---|---|---|
| Frontend | React 19, Vite, Tailwind CSS | Fast iteration, modern concurrent rendering |
| Animation | Framer Motion | Subtle, calm UI motion for a health context |
| Backend | Node.js, Express | Lightweight orchestration layer |
| Storage | Better-SQLite3 | Zero-dependency local persistence |
| AI Inference | Ollama (qwen3.5 / llama3) | Fully local, private LLM inference |
| Voice Output | ElevenLabs API | Natural, empathetic TTS |
| Speech Input | Native Web Speech API | Browser-native, no extra service dependency |
What I'd Build Next
A few directions worth exploring from here:
- On-device speech-to-text to remove even the lightweight dependency on the browser's Web Speech API, pushing the privacy boundary even further
- Federated trend benchmarking — letting users optionally and anonymously compare their trend trajectory against aggregate patterns, without ever exposing raw data
- Multi-condition profiles, since chronic illness is rarely singular — most patients are managing two or three conditions simultaneously, each with overlapping medication interactions
Closing Thoughts
Chronic Disease Copilot started as a hackathon build, but the constraint that shaped it — health AI shouldn't require giving up privacy — is one I think more health-tech tooling needs to take seriously. Local inference is slower to build and harder to optimize than calling a hosted API, but for a domain where the data is this sensitive, it's a trade worth making.
The full source is available on GitHub: vrushabhzade/Chronic-Disease-Copilot-for-Patients
Contributions, issues, and feature ideas are welcome.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article