Where Use Error Hides in High Pressure Clinical Workflows

Medrad

When something goes wrong with a medical device, the first explanation is usually the same. The nurse pressed the wrong button. The technologist skipped a step. The clinician misread the screen.

It is almost never the real story.

The FDA draws a careful distinction here, and it is worth understanding. User error implies the person made a mistake. Use error means the interaction failed. The person did what the design invited them to do, and the design invited the wrong thing. After decades of designing user workflows and interfaces for companies like Edwards Lifesciences, Medrad, Baxter, and J&J we have learned that the second explanation is right far more often than the first.

And the difference changes what you do next. If you believe the problem is the user, you retrain and move on. If you understand the problem is the interaction, you can actually fix it. To fix it, you have to know where use error hides. Because it does hide. It rarely shows up in the demo, the conference room, or the first usability session. It shows up in a handful of predictable places.

Time pressure. In CT imaging, contrast media must be delivered with precise timing during a scan that cannot be paused. When we designed the touchscreen interface for Medrad’s Arterion injection system, the defining constraint was not screen layout. It was that the technologist has a narrow window to confirm dose and timing while the scanner runs and the patient waits. Under that kind of pressure, people do not read. They recognize. An interface that requires reading during a critical task has already failed, no matter how clear the text is.

Focus on Patients, Not the Machine. During open heart surgery, the perfusionist operates the heart lung machine that temporarily takes over the work of the patient’s heart and lungs. When we designed the interface for COBE Cardiovascular’s perfusion system, we learned that this environment has no small tasks. The perfusionist manages blood flow, pressure, temperature, and gas exchange continuously for hours, adjusting in response to the surgical team while the patient’s life depends on each value being right. A display that buries a critical parameter, or a control that behaves differently than the one beside it, adds risk in a setting where there is no margin to absorb it. The interface has one job: keep the perfusionist’s attention on the patient’s vitals, never on the machine.

Interruptions. A nurse begins programming an infusion and gets pulled away by an alarm two beds over. Three minutes later she returns. Does the screen show her where she left off, or does it look the same whether the sequence is half finished or complete? Interfaces must be designed to show users exactly where they left off, because hospital work is interrupted work.

Shift handoffs. The day technologist knows the workaround. The night technologist inherits the settings without the context. Use error concentrates at the seams between people, when assumptions travel with the device but knowledge does not.

Alarm fatigue. When everything alerts, nothing alerts. In the cardiac ICU, where we designed the interface for Edwards’ HemoSphere monitoring platform, the question was never how to add alarms. It was how to build a visual hierarchy that lets a clinician separate a trend worth watching from a condition that needs immediate intervention. No one on that unit is being careless when the tenth alert of the hour gets less attention than the first. Attention wears down when everything demands it, and the design has to account for that.

The environment itself. Gloved hands on a touchscreen. Glare from surgical lighting. A dim room during imaging. A device operated from an angle because that is where the cart fits. None of this appears in a spec sheet, and all of it changes what a usable interface means.

Here is the uncomfortable part for device teams: you cannot find these failure points by asking.

Experienced clinicians, nurses, and technologists compensate silently. They develop workarounds in the first month and stop noticing them by the third. Ask a veteran CT technologist where the interface slows her down and she will often say it does not. Watch her for an hour and you will see her pause at the same screen every time, tap a field twice because the first tap sometimes does not register, and keep a laminated card taped to the cart with the sequence the interface should have made obvious. She is not hiding anything. Expertise makes friction invisible to the person experiencing it.

This is why professional observation, not interviews or workshops alone, is the foundation of research in regulated environments. But observation by itself is not enough either. Anyone can stand in a room and watch. A trained observer knows what to look for: the hesitation before a critical task, the workaround taped to the machine, the same question asked twice per shift, the flicker of doubt that crosses a face before a confirmation button gets pressed. And in fast moving clinical work, even a trained eye cannot catch everything in real time. We often record sessions and go back through the video afterward, coding workflows, workarounds, and facial and body gestures to find the gaps between how the task is supposed to happen and how it actually happens. Those gaps are where use error lives, and users are the last ones who can point them out to you.

Every interface performs well in a demo. The room is calm, the data is clean, and the person driving knows the happy path.

Clinical reality is the opposite. The meaningful test of a medical interface is the worst five minutes: the deteriorating patient, the interrupted task, the new nurse on her second shift, the alarm that fires during a handoff. Design for those five minutes and the demo takes care of itself. Design for the demo, and those worst five minutes show up later as complaints, adverse event reports, and recalls.

Practically, this means critical tasks come first and features come second. It means formative evaluation early enough to change the design, not late enough to merely document it. Teams that treat formative work as a rehearsal for Summative validation catch use errors when fixing them costs a design sprint. Teams that skip ahead find the same errors after submission, when fixing them costs far more.

If you are building or updating a medical device interface, ask:

  1. Can a user tell, at a glance, whether a critical task is complete, half done, or not started?
  2. What happens when the person operating the device is interrupted at the worst possible moment?
  3. Have you watched real users in their actual environment, or have you only heard what they remember about it? And did those observations actually translate into the design?
  4. If you have watched them, did you capture it? Experienced users move fast, and their shortcuts and workarounds slip past live observation. Video analysis of their workflows, gestures, and expressions is often the only way to run a real gap analysis between the intended workflow and the one that actually happens. This does not require months of study. A focused video analysis often takes days.

If any answer is uncertain, that is probably where your use error is hiding, and it is far less expensive to find it now than after submission.


Posted in