Designer, Remote Patient Monitoring

Who Needs Me First

042014–2016

TELUS Health’s remote-patient-monitoring dashboard — the screen a nurse opened each morning to see, across their whole panel, who was getting worse and who needed them first. I was the designer: from the nurse’s own questions and a hand-drawn vocabulary for the body’s signals, through the add-patient and first-time-login flows, to how a week of readings should be read at a glance. A design decision here carried life-safety consequences, and clinicians reviewed every one.

TELUS Health builds the software Canadian clinicians use to monitor patients between visits. I was the designer on its remote-patient-monitoring (RPM) surface: the Clinical Dashboard nurses used to track recently discharged and chronically ill patients, and the flows that put a patient on the panel and a tablet in their hands. The work ran 2014–2016, and what shipped is the screen clinicians read each morning.

The product team was not a typical software team. The product managers were nurses who had practised clinically before moving into product. We held weekly co-design workshops, and every threshold setting, every alert, every symptom-entry path was reviewed by clinicians before it shipped — not as a final check, but as an embedded part of the design loop.

So the dashboard did not begin as a layout. It began with the nurse’s own questions — who needs me first, who has been getting worse — and a hand-drawn visual vocabulary for the body’s signals: weight, blood pressure, pulse, oxygen, glucose. Then a deliberately wide search for the form, including shapes that were never built, before a triage table won.

A nurse opened it and saw, for every patient on her panel, vital readings, reported symptoms, alert status, and lifecycle stage in one view — alerts tiered by severity, red for high, orange for medium, yellow for low. Around that screen sat the rest of the problem: matching the right patient to the right clinician at first login, and the human chain that put a monitoring device in an elderly patient’s home. The captions show the work — the questions first, the form searched wide, then the pixels.

I — The Clinical Dashboard

The dashboard did not begin as a layout. It began with the nurse’s own questions — who needs me first, who has been getting worse — and a hand-drawn vocabulary for the body’s signals. Then a deliberately wide search for the form, including shapes that were never built.

A hand-drawn page titled “Nurse’s Concerns” listing the questions a nurse asks and the four things she must pay attention to. — fig. 1 — 2014, before the screen — the nurse’s own questions (left), and a hand-drawn visual vocabulary for the body’s signals (right): the questions the dashboard had to answer, and the language it would answer in.

A hand-drawn “Visual Vocabulary” page with icons for weight, blood pressure, pulse, oxygen level, and glucose level grouped as biometrics. — fig. 1 — 2014, before the screen — the nurse’s own questions (left), and a hand-drawn visual vocabulary for the body’s signals (right): the questions the dashboard had to answer, and the language it would answer in.

A hand-drawn radial dashboard concept plotting patients around a circle by biometric and alert level. — fig. 2 — 2014, the form, searched wide — a radial layout plotting every patient by biometric and alert level, one of several shapes explored before the triage table won.

A more developed hand-drawn radial dashboard concept, patients arranged on concentric time rings around a clock face, with a legend for validated and unvalidated readings. — fig. 3 — 2014, the radial pushed further — patients on concentric time rings, a legend separating validated from unvalidated readings and biometric from answer alerts. Another shape tried before the table won.

A hand-drawn patient-table dashboard with biometric column headers, alert-priority count tabs, and one row expanded to show a trend chart. — fig. 4 — 2014, the concept that converged — a patient table with the biometric vocabulary as columns, triage counts across the top, and a row drilled open to its trend. The shipped dashboard, worked out on paper.

A hand-drawn single dashboard table row with column headers Wt, BP/P, O2 sat and a patient cell, titled “indication of no readings”. — fig. 5 — 2014, one row of the dashboard, worked out by hand — the patient cell, alert icons, and the vital columns (Wt, BP/P, O₂ sat), including how to show a missing reading. The shipped row, line for line.

A hand-drawn pair of patient cards labelled Normal and Alert, the alert card half-filled solid black. — fig. 6 — 2015, the patient as a single card — its normal and alert states (left), and the panel as a wall of cards with one pulled forward (right). A direction explored and set aside; the triage row won.

A hand-drawn grid of sixteen patient cards, one card filled in solid to show the selected state. — fig. 6 — 2015, the patient as a single card — its normal and alert states (left), and the panel as a wall of cards with one pulled forward (right). A direction explored and set aside; the triage row won.

A hand-drawn wireframe of a “My Patients” filter — a dropdown listing My Primary Patients, My Patients, and patients of named colleagues, with annotations. — fig. 7 — 2016, whose patients — a proposal to scope the panel to my primary patients, all my patients, or a colleague’s, so a clinician covering a shift would see the right list. Designed to spec; not shipped.

A nurse opened the dashboard in the morning and saw, for every patient on her panel, vital readings, reported symptoms, alert status, and lifecycle stage in one view. Alerts were tiered by severity: red for high, orange for medium, yellow for low. She could drill into a row to read the longitudinal data — a week of readings against the threshold, her own annotations inscribed back into the timeline.

A patient row’s vital popover showing an on-demand reading flagged in red beside earlier values. — fig. 8 — 2015, a vital drilled in from the patient row — an on-demand reading flagged against its threshold, the history beside it.

The dashboard with a tooltip reading ‘Monitoring plan suspended’ and a date range. — fig. 9 — 2015, patient lifecycle made visible — a suspended monitoring plan, dated in place, so a covering clinician reads the state at a glance.

The dashboard legend, keying the alert and result colour codes. — fig. 10 — 2015, the alert taxonomy behind the colours — current, previous, and recently validated alerts, and results marked as annotation or as error.

II — Onboarding & First-Time Login

Two onboarding problems sat around the dashboard. The nurse created the patient’s account and added them to her panel herself — the right patient assigned to the right clinician, with the safeguards a monitoring program demands. The patient then had to log in on a tablet for the first time, at home, alone — receiving the credentials the nurse had set up, and turning them into their own PIN.

A hand-drawn six-step Add Patient flow across mobile screens, numbered Search, Review, Assign. — fig. 11 — 2015, the Add-Patient flow, worked out screen by screen — search, review, assign — the six steps that put a patient on a clinician’s panel.

A hand-drawn first-time patient login flow — create a PIN, confirm, and a “used?” decision branch, ending with “create your own PIN”. — fig. 12 — 2016, first-time patient login, designed for the kitchen table — an elderly patient creating their own PIN on a tablet, the confirm-and-reuse path drawn out so the step never traps them.

A hand-drawn flow mapping patient, tablet, clinical station, and clinician, with sticky notes reading “Alert if…” and “Rejected if…” enumerating the matching conditions. — fig. 13 — 2016, the matching rules, enumerated — tablet ID, patient, security question, and timestamp checked against each other, with the alert and rejection conditions spelled out as condition-to-outcome rules.

III — Reading the Results

Two questions sat at the end of the loop: how a week of a patient’s readings should be read — as a table of numbers, or as a graph — and how the monitoring device got into the home in the first place, which took a chain of people, not a screen.

A hand-drawn comparison of two ways to show previous blood-pressure results — a dated table on the left, a trend graph on the right. — fig. 14 — 2016, table or graph — the same week of blood-pressure readings shown both ways, to decide which a clinician reads faster between visits.

A hand-drawn service-design diagram of the equipment-installation collaboration flow, mapping the people and steps that get a monitoring device set up in a patient’s home. — fig. 15 — 2016, the system around the screen — the equipment-installation collaboration flow, mapping every hand-off from order to a working device in the patient’s home. The dashboard only worked if this did.