Backend
- FastAPIREST API
- Python 3.13Runtime
- Pydantic v2Validation
- Auth0 + RLSIdentity
How it works
From a device signal to a clinician's dashboard — four independent layers, all auditable.
Phoenix Ascend is assembled from small, well-scoped services. Each layer does one thing; together they hold medical-grade data without forcing engineers or clinicians to trust the layer above.
01 / Journey
One path from device to dashboard.
Every reading follows the same route — captured, validated, stored in time-series tables, and rendered for the role requesting it.
01
Device
Pump · CGM
02
Bridge
Phone relay
03
API
Validates · signs
04
TimescaleDB
7-day chunks
05
Dashboard
Role-scoped
02 / Hard problems
The decisions that shape the system.
Four problems that every medical-device platform has to answer. Here's what we chose — and the trade-offs behind it.
01 Security
How do you actually secure medical data?
Most platforms check permissions once, at the application layer. We built four independent gates — if one is compromised, the others still hold.
- 01Auth0 + RS256 JWTs
Multi-factor login, automatic key rotation via JWKS, and short-lived access tokens.
- 02Row-Level Security
RLS policies enforce access per session — patient, clinician, engineer, or admin — independently of the application layer.
- 03Immutable audit trail
Database triggers log every mutation with before/after state — even direct SQL changes are captured and signed.
- 04pgcrypto AES-256
Stored OAuth credentials encrypted with session-scoped keys that are never exposed to the application layer.
02 Performance
How do you make time-series data fast?
Medical devices generate hundreds of readings per day per patient. That data has to be stored, compressed, and queryable in real time.
- 01TimescaleDB hypertables
7-day chunks partition data for range queries that stay snappy into the millions of rows.
- 02Automatic compression
Old chunks compress on a schedule — storage without sacrificing read performance.
- 03Continuous aggregates
Pre-compute hourly and daily glucose/insulin stats so dashboards don't reaggregate on every page load.
- 04COPY BINARY ingest
Bulk loading from device bridges handles spike loads without back-pressuring the API.
03 Testing
How do you test a medical platform?
When incorrect data could affect clinical decisions, coverage isn't optional. We run a two-lane strategy that balances speed with realism.
- 01Contract tests
Minimal seed data, fast feedback — every PR runs the full suite in under a minute.
- 02Full-dataset tests
Months of deterministic synthetic timeseries for realistic validation against production queries.
- 03CI gates
SQL linting, migration-order verification, and security scanning block merges on policy violations.
- 04MSW + integration
Frontend tests use MSW for API mocking with integration tests across critical clinical workflows.
04 Synthetic data
How do you generate realistic test data?
You can't test a medical platform with random numbers. Our generator produces output indistinguishable from real device logs — grounded in published clinical datasets.
- 01Profile-driven
Grounded in 9 published clinical datasets covering thousands of real patients — no synthetic shape we haven't seen in the wild.
- 02Zero dependencies
Pure Python stdlib — runs anywhere, no supply-chain surface.
- 03Patients evolve
Over 90 days therapy adjusts, glucose patterns shift, adherence changes — tests see the same drift a clinician would.
- 04Format parity
Output matches real device logs exactly — validated against the same parsers used in production.
03 / Stack
What it's built on.
A pragmatic stack — designed today to scale to cloud infrastructure tomorrow.
Data
- TimescaleDBHypertables
- PostgreSQL 17Core DB
- Continuous aggregatesFast reads
- pgcryptoAES-256
Frontend
- React 19Product UIs
- ViteBuild tooling
- EChartsVisualization
- Tailwind CSSStyling
Infrastructure
- DockerContainers
- Pi 5 → AWSCompute
- TerraformIaC
- GitHub ActionsCI/CD