The life of a hospital patient can fully rely on the machine which is keeping their heart beating, their blood pressure normal and breathing steady. Embedded devices like mechanical hearts as well as bedside assist equipment and treatment facilities such as radiation therapy are all run by the software embedded in the devices. But as medical equipment becomes more software based, even the smallest technical glitches can have disastrous consequences.
In 1996, after Europe’s Ariane 5 rocket blew up, scientists ran programmes called static analysers to discover that the problem was a micro processing bug. Now, the same technology is being used to prevent the needless deaths of hospital patients. Instead of reformatting from avionics, to the automotive industry and then to cardiac assist or blood transfusion equipment, the same coding standards can be applied across the board.
Go deeper with GlobalData
There have been a number of recent software-related recalls of medical devices, including St Jude Medical’s Merlin PCS/Identity Pacemakers, Baxter’s Colleague infusion pump and Difibtech’s AED.
A recent study carried out by the University of Patras, Greece – based on data gathered by the US FDA – showed one in every three medical devices using software for operation had been recalled due to failure in the software itself. In percentage terms, 11.3% of total FDA recalls are attributable to software failures.
“Companies in the medical industry, perhaps more than any other, are increasingly concentrated on the software aspect of their products,” says Fergus Bolger, CTO of Programming Research, a supplier of C and C++ code analysis and standards compliance tools to medical device, automotive, aerospace and many other embedded software industries. “Of course you can get mechanical failures but these days you are just as likely to get software-based failures.”
See Also:
Now the solution is not only being promoted as a useful tool in the investigator’s armoury when things go wrong, but can be used as a preventative measure to ensure the safety of medical equipment before it hits the wards. “No amount of testing can completely eradicate all possible software failures,” says Bolger. “It made it necessary for all medical device vendors to show that they have taken all due care in ensuring that their products meet industry best practice.”
How well do you really know your competitors?
Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.
Thank you!
Your download email will arrive shortly
Not ready to buy yet? Download a free sample
We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form
By GlobalDataStatic analysis can detect malfunctions such as runtime errors, buffer overruns, null pointer dereferences, race conditions, resource or memory leaks and dangerous casts.
It works by mimicking the execution of the machine whereby concrete values are replaced by abstract symbols, the programme is run and then facts can be found about the variables and how they relate to each other.
Fatal errors
A classic case study heralds the use of static analysis. Between 1985 and 1987 the Therac-25 radiation therapy machine – produced by Atomic Energy of Canada Limited and CGR MeV of France – gave six patients massive overdoses of radiation, killing three. The six patients were subjected to approximately 100 times the intended dose because Therac-25’s combination of software and hardware had not been tested before hitting the wards and contained a fatal error.
The operators of Therac-25 had never had the machine independently reviewed and therefore had not found that a non-standard sequence of keystrokes led to such disastrous consequences. The fault that was experienced is now known as Race Condition.
Paul Anderson, vice president of engineering at GrammaTech, a spin-off of Cornell University that specialises in static analysis, has recently teamed up with the FDA to produce a research paper: ‘Using static analysis to evaluate software in medical devices’.
In his opinion, the analysis should be employed in the very initial stages of development. “Production is by far the best time to employ this,” he explains. “With every earlier stage you find the bug, the cheaper it is to fix by a factor of around ten. If you find it during design it will be cheap to fix, if you get to coding then it is a bit more expensive and if you find a bug in an employed device in the field, then it is hugely expensive to fix.”
But in Bolger’s opinion it is in the maintenance of medical systems where it can really come into its own. “We recognise that most of the software industry is in maintenance mode for more than 90% of the time. That’s where we need to be – helping them maintain a high-quality level to their software to make sure they’re not adding some new functionality that doesn’t meet coding standards.”
Raoul Jetley, a researcher at the FDA Center for Devices and Radiological Health/Office of Science and Engineering Laboratories, says that in an ideal world static analysis should be integrated with the manufacturer’s software lifecycle development process.
He believes the medical device industry is not as receptive to the technology as its peers. “Automotive, aerospace, rail and other safety-critical industries have embraced all forms of static analysis and incorporated formal methods based on the modelling and verification into their standard of development practice for many years,” he says. “The medical device industry has not embraced this technology to the same extent as other safety-critical industries.”
Indeed, the automotive industry has the industry standard known as Misra, the Motor Industry Software Reliability Association guidelines, the latest standard of which was taken from the avionic industry. But, Jetley says it is not something they will push for in medicine. “While the FDA encourages the use of static analysis, it will not mandate the use of a particular technique for software verification. Device manufacturers can use any means to verify their software as long as they can assure safety and effectiveness of their device,” he says.
Although not likely to occur anytime soon, Anderson says that in theory a set of guidelines could be applied. “I have not heard any talk about adopting coding standards like the Misra rules but I would expect that instead of coming up with fresh ones, it makes sense to adopt these,” he adds.
But while this kind of regulation is not in place, Jetley says that a common way of validating a static analysis tool is to have it analyse itself to detect any possible anomalies.
Nothing is perfect
Static analysis can also be complemented by other similar techniques like dynamic analysis. The latter actively runs a programme with a predefined set of parameters to see how the machine would work in a specific test situation while static analysis creates more general, all-encompassing parameters to pick up bugs over a number of variables.
However, like most systems this method of analysis is not infallible. Even the major competitors in this field will readily admit to the existence of ‘false positives’ which are an unavoidable annoyance.
False positives are warnings reported by the tool that are not genuine errors and are merely created because of the lack of domain specific knowledge about the code. “The challenge is to manage techniques that keep the false positives very low and at the same time find the interesting bugs,” says Anderson. “That is what differentiates this class of static analysis tools from those used in the past.”
In his opinion, static analysis is still a very open research area and eliminating false positives and false negatives (where bugs in existence are not found) as well as improving overall performance is still vital. Jetley agrees. “Practically speaking, completely eliminating false positives and negatives is not possible given the state of technology.
Most effective static analysis tools try to find the elusive spot between false positives, false negatives and performance to make it practical in every day software development.”
While the software may not be foolproof, the benefits of running this type of analysis, especially on embedded devices like mechanical hearts, could be life saving. While other industries now legally have to employ it, the medical device network needs to learn to be more receptive to the safety technologies on offer.
