Mobile phones aren’t the only products to benefit from nifty touch screen displays. A whole range of medical devices now sport them, also – as any trip to your local emergency department (or dentist’s office) will reveal. Unfortunately, many of those devices are just as balky and bug ridden as your average mobile phone -despite the fact that patients’ lives can rely on them.
And this week, there’s more evidence of the lurking epidemic of shoddy, IP enabled medical devices. The medical device maker Hospira issued a voluntary, nationwide recall of its Symbiq brand infusion systems after discovering a software error that caused the touch screen interfaces on the devices to respond incorrectly to user input. The problem could result in “a delayed response and or the screen registering a different value from the value selected by the user,” the company said in a statement.
Symbiq is a drug infusion system that delivers controlled amounts of medications to patients through intravenous, intra-arterial, epidural and other means. It is designed to prevent medical errors by offering pre-defined doses from a drug library. The devices are capable of delivering 16,000 medications across 40 clinical care areas. Symbiq systems are also wi-fi enabled and communicate infusion data back to a separate MedNet management application.
Hospira, of Lake Forest Illinois, began its recall of all Symbiq One Channel and Two Channel Infusers (model numbers 16026 and 16027) on August 29.
In its statement, Hospira said that an internal investigation found that the problems with the pump were software related and affect around 1.5% of Symbiq systems, but that “the software-related root cause of this issue potentially impacts all Symbiq infusion systems currently in the field.” Hospira said that it is in the process of developing design improvements to correct the issue,” which includes “design and development activities.” It advised hospitals and other medical offices that use the pump to test its touch screen and, if problems are encountered, to remove it from service until a patch is available from the company.
Software engineers and security experts have sounded warnings about the vulnerability of IP-enabled medical devices for some time now. A paper prepared jointly by researchers at the Univeristy of California, Berkeley, Carnegie Mellon University and the University of Massachusetts, Amherst in 2011 studied a popular automated external defibrillator (AED) and found serious security holes in both the embedded software ton the device and a commercial software update mechanism used to service it. The researchers concluded that software security is an “afterthought in medical device design.” A subsequent report (PDF) by the FDA’s Office of Science and Engineering Laboratories (OSEL) added to fuel to that argument: finding that software errors were behind a quarter of all medical device recalls in 2011. Finally, security researchers have shown how implantable medical devices such as insulin pumps can be remotely attacked and, potentially, used to deliver lethal doses of medication to their wearers.
The article keeps using the term ‘IP-enabled’ as if that was the cause of the problem. Yet, the vendor is calling this a software problem. Rather than report the facts of the situation, why is the author expand the scope beyond the facts?
What does a touchscreen bug have to do with IP security vulnerabilities? They’re two completely different subjects. More FUD journalism.
Handling of Internet Protocol packets is implemented in… software!!!
If there are poor/non-existent procedures in place to ensure that touch-screen software is working properly, why should we think that network code is competently written?
Thanks for reading and for your comments. I get your point that referring to the Symbiq as IP-enabled is kind of off point, as this isn’t a bug related to its network communications.
In the second instance, I was merely trying to put the Symbiq in the context of other stories that do have to do with vulnerabilities in the communications and management features of these devices. So this is another IP enabled device with a software bug – this one related to the touchscreen.
I don’t think this is FUD. I think the problems with poor quality software implementations on medical devices are actually well-founded and this is another data point. Nobody said the problems were limited to device communications. They span both the basic functions of the devices (in this case: distributing drugs) and their management and communications with other network infrastructure, software update and patching, etc. etc.
First: possible typo. In talking about the AED, the article reads, “[researchers] found serious security holes in both the embedded software ton the device…..” I think “ton” needs to lose a “t”.
Second, software errors in medical devices aren’t new. One of the most infamous medical device bugs was in Therac 25, a radiation therapy machine that killed several patients through overdosage. Virginia Tech has a good article on it (http://courses.cs.vt.edu/cs3604/lib/Therac_25/Therac_1.html) and I think it’s been covered in various journals over the years.
Finally, medical device manufacturers want to cut their costs by any way they can, and skimping on software testing is one of the ways they do it. This is why you see a number of medical devices running Microsoft Windows. The organization I work for has several devices (MRIs, scanning tunneling electron microscopes, etc.) that have Windows machines as controllers, but patching those systems is prohibited by the medical device manufacturer.
Thanks Alan. Fixed the typo. Also – thanks for sharing your ‘boots on the ground’ perspective. Software updates are a big problem in healthcare. I’m not sure why device makers would prohibit patches, though I know that its commonly held that FDA certification of devices prohibits software updates (that is: patching will decertify our medical devices). That, despite the fact that the FDA has been pretty clear in stating that this is not the case – that it does not need to review patches or updates necessary for cyber security – but also that security of medical devices is a joint responsibility of device makers and their customers, and that software updates should be carefully prepared and tested before they are deployed. See this statement from way back in 2009: http://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm189111.htm
The FDA needs to start requiring companies publish their code for anyone in the world to review. The average bit of non-released programming code has about 1 problem per 100. The more eyes that can look at it, the better. There will people who argue that hackers can abuse the bugs but they don’t need source code for that. As recently explained at security conferences blackhat and breakpoint, they simply decompile what is already there and use automated tools to find the bugs. Failing to publish source code makes a company more liable for its software mistakes.
Yes. Agreed. Right after the FEC starts doing the same for electronic voting systems! (More on that later, btw.) 😉
Pingback: /var/water/logged | TechSNAP | Jupiter Broadcasting
I interviewed with Hospira in San Diego about 5 months ago — They had (fired almost all of their US staff about 3 years ago and then) outsourced all of their SW dev and then “ran into some problems.”
This might actually be an indication that they are re-testing the platform extensively and finding problems. Either way, the new push by FDA compliance is driving big changes in the med device space.
Pingback: Medical device software flaw causes inaccurate dosages | Maszman Speaks!
Pingback: Medical Gadgets Buggy, Not Just Vulnerable « kabelmast
Pingback: News To oprogramowanie wyglądało na dobre, a jednak mogło zabić