In 1990, the FDA published a report, Device Recalls: A Study of Quality Problems, that revealed 44 percent of medical device recalls were due to design issues and one-third of those were due to a faulty user interface (UI). The resulting uproar led to the US swiftly passing the Safe Medical Devices Act. This regulation has been in place for over thirty years now, so surely medical UI problems are a thing of the past, right?
Unfortunately, not. A recent study found that approximately 140 medical devices a year are still being recalled due to UI problems.
Can anything be done about it? This blog reviews the top factors that cause medical UI problems and looks at specific recommendations that embedded GUI software teams can use to build next-gen medical devices that are safe and usable.
Three new forces are acting on medical software development processes, and they can interact in ways that lead to poor medical user interface design.
Competition. The competition among medical device makers is fierce – there are more than 6,500 medical device companies in the US. When there are a lot of companies chasing after the same opportunities, manufacturers naturally feel a downward pressure on time to market for development of new products. One study found that on average, a medical company felt they needed to cut their development time by 25 percent to remain competitive.
Complexity. While executives are slashing development timelines, the reality is that medical software is getting more complex and harder to create. This can be observed by the dramatic rise in the length of paperwork submitted to the FDA regarding the development of medical devices. Over a 25-year period, the page count on an average FDA filing has grown by over 600%, in turn leading to longer clearance periods as regulators try to determine approval of the device.
Attractiveness. The third pressure is the iPhone effect. Modern medical devices need an attractive, smartphone-like GUI to compete effectively. Nowhere is this more apparent than in the explosion of home healthcare, where average individuals use medical products instead of trained technicians. But attractiveness and usability are factors for clinical settings too. Our medical clients tell us that once a medical device’s functional requirements are met, significant sales to a health care network can be won or lost depending on a product’s look and feel. While sloppy interface design can lead to the erroneous dispensing of medication and even death, dated displays also impact business opportunities.
Unfortunately, faster product timelines, longer development cycles, and more sophisticated GUIs lead to product development cycles without enough time for adequate usability testing and GUI iterations.
How do we improve medical user interface designs? One big question is whether or not development teams are taking proper advantage of the existing knowledge on proper human factor engineering. There’s a lot of material out there on this; here are some of our favorite resources.
Most of these resources give some guidance but few are completely prescriptive. It’s expected that the majority of design principles are executed within the context of properly conducted usability studies. With shrinking schedules and increasing complexity, fitting even one iteration of usability testing into a development timeline, let alone several, may seem impossible. Perhaps the bigger question is, if usability testing is so crucial, how do medical teams find enough time to conduct them?
A standard development process usually has to wait until hardware design, prototyping boards, operating systems, and all other supporting components are reasonably stable before the GUI can be tested. Given shorter timeframes, it’s easy to see that this will lead to issues. Any time for GUI development, refinement, and usability testing is squeezed into the last weeks before release. That makes it significantly more likely that the pressure to ship will override the need to root out any remaining GUI deficiencies.
What is the ideal way to design a medical GUI that is both stable and intuitive? The key realization is that GUI development must start as soon as the product requirements are solidified, even if the hardware isn’t ready yet. This ensures enough time can be dedicated to working out usability kinks. If developers can discover GUI issues early, they have time to correct any problems where users misinterpret data, mistakenly enter wrong numbers, accept bad default configurations, ignore critical warnings, or are led down incorrect assumptions.
Here are the three essential GUI architectural guidelines you need to know to decouple the GUI from the rest of development:
Most experienced developers would agree that their projects should adhere to these principles, but the best laid plans often go awry. By project’s end, any lofty goals that would keep a GUI insulated from the rest of a system have been abandoned. As a way of expediting the development process, prototyping experiments become production code and business logic creeps into the GUI. These easy-to-overlook deviations occur by small amounts over time, but the end result is that the GUI becomes dependent on underlying functionality. That dependency causes the GUI to be brittle – it cannot be easily changed without breaking the product.
User interface brittleness occurs unless developers exercise extreme discipline when making software changes. At least, this is true when the GUI shares the same language and tools as the rest of the device’s functionality. In other words, if the product’s main logic and the GUI framework are both written in C++, programmers who introduce changes must decide exactly what and where each change resides since their code could conceivably go in either place. A small fix that logically belongs in the device’s underlying functionality may be easier to implement in the GUI. But once that fix is in the GUI, it’s very hard to find the time to go back and fix it properly.
However, if GUI architecture guidelines are being followed (that is, being platform agnostic, using the MVC pattern, and using an event-driven GUI), there’s no inherent benefit to having the GUI and mainstream development share the same language and framework. A key realization is that if the GUI and logic use different frameworks and languages, it will subtly pressure developers to continually reinforce the architectural guidelines that keep the GUI flexible and adaptable.
The forced separation of GUI and business logic is in fact, one of the key architectural decisions behind our Storyboard product. By strictly decoupling the GUI and the logic, prototyping and usability testing of medical equipment interface designs can occur in parallel within the main development path, even before hardware decisions are finalized. With an event-driven architecture, a consumer-grade tablet can be used to test the GUI with scripts to generate events simulating real device behavior. And changes to the user interface can be made freely without the fear of breaking device functionality. This lets medical development teams fix usability problems before they cause recalls – or worse.
Dive deeper into how embedded teams improve medical user interface design in this webinar with BlackBerry QNX, Toradex, and Crank: