Repository navigation
Home
HealthBook AI — your private family health workspace. This wiki is the engineering documentation for the public showcase repository dranubhaparashar/HealthBook-AI. It describes the system as implemented: architecture, data model, security boundaries and each feature pipeline, with Mermaid diagrams throughout.
HealthBook AI is a privacy-first longitudinal family health-record platform. It keeps original medical documents encrypted and private, turns them into structured records only after a person has verified them, separates what was prescribed from what was actually given, and lets a family export or share exactly the part of the history a clinician needs. The same FastAPI backend serves a web application and an Android app. The internal code name is BabyCare, which is why configuration uses the BABYCARE_ prefix.
This is a sanitized public technical showcase. Production infrastructure, credentials, source medical documents and patient records are maintained separately and are not part of the repository or this wiki. Every example uses synthetic data such as Alex Example and
demo@example.invalid.
Project Portfolio: https://dranubhaparashar.github.io/projects/?view=projects
flowchart TD
subgraph clients["Clients"]
W["Web application<br/>Firebase Hosting"]
A["Android application<br/>Expo React Native"]
end
subgraph backend["Backend on Render"]
API["FastAPI<br/>auth, ownership checks, domain modules"]
WK["Reminder scheduler tick"]
end
subgraph data["Supabase"]
DB[("PostgreSQL<br/>encrypted clinical fields")]
OBJ[("Private storage bucket<br/>encrypted originals")]
end
EXT["Brevo email, Web Push, Expo push"]
CAM["Local camera worker<br/>home network"]
W -->|"HTTPS"| API
A -->|"HTTPS"| API
API --> DB
API --> OBJ
WK --> API
API --> EXT
CAM -->|"derived events only"| API
These rules are enforced by the data model and the API, not just by the interface. Each one is explained on the page where it applies.
| Rule | Where it is enforced |
|---|---|
| Prescribed ≠ Scheduled ≠ Given/Administered | Medicines and Administration Model |
| OCR extracted ≠ clinically verified | OCR and Human Verification Workflow |
| Vaccination due date ≠ vaccination administered | Vaccination Model |
| Appointment or attendance ≠ treatment administered | Medicines and Administration Model |
| Culture susceptibility ≠ antibiotic actually received | Labs Growth and Longitudinal Health |
| The software never prescribes or independently changes a dose | Design Decisions |
| Stool-image interpretation is observational only, not a diagnosis | Stool Photo Pipeline |
| Parent-entered information stays distinguishable from clinician documentation | Illness History and Lifetime Health |
| Structured records keep provenance to the original document page | Medical Document Ingestion |
| A reminder or notification is never proof that a dose was given | Notifications and Reminder Architecture |
| Link | Purpose |
|---|---|
| GitHub Repository | Sanitized source code, tests and deployment templates |
| Live Application | The deployed web application (sign-in required; no public data) |
| Project Portfolio | Other projects by the author |
Overview
Platform
Identity and access
Medical records
- 10 Document Ingestion
- 11 OCR and Human Verification
- 13 Medicines and Administration
- 14 Vaccination Model
- 15 Labs, Growth, Longitudinal
- 16 Illness and Lifetime Health
Daily care
Output and sharing
Security
Engineering
- 26 Testing and Validation
- 27 Deployment and CI/CD
- 28 Technology Stack
- 29 Design Decisions
- 30 Limitations
- 31 Roadmap