TL;DR
What: Designed Relay, a concern routing system for dialysis clinics. Captures patient concerns at bedside in under 10 seconds, routes them to the right clinician, and tracks each one to resolution.
THE CLINIC'S STARTING PROBLEM
Upto 60% patient concerns disappear during dialysis sessions.
A patient mentions leg cramps during their session. Here's what happens next.
Patient Care Technician
Hears the concern. But can't make clinical decisions, and is pulled to another chair.
Registered Nurse
Could assess it. But wasn't there when the patient spoke. Never receives it.
Medical Doctor
Could act on it. But only
sees what gets escalated. Never knows.
The problem isn’t recording concerns, it’s routing them.
They’re captured, but don’t reach the person who can resolve them.
WHY THIS IS HARD TO FIX
Concerns surface in seconds, but resolution requires coordination across roles.
Three insights that make this a design problem.
The capture window is 10 seconds.
Technicians are moving constantly. If it’s not logged immediately, it’s gone.
Authority is split across three roles.
Technicians hear concerns, nurses assess, doctors decide. Routing + clear ownership is the real problem.
Concerns have different urgency, but look the same at capture.
The first person logging it can’t clinically judge it. Triage happens at the next role.
THE DESIGN CHALLENGE
How might we design a reliable path between a patient voicing a concern and the clinic acting on it?
The person who hears it can’t triage it. The person who can triage it may not be there. The person who can act on it only sees what gets escalated. The system has to connect all three, without adding burden to any of them.
CONSTRAINTS TO PRINCIPLES
Each constraint became a design principle.
01 Capture before it's forgotten
Insight: PCTs are moving between patients. Capture needs to be fast.
02 Ownership by assignment
Insight: Without explicit assignment, tasks fall between roles.
03 Time Bound Responses
Insight: Delays impact patient trust. Response time is crucial.
04 Context survives handoffs
Insight: Handoffs lose 30% of context. History must travel with the concern.
MY DESIGN PROCESS
Designing for Clinic's Ground Reality, with AI
My AI-Augmented Design process has its roots in the classic double diamond. I front-loaded the process around understanding the clinic roles & context, and used AI to go deeper.
EXPLORATIONS
Three directions rejected. One tradeoff accepted.
I explored three approaches, each solved part of the problem but failed on the rest. Relay came out to be the winner with two tradeoffs: complex build & EMR (electronic medical records) integration.
THE SOLUTION
Relay: A concern routing system that guarantees every patient concern is captured, owned, and resolved.
Concerns need a trajectory not better documentation. Relay moves a concern from the moment a patient speaks, through triage and treatment, to documented closure.
01 CAPTURE
This screen exists to move words from memory into the system fast.
See AI Explorations
02 CLASSIFY
Three levels of concerns: comfort, non-urgent clinical, urgent to keep classification fast.
See AI Explorations
The nurse makes a clinical judgment. The system handles routing, ownership, notifications, and deadlines.
| Design Decision: This avoids two common failures: over-documenting simple issues and vague escalation when urgency is real.
03 ESCALATE (NURSE TO DOCTOR)
Doctors aren't at the bedside. They need context fast. The nurse's note enables a decision. If they can't act, ownership transfers automatically, no concern gets stuck.
Both see the same patient. Both stay in sync.
During an emergency, the nurse's hands are busy. A single status selector (Stabilizing → Responding → Not Responding → Stable) takes one tap. The doctor sees it instantly.
04 CLOSE
→ Doctor sees the nurse's note upfront
→ Can request more info before accepting
→ Approves the request & closes the concern
In nephrology clinics, nurses can't independently close high-severity concerns, it's a regulatory and liability requirement. But we don't want concerns floating by. The nurse does the documentation work, the doctor just reviews and approves. This creates accountability & quick resolution.
DOCTOR FEEDBACK
"The tool must reduce mental load in the moment and feel “native” to clinic workflow, not like extra admin"
Demo: I got the chance to present my solution to Kelly Chen, Nephrology Clinic Practitioner Stanford Health Care in a meeting of 80 cohort members. This is the feedback I received.
PRE-VALIDATION
Simulated walkthroughs before real clinic testing.
I used a synthetic research process to pre-validate the concept to reduce risk before a live pilot.
01- Walked 6 scenarios through 4 roles
Each scenario imposed a real constraint: peak-hour capture, escalation with the RN absent, ambiguous symptom urgency, shift-change handoff, reassignments, and recurrent concerns.
02- The workflow kept breaking in the same place
The decision tree outlines the actions each person needs to do. But across multiple scenarios, one role had no way to see whether any of it was actually happening.
03- The charge nurse was accountable, but blind
She manages the floor, reassigns staff, and triages priorities. But she had no view of which concerns were captured, which were stuck in escalation, and which were missed entirely.
Charge Nurse (CN)
| Owns the floor, but can't see what's happening on it
Knows staffing levels, shift timeline, escalation status
Acts in the full 8-hour shift window
Can't assess patients or be at every station
04- That gap became the dashboard
The charge nurse needed a real-time view of what was happening across her floor, concern status, ownership, documentation gaps, and escalation state at every station.
PROJECTED IMPACT
These outcomes guided every design decision and would be the first metrics I'd track in a pilot.
If concerns aren't captured, nothing
else matters.
Captured but unowned = still lost.
This closes the accountability gap.
Owned but delayed = trust erodes. Response time matters.
Concerns span shifts.
Concern history needs to travel.
REFLECTIONS
Failures & Learnings from Designing for Healthcare
Principles I've added to my toolkit:
Designing for reliability is different from designing for the ideal behaviour.
AI is most valuable when it reduces friction not for making decisions.