Emily Byrne, Sr. Software Engineer, Medtronic
Following a now familiar pattern, software is increasing in importance through the medical device industry. As a regulated industry, this industry has specific requirements; as developers of life-enhancing and life-saving devices, we have moral obligations that drive us to meet and exceed those expectations on behalf of the patients and physicians who rely on our products.
The front line of software is the User Interface (UI). The UI for medical devices must not only meet user expectations and regulatory needs, but also prevent issues that could impact the therapeutic value or timely communication and response to hazardous situations. The UI also must enhance the user experience and build users’ confidence that they can rely on and feel comfortable with using the software and associated medical device.
"As Usage Models Change, User Need Collection Cannot Rely On the Assumptions and Biases Of the Past"
The software team uses Design for Six Sigma (DFSS) practices to gather user needs and stories, translated into verifiable requirements for the User Interface, develop a robust User Interface, and verify that the UI meets those verifiable requirements over the range of use conditions and cases. The software team addresses security concerns, consistent with HIPAA (Health Insurance Portability and Accountability Act) expectations in protecting the patient’s privacy while also protecting their life. With so much depending on the effectiveness of the medical device, software reliability and availability are paramount – and the confidence can be provided through probabilistic modeling.
Gathering user needs and user stories
Eric Maass, Director of Design for Reliability and Manufacturing (DRM)/DFSS for RTG, Medtronic
A thorough understanding of the user needs and stories is not only essential to good product design, but critical for designing safe and effective medical devices. The trend toward more actionable data and seamless integration into the patient’s daily life has affected how patients and physicians expect to interact with the devices they work with. The User Interface must account for this shift and anticipate both use and misuse.
As usage models change, user need collection cannot rely on the assumptions and biases of the past. Observational threads from customer interviews – in which facilitators can capture both the stated and unstated needs of the user base with empathy and without bias – can inform deeper, more quantitative lines of inquiry like conjoint analysis. The resulting collection of user needs and stories can then be synthesized with the therapy, technology, and regulatory voices, creating a clear and comprehensive picture of what the requirements are for the user-facing subsystems of the medical device.
Developing a robust User Interface (UI)
By letting patient comfort drive User Interface requirements, you build user confidence and prevent foreseeable misuse; by integrating technological considerations as the product is architected, you can design for reliability, robustness, and obsolescence. Consider the lifecycle of a medical device – software, and the hardware it relies upon, are subjected to a variety of stressors throughout each phase. Compiling a comprehensive set of use conditions and assessing how they impact the software and the device from the design phase to product retirement can identify potential points of stress, during which the device may operate sub-optimally or not be available to perform its intended function. By knowing these stress points upfront, protections or reactions can be designed into the product and the UI can convey appropriate information to the patient or physician. A robust User Interface that anticipates environmental and operating conditions protects the patient and preserves trust by handling these hazards with grace. A mistake proofing process for software is shown in Figure 1.
Figure 1: Mistake Proofing for Software
Addressing security concerns
If the ideal UI is designed for easy use, difficult misuse, and nearly impossible abuse, how does the design team gain confidence in meeting this ideal? One approach is to define this ideal as the success criteria, and model the probability of success using a Bayesian Belief Network (BBN). Bayesian methods have a proud history with Computer Science, dating back to World War II and the use of Markov Chain Monte Carlo Simulation on ENIAC with the Manhattan Project, and the breaking of the ENIGMA code by Alan Turing’s team in England using Bayesian methods. Bayesian methods use chains of conditional probabilities to predict the probability of desirable and undesirable events, and can also drive backwards, diagnostically, to show what needs to be improved.
Modeling SW Reliability / Availability
Bayesian methods can also be effectively applied to modelling Software Reliability and Availability. BBN’s can be used to model Software Reliability related to the probability of a software defect impacting the interaction of a user with the UI.
Software reliability and availability, as well as security, can be modelled and optimized using BBN’s to model the probability of success in having a robust User Interface, and to predict and then verify that the UI meets user needs as reflected in requirements over the range of use conditions and cases.
By leveraging DFSS best practices and quantitative methodologies for designing a robust UI and modelling reliability, security, availability, and other “-ilities”, medical device software can meet and exceed patient, physician, and regulatory expectations.
Headquartered in Minneapolis, MN, Medtronic strives to alleviate pain, restore health, and extend life for millions of people around the world. Founded in 1949, the firm contributes to human welfare by applying biomedical engineering in research, design, manufacture, and sale of instruments or appliances.