Backend
- FastAPIREST API
- Python 3.13Runtime
- Pydantic v2Validation
- Auth0 + RLSIdentity
How it works
From a device signal
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 telemetry payload follows the same route: captured, validated, stored in time-series tables, and rendered for the role requesting it.
01 / 05
Device
CGM sensors emit a glucose reading every 5 minutes. Pumps emit delivery events alongside them: boluses, basal changes, alarms. Every payload is signed against the device's stored key.
device · mmt-780 + paired CGMLIVE
- pump
- MMT-780G · 9f3a7c1e
- CGM reading
- 142 mg/dL · trend +3.2/min
- payload
- CBOR · 184 bytes
- signature
- ed25519 · valid
02 / 05
Bridge
A phone-side relay batches readings, retries on flaky networks, and hands them to the API over mTLS.
bridge · ios 18 · batchOK
- queue
- 3 readings · oldest 9 s
- transport
- HTTPS · mTLS 1.3
- retry policy
- expo · jitter · 5 attempts
- payload
- gzip · 512 bytes
03 / 05
API
FastAPI validates the payload, checks the signature, and writes to the time-series hypertable — all inside one request.
api · ingest · p50 38 ms200
- endpoint
- POST /v1/readings
- auth
- Auth0 JWT · RS256
- validation
- Pydantic v2 · strict
- audit
- logged · append-only
04 / 05
TimescaleDB
Readings land in a hypertable chunked by 7-day windows. Continuous aggregates compute hourly and daily stats in the background.
pg 17 · timescale · hypertableOK
- table
- readings
- chunks
- 248 · 7-day windows
- compression
- > 30 days · 8.4×
- RLS
- per-session policy
05 / 05
Dashboard
The Portal queries pre-aggregated views, so dashboards resolve in one round-trip, not fifty. Athena, our internal trial workbench, reads device exports straight off the client's disk instead.
client · portal · react 19RENDER
- query
- GET /v1/patients/:id/tir
- cache
- SWR · 30 s
- render
- ECharts · canvas
- p95 ingest → view
- 1.8 s
02 · Hard problems
The decisions that shape the system.
Four problems every medical-device platform has to answer. Here's what we chose — and the trade-offs behind it.
01Security
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.
02Performance
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.
03Testing
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.
04Synthetic data
How do you generate realistic test data?
You can't test a medical platform with random numbers. Our generator produces output that matches real device log formats byte for byte, with glucose and pump distributions 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
- Cont. aggregatesFast reads
- pgcryptoAES-256
Frontend
- React 19Product UIs
- ViteBuild tooling
- EChartsVisualization
- Tailwind CSSStyling
Infrastructure
- DockerContainers
- Pi 5 → AWSCompute
- TerraformIaC
- GitHub ActionsCI/CD
04 · Operating posture
What the platform commits to.
0
p95 end-to-end
Device radio to a rendered chart — the number we optimize.
0
Compression ratio
On > 30-day-old chunks — readable, not just archived.
0
Isolation gates
Auth0 · RLS · pgcrypto · append-only audit log.
0
Uptime target
Multi-AZ posture with observability and automated failover.
Architecture
Four layers.
Four layers.
Each one distrusts the next.
That is not a slogan. It is how the permissions, the audit trail, and the deploy pipelines are wired. Meet the team that built it, or jump into the apps themselves.