Internal Bug: Code Flaw May Lead to Wrong Dose From Infusion Pump 86
chicksdaddy writes "The steady drumbeat of disturbing news about vulnerable, IP enabled medical devices continues this week, after medical device maker Hospira said it has issued a voluntary recall of its Symbiq-brand drug infusion pumps after discovering a software error that may cause touch interfaces on the pumps to not respond to user touches or to display dosage information that is inaccurate. The problem was detected in around 1.5% of Symbiq One Channel and Two Channel Infusers (model numbers 16026 and 16027), but could potentially affect 'all Symbiq infusion systems currently in the field.' The software bug 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."
Interesting (Score:4, Interesting)
How do you teach that to nursing students?
Re: (Score:3)
I would assume they would already know that tools are not infallible and if things are looking right get another source of data.
On the other hand personal experience teaches me some Nurses and Doctors seem to prefer conjecture to actual testing.
Re: (Score:3)
I would assume they would already know that tools are not infallible and if things are looking right get another source of data.
Even if it is a correct assumption, what feedback would they receive that the pump is infusing at the wrong rate?
Re: (Score:2)
By testing the patients blood and noting that claimed infusion rate does not match reality.
Re: (Score:2)
Or death.
Re:Interesting (Score:5, Informative)
You have no clue what you're talking about. Patients get PISSED when they need to be stuck with needles more often than necessary. Especially when you go tell them it's because we don't know if that IV device actually works right.
People just love to be guinea pigs.
On top of who's paying for that? Health insurance companies sure as shit don't pay for device diagnostic tests. Nor does it cover the fact that every patient's different based upon their size, composition, metabolism, etc. All those factors play a big role in drug absorption and metabolism. There's no way to get an established set of values to determine a precise numeric value for infusion.
Not to mention, exactly what blood test are you going to use to test for a straight up saline drip?
Your statement is incredibly misinformed. You'd get better results just by standing next to the pump and listening to it to determine approximately how much it's infusing. Of course that requires one be experienced with the pumps to be able to gauge that by ear.
Re: (Score:2)
+1 - I was just coming back to make pretty much this point, and would have doubtless made it less well.
Re: (Score:2)
You have no clue what you're talking about. Patients get PISSED when they need to be stuck with needles more often than necessary. Especially when you go tell them it's because we don't know if that IV device actually works right.
People just love to be guinea pigs.
On top of who's paying for that? Health insurance companies sure as shit don't pay for device diagnostic tests. Nor does it cover the fact that every patient's different based upon their size, composition, metabolism, etc. All those factors play a big role in drug absorption and metabolism. There's no way to get an established set of values to determine a precise numeric value for infusion.
Last I checked, insurance companies pay for a lot of diagnostic tests. And it's worth noting that things go wrong. So diagnostic tests are required for precisely the above reason.
Not to mention, exactly what blood test are you going to use to test for a straight up saline drip?
How often is the patient urinating? But I imagine blood tests would pick up on whether a patient had too much or too little hydration.
The problem here is that the system is not a straight up saline drip (any more than the old style IV drip). It's a means to inject drugs. And one only knows for sure the actual dosage given to the
Re: (Score:1)
Insurance companies pay to run patient diagnostics, not device diagnostics. Don't be dense.
You want to throw urination in as a measure of an IV drip too? What a great idea. Oh wait, there's that tiny little problem of the patient drinking. And of course you need to take into account the efficiency rate of their kidneys.
And one only knows for sure the actual dosage given to the patient via tests that measure that.
But this line is priceless. One always knows the actual dosage given to the patient by how much drug they put in. The IV Infuser working properly or not is irrelevent to that datapoint.
Re: (Score:2)
You want to throw urination in as a measure of an IV drip too? What a great idea. Oh wait, there's that tiny little problem of the patient drinking. And of course you need to take into account the efficiency rate of their kidneys.
Tell you what. You come up with a better idea, you be sure and tell us.
But this line is priceless. One always knows the actual dosage given to the patient by how much drug they put in. The IV Infuser working properly or not is irrelevent to that datapoint. The issue here is that the RATE OF INFUSION cannot be determined by any blood tests after the fact. All it can do is tell you how much is in there at that moment.
Two things to note here. First, you don't "know" the actual dosage given to the patient any more than you "know" the rate of infusion. The blood test in contrast, tells you what is actually important, how much is in the body. That's the actual dosage.
Re: (Score:2)
How about MAKING A DEVICE THAT FUCKING WORKS LIKE IT'S SUPPOSED TO?
Think about it. What device works like it is supposed to?
Re: (Score:1)
Yes, you do KNOW the dose. Whether it's mixed with saline, or is a straight up bag of goo, there's a specific amount added. Then, as part of the doctor's order, it is prescribed with a rate of infusion. If the machine doesn't work right, that rate of infusion is no longer true and there's absolutely no way possible to determine it after the fact using any known blood tests. All they know is that X amount of drug, regardless of how it's mixed, was infused. That is a known constant barring human error wi
Re: (Score:2)
Yes, you do KNOW the dose. Whether it's mixed with saline, or is a straight up bag of goo, there's a specific amount added.
And you are in error already. That assumption can be wrong.
The better idea, is obviously for a vital piece of equipment found everywhere in hospitals to actually work correctly every time.
An impossibility is not a "better" idea. No piece of equipment, no procedure, no person, nothing found in the real world works correctly every time.
Re: (Score:2)
Patient's blood is usually tested no more than a few times a day, if that frequent. Tests also tend to take hours at least to come back - especially with routine, check-up, non-emergency types of tests. Quite a slow feed-back loop, and most definitely not the way to check whether your infuse is producing the right dose.
Re: (Score:2)
Even if it is a correct assumption, what feedback would they receive that the pump is infusing at the wrong rate?
On the inline pumps, the medicine is added to a bag of ringer's lactate and has a conventional dripping flow meter attached to it before it goes into the pump. The pump regulates the flow of the medicine into the patient, but you can calculate the flow rate by looking at the drips.
In a pain pump, there's a syringe containing the pain meds, and you can watch the syringe depress as meds are requested by the patient and see exactly how much is being dispensed.
Re: (Score:2)
In a pain pump, there's a syringe containing the pain meds, and you can watch the syringe depress as meds are requested by the patient and see exactly how much is being dispensed.
Is that a PCA (patient controlled analgesic)? If so, isn't the point of PCA that you don't need the nurse present?
Re: (Score:1)
You assume wrong.
If you plug the numbers into the device and recheck against the order to see if you're correct, what else can be reasonably done?
It would be the same to demand that you check the tire pressure, oil level, and battery charge every time you get into your car.
A lot of tests are done daily and you may have the incorrect dose running for up to 24 hours before being discovered if you're using lab tests to pick up medication pump errors. Unless it is such a gross error that a bag of fluid that sho
Re: (Score:1)
FTA:
after discovering a software error that caused the touch screen interfaces on the devices to respond incorrectly to user input.
From the same FA:
Software engineers and security experts have sounded warnings about the vulnerability of IP-enabled medical devices for some time now.
Re: (Score:2)
FTA:
after discovering a software error that caused the touch screen interfaces on the devices to respond incorrectly to user input.
From the same FA:
Software engineers and security experts have sounded warnings about the vulnerability of IP-enabled medical devices for some time now.
Yes,
1. Hyping a known problem (software has bugs)
2. Non Sequitur to favorite whine (Wifi enabled x is bad)
All in one little package. Perfect for page views. Little use for anything else.
Re: (Score:1)
I don't see how this is even tied to IP vulnerabilities. It's more like a cross between horrible QA and either bad programming or bad management.
Perhaps the programmers flat out sucked. Perhaps they originally designed it for use with specific hardware interfaces that are replaced in newer models. Perhaps management chose to use an older program against newer hardware. QA should catch all of this regardless. If management allowed for proper QA to occur that is...
Re: (Score:1)
Depends on their underwear and color of their skin.
Therac-25 (Score:5, Informative)
Does this remind anyone else about the issues with the Therac-25 radiotherapy machine?
User interface was able to go out of sync with the model. Causing incorrect dosage to be administered. Deaths were caused and I think we all hoped lessons had been learnt!
https://en.wikipedia.org/wiki/Therac-25
Re: (Score:2)
Darn you beat me. And yes, anyone building medical devices should have learnt the Therac-25 lesson!
Re: (Score:2)
Darn you beat me. And yes, anyone building medical devices should have learnt the Therac-25 lesson!
Buy lots of insurance?
Re: (Score:2)
The core lesson from Therac-25 cannot be taught to a profit seeking enterprise. Cutting corners cuts safety is not something they can deal with as it also cuts profit.
Both Therac-25 and this device should have had external monitoring done by another device and if what it measures does not match the expected outcome shut the device off.
Re: (Score:1)
Don't worry, open source and the free market will solve all of these problems. We just need to deregulate the medical device industry after declaring that all their code and devices should be "open source" and made from "commodity equipment."
Just look at the recent articles about the cost of hearing aids, and you'll see that Slashdot is firmly in favor of letting the community solve its own problems, through some combination of "bluetooth" and "i could cobble something like that together in an afternoon,"
Re: (Score:2)
I think you are really looking at the extremes.
There probably are very likely somethings that could be done better and cheaper with less regulation, but an insulin pump is not one of them.
Sure people exaggerate probably because unless you really understand the problem hearing aids seem like they should be simple. In fact they are very complicated and have to meet a giant checklist of wants and needs.
Re: (Score:2)
While both are important, a hearing aid and an insulin pump have very different safety requirements. For one, a hearing aid won't kill you if it suddenly goes to 11 or 0.
Re:Therac-25 (Score:5, Interesting)
The statement about how the lesson can't be taught to profit seeking enterprises is a load of crap. I have worked in both the area of distributed control systems as well as financial transaction processing (which are both self regulated), and we ALWAYS took situations like this VERY serious. We tested and tested and tested and tried to cover all conditions BEFORE we hit the market. Did the testing cut into our sinister profits, yes, but we knew that peoples lives and livelihoods were on the hook. Are there some companies that don't care, sure, but they will always exist regardless of operating environment.
Re: (Score:3)
The issue is the moment it becomes more expensive to prevent or insure against than the value of the company everyone becomes one of those sinister companies.
If I have a $3 billion company why would I insure against a $4 billion problem more than a $3 billion dollar one?
By its very nature limited liability limits the liability and thus the incentive to not fuck up.
Re: (Score:2)
Way to ignore what I said.
I never mentioned they would not try, nor did I indicate failure would be the majority.
Re: (Score:2)
Very serious, huh? What measures did you take to ensure safety? What I mean is, that code review and testing to the umpteenth level will never uncover every problem. If you aren't doing formal verification, proving that the software is designed correctly and works correctly, you aren't being as serious about it as you could and perhaps should be.
And such application checking cannot address systemic problems. For instance, if the code is in C/C++, one can make a real mess with pointers, memory leaks, b
Re: (Score:2)
I saw that fundamental problem with the military. They wanted security, but they wanted their shiny Windows.
And now that Windows isn't shiny any more they have neither. I can't say I feel a terribly large amount of sympathy, though I do worry about the day a Windows virus sets off a nuke. Let me see, if Windows turns Vladivostok into a smoking hole in the ground should Microsoft be held liable?
Re: (Score:3)
An 'external monitor' for an IV pump? Exactly how would you do that? Gang another pump in series (with concomitant added complexity, chances for infection vectors, operator error and other issues)?
From the fairly useless blurb it sounds like on some (but not all) pumps the user interface can't keep up with the user. Suggests that there was a problem in understanding the manufacturing tolerances of the touchscreens or some other timing issue in the system. While concerning, I don't think anyone really t
Re: (Score:2)
No other pumps, just another array of sensors.
Heck, the external monitor might be to have the patient test his blood and compare to the value the iv pump expected.
Re: (Score:2)
What's interesting is that TFA says the wifi connectivity of the device is partly for reporting back dosage and timing information. It's entirely possible that the "IP-enablement" of the device is exactly how this bug was caught - somebody noticed a discrepancy where either it was reporting delivering a dangerous amount of a drug to a patient, or a patie
Re: (Score:2)
Simply amazing! A bit of technology used for good, and perhaps bad. (I didn't pick up that bit, thanks).
Complications!
Re: (Score:2)
They do have an "external monitor" for IV pumps. It's called a nurse. There's still a drop flowmeter inline up by the bag of IV fluid. Nurses can check this to see what the actual flow is into the patient, when an IV pump is being used. I don't think putting more than one pump on an IV line would work. The IV pumps are very sensitive to blockages and will stop and alarm if the flow is impeded.
Re: (Score:1)
PC, GUI, RS232 board, is one way I can personally verify it has been done. See my previous post for the caveats, though.
Re: (Score:2)
Smart for-profit companies will take such lessons really seriously.
Why? If they don't, one time it goes wrong and they're out of business. If they do, they get over time an excellent name, and can sell at maximum profit. Overall much more profitable than saving a bit of cost cutting corners.
And that's not even counting the potential criminal liablity by the company staff and directors, which can be quite serious in case of death through negligence.
Re: (Score:1)
Nothing to do with 'vulnerable IP enabled' (Score:5, Insightful)
and everything to do with bad code. Why imply that the connectivity is somehow at fault here?
More opportunity for bad code (Score:2)
Re: (Score:2)
And here I thought that more connectivity meant more opportunity to patch software in the field instead of requiring a recall. See also every game system made in the past decade.
Re: (Score:2)
So you are claiming that the mere existence of connectivity code increases the chance of bugs in the infusion code?
How so?
Re: (Score:2)
Interesting, but IP related? (Score:5, Insightful)
Hospira has completed an investigation into customer reports and has found the major contributor to be software related. Other contributing root causes that have been identified include damaged connections, physical damage and other touch screen defects.
It would be nice if the article would stick to the point and not confuse issues.
Re: (Score:1)
It does have to do with firmware/software, user interface, and correctness/reliability, but not security. An unreliable system can never be a secure system, but that often causes people to conflate the concepts of reliability and security.
Lets get a sense of perspective (Score:2)
There are orders of magnitude more medical fsck ups caused by humans making a mistake than by medical devices making a mistake. If I had to choose between a machine giving me a correct dose or a overworked doctor who's been on call for 24 hours with hardly any sleep, well , its not going to be the doctor.
Re: (Score:1)
Of course.
Don't dare tell a doctor or nurse or pharmacist that though. They will go nuts on you. For some reason they are terrified of having anything done by a more reliable system.
Re: (Score:2)
Oh, phoo - it depends on the doctor, and as a population they're probably somewhat less paranoid than your average Joe on the street. There is a lot of fear in the culture about things being taken over by machines. While some is it is about lost jobs, far more is about lost control. (Then, generally, people meet the devices and become accostumed to them.)
The issue with code problems it, of course, that a single mistake can effect far more than one patient. (And yes, of course code generally is more carefull
Re: (Score:2)
Yes, that's correct. Humans make enough mistakes, we don't need machines making them for us when we manage to get things right.
why a touch screen AT ALL (Score:2)
i think for this a 10 key pad (maybe with a row of "extra" buttons) would be a better idea since these devices tend to be used in meds that may not have enough "slop" to handle being set WRONG.
bacteria....is why (Score:2)
Re: (Score:3)
Wouldn't separating the controls from the device just be easier?
Nothing complicated just a pogopin connection or similar. That way you can wipe down the whole device and it can be sealed.
Re: (Score:2)
Quite possibly cost and size. Not only can the buttons not be displayed for normal viewing, and more data can be removed, but a digitizer is damn cheap.
Also it will look a lot nicer and more modern to the customers.
no moving parts, easy to clean (Score:2)
As soon as you introduce physical keys you have moving parts that can get gummed up, are hard to sterilize, and wear out.
Re:no moving parts, easy to clean (Score:4, Informative)
As soon as you introduce physical keys you have moving parts that can get gummed up, are hard to sterilize, and wear out.
lolwut?
http://en.wikipedia.org/wiki/Membrane_keyboard [wikipedia.org]
Also, resistive and capacative touch screens won't work well with the sterile gloves that many medics wear.
They almost certainly did it because it is cheap and/or looks cool. Cool seems to sell even in places where it really reall shouldn't.
Re: (Score:3)
Capacitive buttons work fine with latex gloves. I used one that way frequently due to an injury for the last week or so.
Re: (Score:3)
Capacitive touchscreens generally work fine with the latex gloves medical personnel wear. Thin, little-to-no insulation, no seams... there's really very little issue getting them to work.
Also, moving keys can have corners and edges that can snag and tear gloves, as well - touchscreens do not.
They're moving to touchscreens because touchscreens work, and work well, plus are easier to keep clean.
Re: (Score:2)
Resistive touch screens work by using pressure to close a thin gap between two transparent membranes, and work regardless of whether you're pressing them with fingers, gloves, pencil erasers, or sausages.
Membrane keys would work and are certainly able to be sealed, but are opaque, fixed, and require their own separate area. A touch screen can reduce the overall size of a device by allowing the buttons to occupy the same area as the display.
But most importantly, a touch screen can easily redefine the button
This happens all the time (Score:5, Insightful)
Seriously, medical devices are recalled ALL THE TIME. Not really interesting info.
I used to date a girl who handled recalls for a medical device company.
My own medical device software mistake. (Score:5, Interesting)
I wrote all the "C" code which controlled a robotic bone lengthening device. (Read up on the ilizarov procedure.) At the most basic, it is used to make your legs or arms longer, a tiny bit per day, just over an inch per month of growth. The doctors would break the bone, after having installed an external mechanical frame holding you together. They would slowly lengthen the mechanical frame by 1mm every day. They would use wrenches and do it four times a day, 1/4mm per lengthening. Our machine would do it once per minute (growing your bone at 604 nanometers additional length per minute.) I used a table in ROM of how many pulses to do, how often. A couple of the entries were wrong and resulted in the wrong amount of bone lengthening.
accountability... (Score:3)
Seems like there ought to be multiple third party code audits and product testing before these go to market. How liable is a company for software bugs that cause significant damage or kill? To what degree to third party audits remediate the level of liability? Scary stuff.
Re: (Score:2)
This was an issue for some 1.5% of the devices. Hand out five, maybe ten of them for testing by third-party auditors, and good chance none of the 1.5% is included.