2006). During this period, 11.3% of all recalls were attributable to software failures. This recall rate is nearly double compared to the period of 1983–1997 where only 6% of recalls were attributable to computer software (Wallace and Kuhn, 2001). For pacemakers and implantable cardioverter–defibrillators, the number of devices recalled due to software abnormalities more than doubled compared with 1991–2000 (Maisel et al., 2002). In 2006, Faris noted the milestone that over half the medical devices on the US market now involve software (Faris, 2006).
Yet, despite the lessons learned by tragic accidents, such as the radiation injuries and deaths caused by the Therac-25 linear accelerator over 20 years ago (Leveson and Turner, 1993), medical devices that depend on software continue to injure or kill patients in preventable ways. Problems in medical device software result largely from a failure to apply well-known systems engineering techniques, especially during specification of requirements and analysis of human factors.
“The ability of software to implement complex functionality that cannot be implemented at reasonable cost in hardware makes new kinds of medical devices possible…” (NRC, 2007).
Software can significantly affect patient safety in both positive and negative ways. Software helps to automatically detect dangerous glucose levels that could be fatal for a person using an insulin pump to treat diabetes. Medical linear accelerators use software to more precisely target the radiation dose. Remote monitoring of implanted devices may help to more quickly discover malfunctions and may lead to longer survival of patients (Kolata, 2010). However, medical device software contributes to the injury or death of patients. Problems ranging from poor user interfaces to overconfidence in software have led to accidents such as fatally incorrect dosages on infusion pumps (FDA, 2004a, 2010; Meier, 2010) and in radiation therapy (Leveson and Turner, 1993; Bogdanich, 2010b). A common trait for adverse events in medical device software is that the problems are often set in place before any implementation begins (see Table D-1).
In the context of software, trustworthiness is inextricably linked with safety and effectiveness. There are several definitions of trustworthy software (see Sidebar 1) that vary by the specific contributions and terminology of various research subdisciplines. However, the fundamental idea is that software trustworthiness is a system property measuring how well a software system meets requirements such that stakeholders will trust in the