EMS responders make stroke routing decisions before they can confirm what type of stroke they're treating. We built a companion app for a portable EEG cap that translates real-time brain data into a classification EMS can act on in the field.
Time Span: 4 Weeks
Category: Healthcare
Role: UX & UI Designer
CONTEXT
In the United States, strokes are the fourth leading cause of death, affecting approximately 800,000 people each year. Every untreated minute can destroy about 1.9 million neurons. The critical distinction is stroke type. Ischemic strokes are caused by clots, while hemorrhagic strokes require different treatment decisions and hospital capabilities.
EMS teams often have to make routing choices before they can access the tools needed to read brain activity. The Global Ties at UC San Diego team was building a portable dry EEG cap to capture that brain activity in the field and my role was designing the companion app that translates that data into something EMS responders can actually act on.
PROBLEM
EMS teams cannot confidently identify stroke type in the field before hospital arrival. Traditional diagnostic tools are too slow and bulky for pre-hospital use, forcing routing decisions without neurological confirmation. This leads to delayed or incorrect hospital selections, requiring secondary transfers and losing critical treatment time. In interviews with four practicing EMS responders, this uncertainty wasn't just procedural. It was emotional and persistent.
"Every time I hand off a stroke patient, there's this voice in my head: 'What if you got it wrong?'"
"When I mess up a stroke call, I'm not just failing a statistic. I'm failing a family."
By coding across workflow steps, emotional moments, and recurring workarounds, we identified three consistent gaps: BEFAST structures the assessment but not the answer; hospitals receive incomplete pre-arrival information; and patient history shapes interpretation inconsistently, with no dedicated place in current workflows.
To map where uncertainty peaks, we traced the full EMS journey from dispatch to handoff:
SOLUTION
Each screen maps to a specific moment where EMS responders lose confidence. The goal wasn't to add information; it was to surface the right information at the right step, in a form someone could act on under pressure.
Stroke Classification
What responders needed wasn't data, it was a decision. We translated EEG output into a single interpreted signal, ischemic or hemorrhagic, hiding complexity rather than exposing it. Without this layer of interpretation, a waveform in the back of an ambulance tells a responder nothing they can act on.
BE-FAST Assessment
We kept the familiar BE-FAST protocol and built the app around it. One change emerged from field testing: the "Time" field became a dedicated input rather than a checkbox, after we discovered that checkboxes captured completion but not clinical information. Last known well time is a critical factor in treatment eligibility, and it needed a field that made that clear.
Hospital Routing
Routing decisions were previously made on distance alone, without accounting for what the receiving facility was actually equipped to treat. With stroke type confirmed earlier in the flow, the app ranks nearby facilities by capability match, not just proximity. A hemorrhagic stroke and an ischemic stroke require different interventions and different hospital resources, and the interface reflects that distinction directly so responders aren't making capability judgments under pressure.
Handoff Summary
Receiving teams were preparing blind, often learning critical details only when the ambulance arrived. Symptoms, patient history, witness notes, and EEG classification are now packaged and transmitted before arrival, giving hospital teams time to prepare the right response rather than react at the door.
FIELD VALIDATION
The most significant finding came from the BE-FAST "Time" field. In the early prototype, it was a simple checkbox with no label explaining what "Time" referred to. We gave testers a patient scenario, a man with facial droop, leaning to one side, appearing dizzy, wearing a watch, and asked them to complete the checklist. When they reached "Time," they paused, then checked the box because the patient was wearing a watch.
They technically completed the checklist but captured no clinical information. BE-FAST's "Time" refers to last known well time, a critical factor in treatment eligibility, but as a checkbox it gave no indication that anything should be recorded. We replaced it with a dedicated entry field, prompting responders to record an actual time rather than make a binary decision.
When we brought the refined prototype back to responders, the reaction was noticeably different. They moved through the flow without hesitation, said it felt focused rather than overwhelming, and several noted that having the stroke classification surfaced clearly would reduce the uncertainty they currently carry into every handoff. For responders who described second-guessing themselves after every call, that kind of confidence was a change.
REFLECTION
The biggest thing this project taught me was to resist the urge to add. In most projects, more features feel like more value. Here, every decision came down to one question: does this help a responder in the next thirty seconds, or does it just add noise?
The BEFAST "time' checkbox was a prime example. It looked right, it worked fine, and it told us nothing useful. Watching a tester check the box because the patient was wearing a watch was one of those moments where you realize how easy it is to build something that feels complete but completely misses the point.
Designing the app side of a real clinical tool was something I didn't take lightly. The Global Ties team was building hardware that could change how stroke care happens in the field, and the app was what stood between that hardware and a responder who had thirty seconds to make the right call. That's a different kind of pressure than anything I'd felt on a project before, and it made me slower, more deliberate, and a lot more honest about what actually needed to be there.
If I kept going, I'd want to see what happens on the hospital end, whether receiving teams actually use the pre-arrival summary differently, and whether it changes anything about how they prepare. That's where the real impact of this tool either shows up or doesn't.
