TL;DR
When the US introduced new reimbursement codes for remote patient monitoring, Cardiologs saw an opportunity: run Apple Watch & Kardia ECGs through our AI algorithms and give cardiologists a real-time monitoring platform.
I designed both sides of the product — a simple iOS app for patients to send their ECGs, and a responsive web platform for physicians to track, triage, and review cardiac events over time.
The product went from zero to a live beta with US clinics in under six months.
Context
Cardiologs is an AI-powered platform that helps cardiologists and electrophysiologists analyse long-duration ECGs. The AI automatically detects and categorises cardiac arrhythmias, allowing physicians to review cases faster.
Cardiologs RPM came from a regulatory shift: Medicare introduced new reimbursement codes specifically for remote patient monitoring. For the first time, physicians could bill Medicare for continuous monitoring of cardiac data between appointments — creating a viable business model for remote cardiac care.
Our angle was device-agnostic and physician-oriented: leverage the Apple Watch ECG or Kardia device and focus on improving the physician's monitoring workflow. But we only had the algorithm — the RPM platform had to be built from the ground up.
Research & Discovery
The Head of Product ran the initial discovery with cardiologists. I inherited those insights and translated them into early design concepts, then iterated directly with clinicians through mockup reviews and monthly calls once the beta was live.
One insight reshaped the entire Event List design. Physicians told us a flat list of all cardiac events was unworkable — they needed to see only what mattered for each patient's specific condition. A patient monitored for atrial fibrillation management doesn't need the same alert hierarchy as one recovering from a VT ablation.
This feedback led directly to the Important / Secondary split: events classified as clinically significant for the patient's indication surfaced in the "Important" tab, while everything else went to "Secondary."
Key Decisions
Responsive from day one — because alerts don't wait
The product's core promise was real-time monitoring. When the AI detects a concerning cardiac event, the physician needs to see it and act — whether they're at their desk, between consultations, or at home. If the alert arrives and the platform doesn't work on their phone, the product fails its primary use case.
So we designed responsive from the start.
Tables become cards on mobile
On desktop, the Event List is a data table — sortable and filterable. On mobile, I replaced the table with stacked cards. Each event becomes a card with label-value pairs arranged vertically. The tradeoff: you lose the ability to compare across rows at a glance. The gain: every piece of information remains visible and tappable without horizontal scrolling or truncation.
Stripping ECG measurements on mobile
On desktop, the event detail view shows ECG strips with full clinical data and the ability to take measurements directly on the trace. On mobile, we had to choose.
An ECG trace needs horizontal space to be clinically readable. Measurement tools require precision that a touch screen can't reliably provide. And the physician on mobile is checking an alert — not doing a full analysis.
We removed the measurement capability entirely on mobile and made the ECG strip scrollable horizontally. The clinical metrics (QT, QTcB, QRS) remained as pre-computed values. If they need to measure, they open it on desktop.
Solution Overview
Event List — The physician's daily command centre. Events pre-sorted into Important and Secondary based on the patient's clinical indication.
Patient Profile — A longitudinal view of a single patient. Heart rate trend over time with Important and Secondary events plotted as dots on the curve, enrollment status, clinical information, and a chronological event list.
Event Detail — The clinical deep-dive. Patient demographics, the specific finding with its source, full clinical metrics, the raw ECG trace, a comment field, and the ability to reclassify the AI's finding. The "Mark as reviewed" action closes the loop.
Outcomes & Reflection
The product went from concept to live beta in under six months. Several US clinics used it with real patients.
The beta remained a beta. Scaling beyond the pilot required regulatory and business authorisations that were still in progress when I left the project.
What I'd do differently: we bridged the gap from data capture (patient records ECG) to information delivery (physician reviews events). But we never solved the communication layer between the two. Patients enrolled in remote monitoring want reassurance. Physicians don't want an inbox full of patient messages on top of their clinical workload.
This tension between patient anxiety and physician bandwidth is the hardest design problem in remote monitoring, and we sidestepped it. Designing that communication layer — asynchronous, structured, and low-burden for physicians while still reassuring for patients — would be the next critical piece.