eHealthier
Risk flagging & escalation
Patient surveys picked up high-risk lifestyle and mental-health factors linked to long-term disease. I designed the logic that decides what happens next, and the interface around it: either the clinician is alerted, or the system sends a follow-up survey to diagnose the flag first.
- Outcome
- Urgent patients surfaced to clinicians while follow-up surveys handled the rest; piloted across four clinics, where clinicians saw patients take interest in areas of their health they hadn’t considered.
- Role
- UX Designer & Researcher: escalation logic, clinician interface and patient-facing risk messages
- Team
- Validated with psychometricians, researchers and doctors; built with eHealthier’s CTO and senior full-stack developer
- Timeline
- One month of design, then a one-month pilot
- Methods
- Expert interviews · trials of logic variants · remote research · clinic pilot · clinician follow-up interviews
- Deliverables
- Escalation business rules · clinician alert interface · patient-facing risk messages · pilot findings
- Skills
How a flag escalates
- Patient completes an ePROMExercise, sleep, food, mental health
- High-risk factor flaggedLinked to long-term disease risk
- Severity checked
-
- Clinician alertedCall the patient in
- Urgent patient surfaced
- Follow-up ePROM auto-assignedDiagnose the flag first
- Clinician time saved
The problem
eHealthier’s ePROMs (short patient surveys) could pick up risk factors such as poor sleep, low exercise, diet and mental-health concerns. Each of these is linked to long-term disease risk. But a flag on its own creates work: if every flag lands on a clinician’s desk, the urgent ones get lost and clinicians drown in alerts. And if a patient sees a risk factor presented badly, it alarms them rather than helping.
Two questions shaped the work: which flags need a clinician now, and how should a risk factor be shown to a patient so it motivates rather than alarms?
Research
I interviewed psychometricians, researchers and doctors, then trialled variants of the escalation logic with them. Each variant was judged on two things: academic validity (does the flag mean what we say it means?) and real-world usefulness (would a clinician act on it?). The research ran remotely.
Analysis
The escalation rules, in plain language:
| Severity | What happens | Who acts |
|---|---|---|
| Higher severity | The clinician is alerted to call the patient in. | Clinician |
| Lower severity | A follow-up ePROM is assigned automatically to diagnose the flag first. The clinician can see a follow-up is under way. | The system first; the clinician can see it |
What I designed
- Escalation logic. Depending on severity, a flag either alerts the clinician to call the patient in, or automatically assigns a follow-up ePROM that diagnoses the flag first. That saves clinician time and makes urgent patients stand out.
- The clinician interface for flags and alerts: flagged patients listed by severity, each showing which risk factor was flagged and whether a follow-up survey is already under way, so clinicians can see at a glance who needs a call.
- Patient-facing risk messages that show a risk factor in a way that motivates rather than alarms.
Pilot
We piloted the system across four podiatry clinics in Canberra. Surveys were issued in the waiting room and sent to each clinic’s wider patient base.
- pilot
- 1 month
- podiatry clinics
- 4
- clinicians
- 8
- patients
- Several hundred
In follow-up interviews, clinicians reported that patients showed more interest in areas of their health they hadn’t considered before.
Reflection
A flag is only useful if the people receiving it trust it, so validating the logic with experts mattered as much as designing the interface. The same pattern applies to any alerting system: decide what deserves a person’s attention, and automate the checks that come before it.