It’s probably not the first thing most of us would ask, but when lawyer Karen Sandler discovered she had a potentially life-threatening heart condition and would need a defibrillator, her first question was: “What does it run?”
She adds: “I asked everyone but could not get a satisfactory answer. I contacted device manufacturers and even went as far as signing a non-disclosure agreement, but no-one seemed to take me seriously.”
Go deeper with GlobalData
It may seem a slightly arcane issue at first glance, but the regulation and transparency of the software behind medical devices is deadly serious, with potentially profound ramifications for the medical devices industry, argues Sandler. She is now an attorney with the SFLC, which campaigns to advance the agenda for ‘free and open’ software.
In an environment where more and more medical devices are becoming implantable, being sure that their software is not going to malfunction is of critical importance. And, as Sandler points out: “The US Food and Drug Administration (FDA) does not review the source codes of medical devices, relying instead on the documents supplied by manufacturers and the tests they carry out, without knowing how well designed or appropriate those tests might be.”
Implantable medical devices are commonly used by millions of patients to treat chronic heart conditions, epilepsy, diabetes, obesity and even depression. The software within them can be used for actions such as cardiac pacing and defibrillation, drug delivery and insulin administration. In many cases it is also responsible for monitoring, recording and storing private patient information, communicating wirelessly with other computers and responding to changes in doctors’ orders. Yet it is well-known that software, especially the more complex it gets, is not infallible and rarely ‘bug-free’.
“It is estimated that for every 1,000 lines of code you will get a bug,” says Sandler. “And these are devices that will have hundreds of thousands, sometimes millions, of lines of code.”
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 GlobalDataJust as worryingly, she points out that the FDA issued 23 recalls of defective devices during the first half of 2010, all categorised as ‘Class I’ recalls, meaning there was “reasonable probability that use of these products will cause serious adverse health consequences or death”. Although it is hard to tell from the information the FDA has released on these recalls, Sandler estimates that at least six of those 23 were caused by software defects.
Then there was the FDA’s Infusion Pump Improvement Initiative, launched in April 2010 in the wake of approximately 56,000 reports of adverse events related to infusion pumps between 2005 and 2009. The initiative found that the most common types of problems reported were associated with software defects or malfunctions, user interface issues and mechanical or electrical failures. Moreover, the US Supreme Court ruling in Riegel vs Medtronic in 2008 prohibited patients harmed by defects in FDA-approved devices from seeking damages against manufacturers in state courts. What this has meant in reality, Sandler suggests, is that people have little option but to “trust manufacturers entirely or risk their lives by opting against life-saving treatment”.
The worry is that, as more implantable medical devices are designed to wirelessly communicate with physicians’ offices, hospitals and manufacturers, routine tasks such as reprogramming, data extraction and software updates may lead to even more accidental software glitches, which could in turn compromise the security, safety and effectiveness of such devices.
Greater transparency
No-one is suggesting that manufacturers deliberately go out of their way to incorporate faulty software into their devices. What Sandler and the SFLC want to see is more transparency and access to what is going into them, arguing that a more open software regime would lead to a much safer one.
“The manufacturers argue that the best way is ‘security through obscurity’. They argue that by not publishing source codes, it is safer because they do not take the risk of exposing them to hackers. But the more sophisticated a device becomes, the more reliant it will be on its software.
“Software bugs are, of course, a fact of life and we are not trying to be alarmist. Anyone who works on code knows that bugs are going to get introduced along the way. But by publishing the codes, not only do you have greater transparency, it is possible for people to look at them, analyse them, then identify and rectify or flag up bugs themselves.
“It is a misconception that if source code is closed then it is protected and the manufacturer can simply fix things,” she adds. “If things are open then problems can be found and identified by everyone.”
But surely that would be commercial suicide, in effect giving away one of the most critical intellectual assets that device manufacturers have? Not so, suggests Sandler.
“Medical device manufacturers are not really selling their software, what they are selling is precision equipment,” she says. “As a patient, there is no way that I am going to buy software for a medical device from someone who has simply downloaded it from somewhere else. When I get a medical device, I get it because it is a precision piece of equipment that I can trust will do what it is supposed to do. Competition on the software simply does not come into it.”
The role of the FDA
In an ideal world, she adds, this is something the FDA should be doing. But in these austere times its resources, like everyone else’s, are not infinite. So the answer, she says, has to come through a change in mentality among device makers.
“The FDA should be reviewing the codes, but even that would be no substitute for everyone being able to review them,” she says. “It would be great to get a medical device manufacturer to take a unilateral move on this, and in doing so I am sure it would encourage others to follow suit.”
However, she is realistic enough to recognise that, especially in the current, incredibly competitive climate, this may well be little more than an aspiration. Without an FDA lead or push, this is something that is unlikely to happen from the inside out in the medical devices industry.
“The public wants devices to be as safe as possible, and manufacturers should want their devices to be as safe as possible. But for that to happen things need to be open; source codes need to be published and verifiable for review, there is no substitute for that,” stresses Sandler.
“Sadly, the only way it is going to become more of an issue is if there are more failures. We all hope there will not be any more, but there probably will be.”
