There are many different levels of software quality related crises in the IT world. There are those that are a mere inconvenience, like when Twitter, Facebook or Gmail go down. There are those that pose a significant business difficulty, like when a number of financial organizations faced outages recently. In the medical industry, however, software quality failures go beyond inconvenience and difficulty; they result in life and death consequences!
Medical News Today last week reported that 39 recalls of medical devices last year, and 500 recalls of devices over the last seven years, were a direct result of software defects and malfunctions. The number seems to pale in comparison to the Institute of Medicine’s findings earlier in the decade of 94,000 cases where patients were harmed due to medical errors. However, each of those recalled devices represents the possibility of multiple adverse medical encounters that could have – or perhaps did – result in harm or death to patients.
Examining the Requirements
In October, Espicom Healthcare Intelligence reported that the Medical Device market in the United States had grown to $94.9 billion, making this the largest medical device market in the world; it is also one that is highly scrutinized and regulated by the FDA. Since 1997, part of that scrutiny has been aimed at the software embedded within medical devices. In its General Principles of Software Validation, the FDA states:
Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR §820.70(i). This requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system.
So why then do nearly 10% of medical devices continue to be recalled each year as a result of software quality issues? And this doesn’t include those devices that suffer software failures on an individual basis and, therefore, are not recalled. Not to cast aspersions upon the FDA, but perhaps it’s because they profess to recommend the “least burdensome approach” for validating software quality; or as they state in their General Principles:
We believe we should consider the least burdensome approach in all areas of medical device regulation. This guidance reflects our careful review of the relevant scientific and legal requirements and what we believe is the least burdensome way for you to comply with those requirements.
Consulting on the Diagnosis
Next month the 14th Annual Software Design for Medical Devices conference will be held in San Diego. The discussion at the conference will focus around getting new technology to market while still meeting the burden of the FDA’s requirements regarding software quality – you know, the aforementioned “least burdensome approach.”
Topics slated to be discussed at the conference include:
These are all positive steps toward ensuring software quality, but they seem to neglect one important aspect – the structural quality of the software used to build and operate devices.
Since defective software in a medical device – whether it’s a heart monitor, an insulin pump, a pacemaker, et al – can have dire consequences, there should be some regulation that oversees the software going into the device. Either the device manufacturer or its software vendor should perform some form of structural quality analysis rather than just placing the burden upon the device manufacturer to test its use post-deployment. Testing isn’t enough. As Capers Jones wrote in his 2009 book, Applied Software Measurement, to which I referred in an earlier post on OnQuality, “In terms of defect removal, testing alone has never been sufficient to ensure high quality levels.”
More attention should be paid to the structural quality of application software being embedded into medical devices. This can best be done through a system of automated analysis and measurement, which can assess thousands upon thousands of lines of code as well as interfaces and other structural factors that can result in software malfunction, and which manual analysis cannot detect efficiently. If automated analysis and measurement of medical device software saves even one life, such a requirement would be worth going beyond the “least burdensome approach” because in the medical industry, software quality is a life and death issue.