Healthcare Monitoring System
A Semester 4 group healthcare monitoring platform spanning device ingest, streaming intelligence, dashboards, and cloud platform work across the Healthcare-Monitoring-System org (backend, d2-data-intelligence, d3-frontend-dashboard).
My contribution was in subgroup D2 — Data & Intelligence (d2-data-intelligence): turning raw vitals into scored, alert-ready events for clinician UIs. D2 sits between D1 (wearables / MQTT edge) and D3 (Next.js / Flutter dashboards). A Kafka worker consumes `vitals.raw`, validates readings, runs a shared feature engine (rolling windows, trends, normal/warning/critical thresholds), scores with PyTorch models, persists to PostgreSQL, and publishes `vitals.scored` / `alerts`. A FastAPI layer exposes latest vitals, history, and summaries for D3 under documented integration contracts, with hybrid batch paths for retraining from stored data.
The wider system deploys on K3s with Argo CD (D2 API + worker, backend API, D3 frontend, PostgreSQL, InfluxDB), with D4 covering Keycloak, Vault, Prometheus/Grafana, and GitOps. End-to-end demo path: raw vital → Kafka → worker score → Postgres → D2 API → D3 dashboard alert.
Year
Features
Technologies
- Keeping one feature definition across training notebooks, Kafka worker, and sync API scoring
- Decoupling device producers from dashboards without losing alert latency
- Aligning D2 analytics schema with backend-owned identity/domain tables under Keycloak
- Coordinating topic names, patient/device IDs, and JSON contracts across four subgroups
- Running a multi-service stack (API, worker, DB, Kafka, dashboards) reliably on K3s for demos
- Centralized feature module under src/d2/features imported by ML, worker, and API
- Kafka topics vitals.raw → worker → vitals.scored / alerts as the live backbone
- D2-owned analytics migrations only; shared core schema owned by backend deploys
- INTEGRATION_D3.md + Pydantic schemas updated in the same PRs as public JSON changes
- Containerized D2 API/worker with Argo CD on K3s alongside Postgres and InfluxDB
Key Features
D2 stream worker: consume vitals.raw, validate, featureize, infer, persist, publish vitals.scored / alerts
Canonical vitals feature engine — rolling windows, trends, threshold status for train and serve
PyTorch anomaly / risk models with versioned inference for API and worker
FastAPI REST for D3 — latest vitals, history, doctor/patient summaries, live/ready/health probes
PostgreSQL persistence with D2 analytics migrations and demo seed for admin dashboards
Optional sync scoring path for demos alongside the async Kafka path
Integration contracts documented for D3 JSON shapes and enums
K3s deploy: D2 API + worker images alongside backend, Next.js dashboard, Postgres, InfluxDB
CI with pytest; observability hooks for Prometheus metrics
Full-system context: D1 MQTT devices, D3 Next.js/Flutter UIs, D4 Keycloak/Vault/GitOps
Technologies
Learnings
Built a streaming ML path where feature code is shared across train, worker, and API — no duplicated vitals math
Designed Kafka consume → feature → PyTorch infer → Postgres → scored/alert publish for live monitoring
Exposed D3-facing FastAPI contracts (vitals, history, summaries) kept in sync with integration docs
Operated hybrid batch + stream: live scoring plus DB/processed-data retrain loops
Collaborated across D1–D4 boundaries (MQTT edge, dashboards, Keycloak, K8s GitOps) on a large course team
Highlights
D2 Data Intelligence
Kafka → Score → API
K3s / Argo CD
Next Project