Redesigning Firmware Updates for Hospital Infusion Pumps
Context
Infusion pumps are critical medical devices used around the clock in hospitals. Keeping their firmware current is not optional: it's a patient safety and cybersecurity requirement. Outdated firmware leaves known vulnerabilities unpatched in a networked clinical environment. But the existing update process was manual, time-consuming, and disruptive to clinical operations.
Biomedical engineers had to physically connect each pump to a laptop via cable and update them one at a time in a dedicated room. Nurses were responsible for transporting pumps to and from that room: pulling them away from patient care to manage equipment logistics. With hundreds of pumps in a hospital fleet, the result was a shrinking pool of available devices, operational bottlenecks, and real risk that demand would outpace supply.
The solution was to deploy firmware over the hospital network: eliminating the manual cord-and-laptop process entirely. My role was to ensure the new software workflows, both the deployment interface used by biomeds and the update acceptance flow on the pump itself, were intuitive, error-resistant, and validated for FDA clearance.
The Human Problem
Biomedical engineers were spending significant time on manual, repetitive firmware updates: one pump, one cable, one room at a time. Nurses were pulled from patient care to transport equipment. Every pump being updated was a pump unavailable for patient use.
The stakes were concrete: if too many patients required infusion pumps simultaneously, the manual update bottleneck could mean not enough pumps in commission. The solution needed to reduce manual burden without introducing new opportunities for use error in a high-stakes clinical environment.
Formative Research
Phase 1: Task Analysis & Gap Identification
Before any redesign work, I mapped the existing firmware update task flow end-to-end: both for the biomedical engineer managing deployment from the software side and for the interaction on the pump itself.
This analysis surfaced the gaps: where the current UI didn't support the new over-the-network workflow, where steps were ambiguous, and where the system would fail to communicate critical status information to users managing a large fleet.
I translated these gaps into prioritized UI recommendations, which became the foundation for the redesign.
Phase 2: Heuristic Evaluation
With a proposed UI in hand, I conducted a heuristic evaluation of both interfaces (the deployment software and the pump-side update flow) against established human factors and usability principles.
This identified issues with feedback clarity, error recovery, and status visibility before any user testing, reducing the cost of iteration.
Phase 3: Formative Usability Study + Information Architecture Research
We brought in biomedical engineers from real hospital environments for formative usability sessions. Alongside task-based usability evaluation, we investigated how biomeds conceptually model their work: how they identify, organize, and track infusion pumps across a hospital floor.
Key findings that directly changed the design:
Pump identification: Biomeds had developed a natural workaround: they used the last 3 digits of a pump's ID number as their shorthand identifier. The redesign incorporated sortable ID columns to match this mental model.
Fleet visibility: Biomeds needed to see pump status at a glance across a care unit, not drill into individual devices. The deployment page was restructured to surface care unit first, then device status, firmware deployment status, and ID: in the order biomeds actually needed to process information.
Status clarity: Color coding was added for deployment status, paired with text descriptions for accessibility and unambiguous interpretation under clinical conditions.
Validation
Phase 4: Human Factors Validation Study
This (hopefully) final study was designed to demonstrate to the FDA that risk had been reduced as far as possible for the following critical tasks: deploying the firmware package to the infusion pump, activating the firmware in maintenance mode, and resolving alarm states. Both tasks were classified as critical because failure in either — whether the package fails to deploy or the activation step is missed — results in the pump continuing to run on outdated firmware, leaving known cybersecurity vulnerabilities unpatched. The study was required to show that real users, under realistic conditions, could complete these tasks safely and reliably with the redesigned interface.
Participants: 15 biomedical engineers recruited from different hospitals, with varying years of experience. Participants were required to be directly involved in firmware updates: shift managers who don't perform updates directly were excluded. One participant who did not meet criteria was identified during the study; their data was excluded and this was documented transparently in the report.
Training: Participants received training from a certified biomedical trainer, followed by a one-hour training decay period to simulate real-world conditions.
Activities:
Use Scenario 1: "You've received a firmware package and must update the following infusion pumps [specific IDs]. Please proceed and let me know when the update is complete."
Use Scenario 2: Resolving alarm states.
Knowledge questions to assess understanding of the device and workflow that are difficult to observe in the use scenarios.
Root causing any observed use errors and incorrect responses to knowledge questions, which I only did after all activities were completed to avoid biasing the participant towards the correct answer.
Critical Use Error:
During validation, a critical use error emerged in the final activation step. The correct workflow required biomeds to: (1) verify the firmware package arrived successfully in standard mode, then (2) switch to maintenance mode to complete the activation. Participants correctly completed step one: they checked the nurse-facing standard interface, confirmed the package was present in settings, and concluded the update was done. They never switched to maintenance mode.
The UI provided no bridge between these two steps. There was no prompt telling biomeds that package confirmation was not the same as activation, and that maintenance mode was still required. In a clinical environment, this carries real consequences: pumps left on outdated firmware expose the hospital to unpatched cybersecurity vulnerabilities.
Root cause: The UI did not prompt users to transition from standard mode to maintenance mode after confirming package delivery. The absence of a bridging cue allowed a reasonable but incorrect mental model to persist: package arrived equals update complete.
Resolution: Working with the UX designer and engineering team, we added a prompt at the exact point of failure: when a biomed views the firmware package in settings, the UI now displays "Go to maintenance mode to finish the update." This directly addressed the gap between confirmation and activation.
Supplemental Validation Study: We reran the study with the updated interface. The critical use error did not recur. The study cleared!
Impact
FDA cleared April 2025: the updated firmware deployment workflow was approved for market.
Critical use error identified, root caused, and resolved before submission through rigorous validation and supplemental testing.
Biomedical engineer workflows directly shaped the design: column order, sorting logic, and status visibility were all grounded in how biomeds actually identify and manage their pump fleet.
Reduced manual burden: the over-the-network deployment model eliminated the need for cord-based, one-at-a-time updates, reducing operational disruption and freeing nurses from equipment transport responsibilities.
Learnings I’ll take with me
What was hard: The validation study surfaced a critical use error late in the process. The pressure to move quickly toward submission was real: but the right call was to root cause it properly, fix it, and revalidate. Cutting corners on a use error with patient safety implications wasn't an option.
What I learned: In high-stakes clinical environments, confirming that a step succeeded is not the same as completing the process: but if the UI doesn't make the next required step explicit, users will reasonably stop where the feedback stops. The gap between "package confirmed" and "update activated" was invisible until we watched real biomeds navigate it. That's exactly what validation studies are for.
Next: This project demonstrated the value of embedding human factors research early and continuously throughout development. The research-to-design loop (task analysis, formative study, heuristic evaluation, validation) is directly transferable to complex consumer health and enterprise product contexts.