Capstone · sponsored by Medtronic Diabetes

Connected monitoring
for pumps and CGMs.

Phoenix Ascend ingests live telemetry from connected pumps and CGMs, computes clinical insights, and puts them in front of the people who can act on them: patients, caregivers, clinicians. End to end in under two seconds.

See the architecture → Open Athena ↗
End-to-end latency
< 2.0 s
Platform uptime
99.97%
Compliance
HIPAA-ready
Glucose · last 60 min DEV · MMT-1780 · CGM-9
LIVE
142 mg/dL +3.2/min
TIR 24h78%
Above14%
Below8%
Pump · delivering CGM · 4.2 min ago Caregiver · paired
Scroll

Every 5 minutes, a glucose reading
leaves the sensor on someone's arm
and reaches the people who can act on it.

Phoenix Ascend · Platform Overview 01 / Why this matters
By the numbers

What the platform sees in a normal day.

0 CGM readings per patient One every 5 minutes, all 24 hours, ingested, validated, stored.
0 Avg ingest-to-dashboard From device radio to a rendered chart, end to end.
0 Isolation layers Device · API · App · Data — each independently hardened.
0 Uptime target Multi-AZ posture with observability and automated failover.
AthenaInternal Trial Workbench

The tool our team uses to read every pump export.

Athena is our internal analysis companion for the Phoenix Ascend clinical trial. It parses raw pump and CGM exports in the browser, runs the same clinical formulas the Portal surfaces, and gives the engineering and trial team a trusted second opinion against real device files — with no backend and no data at rest.

  • Parses every major pump firmware CSV format: Medtronic, Dexcom, mixed regional delimiters
  • Clinical-grade AGP: Time-in-Range, GMI, variability per Bergenstal & Battelino consensus
  • Browser-only by design: no server, no database, no PHI at rest
  • Used during verification runs to validate Portal outputs against trial exports
Open athena.phoenixascendcloud.com ↗
athena.phoenixascendcloud.com/export/sample
MMT-780 · Trial export
Sample patient · 14 d
Time in Range76%
Variability32mg/dL
Episodes41
CGM active101%
portal.phoenixascendcloud.com/patients
My patients · 18 active
⌘K search
AM
A. Morgan
TIR 82%
141 ↗
JS
J. Silva
TIR 64%
186 →
RK
R. Kapoor
Low 58
58 ↘
LP
L. Park
TIR 88%
118 →
PortalPatient & Caregiver

Built for the 3 a.m. glance.

At 3 a.m., a parent opens the Portal and sees one glucose number, one trend arrow, and whether to be worried. Nothing else. That is the whole design.

  • Live reading, trend arrow, time-in-range at a glance
  • Caregiver pairing with scoped, revocable access
  • Configurable alert windows and escalation paths
  • Renders on a 2018 phone on spotty LTE, on purpose. Diabetes does not wait for good signal.
Open portal.phoenixascendcloud.com ↗
Why Phoenix Ascend

A platform built for the telemetry — not bolted onto a record system.

Device data has different failure modes than claims, notes, or labs. Phoenix Ascend treats it that way from the first byte.

Capability
Generic EHR portal
Phoenix Ascend
Live CGM + pump telemetry
Hourly batch, often manual
Streaming, sub-2-second
Purpose-built patient view
Buried in chart tabs
Dedicated Portal, mobile-first
Caregiver pairing
Via proxy access request
Scoped, revocable, audit-logged
Vendor-agnostic pump & CGM export parsing
Vendor-specific tools only
Athena, in-browser, every major pump format
Isolation between layers
Monolithic deployment
Four independent layers
HIPAA-grade audit trail
Yes
Yes, down to the reading
Security & compliance

Security decisions made once, before the first byte.

Patient data is treated as PHI from the moment a device radio emits it. Transport, storage, and access are hardened and audited at every layer, so a bug in the application cannot become a breach in the record.

Transport

TLS 1.3 end to end

Mutual TLS between device gateways and the API; certificate pinning on mobile clients.

Storage

Encrypted at rest

AES-256 per-tenant encryption envelopes; key material isolated from the data plane.

Access

Scoped & revocable

Access granted per session for clinicians, patients, caregivers. Revoked in one click. Every view tied to a name and a timestamp.

Audit

Append-only trail

Every reading, every view, every export — tied to an identity and a timestamp.

Origin

A Medtronic capstone, built like a product.

Phoenix Ascend began in fall 2025 as a Senior Capstone project sponsored by Medtronic Diabetes. The brief was deliberately open: build a modern cloud platform for connected-device telemetry — the way you'd build it in industry. We took that seriously.

Aug 2025

Capstone kickoff

Team formed. Medtronic sponsors scoped the brief: real telemetry, real scale, real clinical vocabulary.

Oct 2025

Four-layer architecture locked

Device · API · App · Data. Each layer independently deployable, testable, and hardened.

Feb 2026

Portal beta, Athena supporting verification

First clinician walkthroughs of the Portal; first end-to-end reading from simulated CGM to rendered chart. Athena running alongside, parsing trial exports to validate Portal outputs against raw device data.

Apr 2026

Capstone showcase

Platform running in multi-AZ posture; sub-2-second ingest-to-dashboard; HIPAA-ready audit trail.

Questions we get

Things worth being clear about.

Is Phoenix Ascend FDA cleared? +
No — Phoenix Ascend is a capstone platform, not a cleared medical device. It is architected to the patterns a cleared system would need (HIPAA-grade audit, layer isolation, reproducible deploys), but it is not a replacement for Medtronic's regulated clinical tooling.
Whose data flows through it? +
For the capstone, synthetic and de-identified telemetry only. The platform is shaped so that real PHI could flow through it under a proper BAA — that's the point of the layered architecture and audit posture — but we do not run real patient data.
Why two apps instead of one? +
Portal and Athena are different jobs for different audiences. Portal is the live clinical product, built for patients, caregivers, and clinicians. Athena is our internal analysis workbench for the clinical trial: it parses raw pump and CGM exports in the browser so the engineering team can validate Portal outputs against real device files without ever touching server-side PHI. Merging them would force one to carry the other's trust boundary.
What does "four-layer architecture" actually mean? +
Device layer (simulated pumps and CGMs), API layer (authenticated ingress and service mesh), App layer (Portal plus the Athena trial workbench), Data layer (time-series store, warehouse, audit log). Each layer is versioned, observable, and deployable on its own — failure in one doesn't cascade.
Who is on the team? +
Four seniors, one Medtronic sponsor, and a faculty advisor. Full bios live on the Team page.
Can I read the architecture? +
Yes — the Architecture page walks through the four layers, the telemetry journey, and the stack with no hand-waving.
Phoenix Ascend

Medical-grade data.
No handholding.

Explore the architecture, meet the team, or open one of the apps. Whichever tells you what you need to know.

Read the architecture → Meet the team