Personal Health — Personal Health Stack

Use case

One person, one stack: all health sources (Withings, Samsung Health, ResMed myAir, Health Connect, Telegram bot inputs) land locally on the home server. Daily view of sleep, weight, activity, and CPAP data in a single TimescaleDB. No cloud, no trackers, all on my own iron.

Versions

• personal-health + healthadvisor v1 — first generation, running in daily use. Two cooperating stacks: personal-health is a Markdown knowledge base with a Telegram bot over Claude, healthadvisor is a FastAPI backend with TimescaleDB and an Android frontend. It works, but is token-hungry and split across two repos.
• personal-health-v2 — unified greenfield re-implementation. Both predecessor stacks fold into a single token-efficient system with unified Postgres and a shared backend. Status: spec phase complete, migration in progress, not in production yet.

What's done (v1, running)

• GDPR export pipeline for Withings (scale, sleep, blood pressure)
• Samsung Health sync via Health Connect (steps, heart rate)
• ResMed myAir login through Okta + AppSync GraphQL for CPAP analysis
• Own Postgres + TimescaleDB schema running locally
• Claude bridge for VL analyses (ha-claude-bridge)
• Telegram bot for conversational input into the Markdown knowledge base
• Android frontend for the FastAPI view

What's done (v2, in progress)

• Spec phase complete (as of 2026-05-02), all four owner decisions resolved
• Unified architecture across the two predecessor repos locked in
• Migration plan across five phases, Sub-A.5 as the implementation entry point
• Token strategy defined (vision-v2.md)
• Backend skeleton spec ready for Phase B (sub-b-prime-backend-skeleton.md)

In progress

Sub-A.5 migration: three data sources (old personal-health, old healthadvisor, new direct entries) consolidated into unified Postgres. Phase 0 setup with repo init, schema copy, Postgres container. Until v2 is production-ready, v1 stays the daily workhorse.