Internal Bug: Code Flaw May Lead to Wrong Dose From Infusion Pump

← Back to Stories (view on slashdot.org)

Internal Bug: Code Flaw May Lead to Wrong Dose From Infusion Pump

Posted by timothy on Thursday November 1, 2012 @03:35AM from the clippy-thinks-you're-injecting-insulin dept.

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."

86 comments

Min score:

Reason:

Sort:

Interesting by colinrichardday · 2012-11-01 03:36 · Score: 3, Interesting

How do you teach that to nursing students?
1. Re:Interesting by h4rr4r · 2012-11-01 03:42 · Score: 2
  
  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.
2. Re:Interesting by Anonymous Coward · 2012-11-01 03:43 · 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.
3. Re:Interesting by ColdWetDog · 2012-11-01 04:04 · 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.
  
  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.
  
  --
  Faster! Faster! Faster would be better!
4. Re:Interesting by colinrichardday · 2012-11-01 04:04 · Score: 2
  
  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?
5. Re:Interesting by h4rr4r · 2012-11-01 04:10 · Score: 1
  
  By testing the patients blood and noting that claimed infusion rate does not match reality.
6. Re:Interesting by NatasRevol · 2012-11-01 04:27 · Score: 1
  
  Or death.
  
  --
  There are two types of people in the world: Those who crave closure
7. Re:Interesting by Anonymous Coward · 2012-11-01 05:04 · Score: 0
  
  That simple, huh? Thanks for providing another bullet point underlining your comment below:
  
  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.
  It's amusing that you don't see the irony of your own statements, and just keep on pronouncing "simple" solutions to things you don't "really understand."
8. Re:Interesting by wganz · 2012-11-01 05:07 · 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 should take 24 hours to infuse only takes part of your 8 hour shift.
9. Re:Interesting by autocannon · 2012-11-01 05:14 · 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.
10. Re:Interesting by autocannon · 2012-11-01 05:18 · 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...
11. Re:Interesting by wvmarle · 2012-11-01 05:20 · Score: 1
  
  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.
12. Re:Interesting by tylikcat · 2012-11-01 05:31 · Score: 1
  
  +1 - I was just coming back to make pretty much this point, and would have doubtless made it less well.
13. Re:Interesting by khallow · 2012-11-01 05:56 · Score: 1
  
  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 patient via tests that measure that.
14. Re:Interesting by Mike+Buddha · 2012-11-01 06:10 · Score: 1
  
  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.
  
  --
  by Mike Buddha -- Someday the mountain might get him, but the law never will.
15. Re:Interesting by colinrichardday · 2012-11-01 06:41 · Score: 1
  
  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?
16. Re:Interesting by autocannon · 2012-11-01 07:33 · 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. 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.
17. Re:Interesting by khallow · 2012-11-01 09:34 · Score: 1
  
  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.
18. Re:Interesting by shiftless · 2012-11-01 11:53 · Score: 0
  
  Tell you what. You come up with a better idea, you be sure and tell us.
  How about MAKING A DEVICE THAT FUCKING WORKS LIKE IT'S SUPPOSED TO? Do you think that would be a better idea, JACKASS?
  Fucking Christ this site is full of dense pedants.
19. Re:Interesting by khallow · 2012-11-01 12:28 · Score: 1
  
  How about MAKING A DEVICE THAT FUCKING WORKS LIKE IT'S SUPPOSED TO?
  Think about it. What device works like it is supposed to?
20. Re:Interesting by autocannon · 2012-11-01 13:31 · 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 with the dose.
  This is not an electrical system. Organic systems are complex, if you apply 100 mg of drug X you will then find blood test gives result Y every time will never happen. It doesn't work that way. AT ALL. In fact, given a single blood sample, if you run the same test on it twice you will get different results. They are most likely very close, but they're not exact. However, sometimes a blood sample will give such bizarre results that a second sample will be required to verify. So any attempt to use a blood test to make a numerical certainty of what a device did before hand is sheer lunacy. God you'd almost think I have firsthand knowledge of how hospital laboratories work.
  Do you know anything about healthcare, or just like to argue about what you know nothing about.
  The better idea, is obviously for a vital piece of equipment found everywhere in hospitals to actually work correctly every time. Ever been in an ER? Just pretend for an instant that it's important their equipment work without question. There's not always time to check after the fact.
21. Re:Interesting by khallow · 2012-11-01 18:40 · 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.
  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.
22. Re:Interesting by Anonymous Coward · 2012-11-01 23:18 · Score: 0
  
  With what those guys think, it's more like testing your tire pressure, oil level, etc. every time you crank the car and several times an hour while it's running, with calibration of your instruments against physical reference standards from scratch every time.
Therac-25 by Anonymous Coward · 2012-11-01 03:43 · 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
1. Re:Therac-25 by TERdON · 2012-11-01 03:44 · Score: 1
  
  Darn you beat me. And yes, anyone building medical devices should have learnt the Therac-25 lesson!
  
  --
  I have a really elegant proof for Fermat's last theorem. If this sig was only a bit longer...
2. Re:Therac-25 by h4rr4r · 2012-11-01 03:47 · Score: 1
  
  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.
3. Re:Therac-25 by Anonymous Coward · 2012-11-01 04:02 · 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," without the interference and meddling of government regulation.
  It's hilarious to me that people who are so quick to sound off about how corporations will always produce crap unless they're forced to produce a safe device at gunpoint will also say that those devices should be super cheap, and opine that eliminating government meddling will magically produce a cheaper product that is as safe - if not safer - due to some sort of magical "open source community" secret sauce.
4. Re:Therac-25 by h4rr4r · 2012-11-01 04:09 · Score: 1
  
  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.
5. Re:Therac-25 by deKernel · 2012-11-01 04:10 · Score: 4, 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.
6. Re:Therac-25 by ColdWetDog · 2012-11-01 04:11 · Score: 2
  
  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 thinks you can get 'perfect' devices. Certainly the smarter pumps have the advantage that they can do some simple arithmetic calculations (which humans are notoriously buggy at) and have many more failsafes than the old 'dropper' method of determining IV flow rates (1 drop every 10 seconds = 100 cc / hr or some similar).
  I'm more interested in how they determined an error in 1% of their pumps. Did somebody look carefully? Did their QA processes find it? Did the FDA find it?
  
  --
  Faster! Faster! Faster would be better!
7. Re:Therac-25 by h4rr4r · 2012-11-01 04:13 · Score: 2
  
  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.
8. Re:Therac-25 by h4rr4r · 2012-11-01 04:14 · Score: 1
  
  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.
9. Re:Therac-25 by Anonymous Coward · 2012-11-01 04:22 · Score: 0
  
  So then your comment about "companies won't learn it" is a case of looking at extremes too? Why not actually, you know, engage in reasoned, rational discussion then? This is Slashdot - I presume you're here because you want to read about interesting science and technology, and engage in reasonable discussion of the same... not just karma whore by mixing "for profit evil, mitt romney bad, government regulation evil!" into a logically contradictory stew.
  Lots of companies take great pains to ensure that their devices are designed safely; This issue affects an estimated 1% of this company's pumps - meaning... 99% of them are just fine. But of course, that doesn't stop you sounding off about how "the only company that cares about patient safety is one that's forced to on pain of a bullet to the head." When's the last time you wrote software to control anything as complex as an infusion pump, and had anything even as low as a 5% failure rate?
  Your comment about how they "ought to have" fixed the problem - by adding another device, or testing the blood, sort of negates the benefit of having a portable infusion pump in the first place - which is that the patient can manage their own dosage without having to be in the doctor's office 2, 3, 4, times a day, or the constant presence of a nurse to ensure that proper dosage is being administered, or being hooked up to a medicine cabinet worth of machinery to ensure that everything is working properly. In addition, you are simply serializing two (or more) complex pieces of machinery, making it all the more likely your system will fail.
  Given a likely incorrect dosage of less than 1% (1% of the units are estimated to be faulty - it's likely that less than all of those units have actually administered a wrong dose), I'd love to see the numbers on how often doctors and nurses screw up doses and timing, because it wouldn't surprise me a bit if their failure rate was significantly higher than 1%.
10. Re:Therac-25 by Anonymous Coward · 2012-11-01 04:32 · Score: 0
  
  And who said IPad couldn't kill you?
  Captcha: salesman
11. Re:Therac-25 by Anonymous Coward · 2012-11-01 04:33 · Score: 0
  
  You are, of course, demonstrably wrong, and it's clear that you've done all your market research by watching Fight Club.
  Those "$3bn" Pharmaceutical and medical device companies regularly produce devices that would expose them to far more than $3 billion in liability. And yet, the devices they manufacture are overwhelmingly safe. Why? Because the people making the devices are largely good people, who don't want a device they participated in the manufacture of to kill other people.
  A "ZOMG HORRIBLE" headline about a faulty medical device... affects ~1.5% of the devices this single company produces. Meaning 98+% of them are not faulty. Meaning, these are overwhelmingly safe devices - and the company is producing them to a degree of safety that far exceeds $3bn of liability.
  But don't let any facts or reason stand between you and your bizarrely dissonant "anti-corporate, anti-government, anti-regulation, pro-safety" ravings. I hear that line of attack is pure GOLD when you're karma whoring on Slashdot.
12. Re:Therac-25 by h4rr4r · 2012-11-01 05:04 · Score: 1
  
  Way to ignore what I said.
  I never mentioned they would not try, nor did I indicate failure would be the majority.
13. Re:Therac-25 by sjames · 2012-11-01 05:18 · Score: 1
  
  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.
14. Re:Therac-25 by wvmarle · 2012-11-01 05:23 · Score: 1
  
  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.
15. Re:Therac-25 by Americano · 2012-11-01 05:43 · Score: 1
  
  I'm more interested in how they determined an error in 1% of their pumps. Did somebody look carefully? Did their QA processes find it? Did the FDA find it?
  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 patient said, "I told it to give me 100mg of the drug," and the device was reporting, "I gave them 10mg of the drug."
  It's entirely possible that the IP capabilities of the device are precisely why the were able to find the bug in question.
16. Re:Therac-25 by bzipitidoo · 2012-11-01 05:50 · Score: 1
  
  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, buffer overruns, and the like. The language lends itself to those kinds of problems. We now have tools like Valgrind to catch some of that, but still, can't depend on those tools to catch everything. A language such as Java makes some of those problems impossible. Some kinds of memory leaks can't happen with automatic garbage collection. Java also tries to simplify pointers by hiding them. Then, need I comment about the use of Windows (WinCE, maybe?) as a platform? I saw that fundamental problem with the military. They wanted security, but they wanted their shiny Windows. So they insisted that Windows be made secure, rather than accept that they ought to switch to Linux (slightly better), or SELinux (a bit better yet), OpenBSD, or go all the way and dig up a formally verified microkernel, like perhaps QNX. Did you consider such things, or did you try to push ahead with inferior tools?
  The infamous Therac-25 was an extreme example of bad engineering. Sanity checks of the outputs is always a good idea, but they removed that, to save money. The saddest part is they didn't even do a good job of analyzing whether removing those sanity checks saved any money. If they had, they would have realized the savings was so small it was less than the costs of the changes to the software. They made a number of other utterly boneheaded and incompetent decisions, such as hiring bad programmers. Some of the stuff in the Therac-25 software would easily make The Daily WTF.
  
  --
  Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
17. Re:Therac-25 by Mike+Buddha · 2012-11-01 06:12 · Score: 1
  
  Darn you beat me. And yes, anyone building medical devices should have learnt the Therac-25 lesson!
  Buy lots of insurance?
  
  --
  by Mike Buddha -- Someday the mountain might get him, but the law never will.
18. Re:Therac-25 by ColdWetDog · 2012-11-01 06:14 · Score: 1
  
  Simply amazing! A bit of technology used for good, and perhaps bad. (I didn't pick up that bit, thanks).
  Complications!
  
  --
  Faster! Faster! Faster would be better!
19. Re:Therac-25 by Mike+Buddha · 2012-11-01 06:17 · Score: 1
  
  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.
  
  --
  by Mike Buddha -- Someday the mountain might get him, but the law never will.
20. Re:Therac-25 by Tough+Love · 2012-11-01 08:53 · Score: 1
  
  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?
  
  --
  When all you have is a hammer, every problem starts to look like a thumb.
21. Re:Therac-25 by Anonymous Coward · 2012-11-01 09:58 · Score: 0
  
  Don't forget, it will be 3D printed in space in a private orbital factory.
22. Re:Therac-25 by Anonymous Coward · 2012-11-01 13:29 · Score: 0
  
  Nurses can use that to get a rough estimate of how much fluid is flowing. An order of magnitude infusion rate problem will show up; a 10% one won't.
23. Re:Therac-25 by Empiric · 2012-11-01 13:50 · Score: 1
  
  Some lessons were learned, if only the priority to isolate to somebody else the selling company's risks. Around 20 years ago my first "real" software job was writing software to interface PC GUI-based monitoring/nursing-operation software to another Very Large Very Well Known Company's infusion pumps. Along with all the software implementation expectations they had of the 8-person company I worked for, a major priority of theirs was ensuring we developed a "Failure Mode Effects Analysis" document. Essentially, that involved our company non-optionally documenting (and thereby taking the risk for), every conceivable way the overall system could break (inclusive of their pumps breaking), and detailing specifics on how it wouldn't break (in a manner that could conceivably put a patient at risk) even if it broke, for all those hypothetical circumstances. My introduction to the world of theoretically-impossible engineering tasks, and the politics of making sure those tasks are the responsibility of Other People, started early...
  
  --
  ~ Whence do you come, slayer of men, or where are you going, conqueror of space?
24. Re:Therac-25 by Empiric · 2012-11-01 13:57 · Score: 1
  
  An 'external monitor' for an IV pump? Exactly how would you do that?
  
  PC, GUI, RS232 board, is one way I can personally verify it has been done. See my previous post for the caveats, though.
  
  --
  ~ Whence do you come, slayer of men, or where are you going, conqueror of space?
25. Re:Therac-25 by Anonymous Coward · 2012-11-01 14:21 · Score: 0
  
  "we knew that peoples lives and livelihoods were on the hook"
  Yeah, the CEO's.
Nothing to do with 'vulnerable IP enabled' by Anonymous Coward · 2012-11-01 03:45 · Score: 5, Insightful

and everything to do with bad code. Why imply that the connectivity is somehow at fault here?
1. Re:Nothing to do with 'vulnerable IP enabled' by Anonymous Coward · 2012-11-01 05:09 · Score: 0
  
  IP="Intellectual property" I think, i.e. closed source code, no pear review no external checks.
2. Re:Nothing to do with 'vulnerable IP enabled' by Anonymous Coward · 2012-11-01 05:49 · Score: 0
  
  Oh, so it only affects medical devices that contain intellectual property. That makes as much sense as a fruit reviewing said IP.
3. Re:Nothing to do with 'vulnerable IP enabled' by Anonymous Coward · 2012-11-01 07:45 · Score: 0
  
  This doesn't even seem to have anything to do with bad code. With the problem only occuring on 1.5% of the devices, it is more likely a supplier quality issue with the touch screen.
Interesting, but IP related? by PieEye · 2012-11-01 03:47 · Score: 5, Insightful

I don't see any mention in the article that having the device connected to IP is causing the issue. Sounds like a touchscreen / code issue. The FDA's article also doesn't specify anything other than that.
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.

--
... in bed.
1. Re:Interesting, but IP related? by Smerta · 2012-11-01 04:14 · Score: 1
  
  Absolutely agree. I've given talks about embedded devices and problems created by adding IP connectivity, but from what I can tell this has nothing to do with connectivity.
  
  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.
More opportunity for bad code by tepples · 2012-11-01 03:50 · Score: 1

More connectivity means more code. More code means more opportunity for bad code. Code involved in connectivity is also likely to see more scrutiny from criminals who want to commit a crime remotely.
1. Re:More opportunity for bad code by kwerle · 2012-11-01 04:33 · Score: 1
  
  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.
2. Re:More opportunity for bad code by Zalbik · 2012-11-01 05:00 · Score: 1
  
  So you are claiming that the mere existence of connectivity code increases the chance of bugs in the infusion code?
  How so?
3. Re:More opportunity for bad code by tepples · 2012-11-01 05:34 · Score: 1
  
  I am claiming that if poorly written connectivity code inadvertently overwrites arbitrary data in certain edge cases, this may allow an attacker to overwrite data used by the infusion code.
Lets get a sense of perspective by Viol8 · 2012-11-01 03:52 · Score: 1

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.
1. Re:Lets get a sense of perspective by h4rr4r · 2012-11-01 03:55 · Score: 0
  
  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.
2. Re:Lets get a sense of perspective by asylumx · 2012-11-01 04:15 · Score: 1
  
  There are orders of magnitude more medical fsck ups caused by humans making a mistake than by medical devices making a mistake.
  Yes, that's correct. Humans make enough mistakes, we don't need machines making them for us when we manage to get things right.
3. Re:Lets get a sense of perspective by tylikcat · 2012-11-01 05:10 · Score: 1
  
  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 carefully monitored.)
4. Re:Lets get a sense of perspective by Anonymous Coward · 2012-11-01 05:17 · Score: 0
  
  And how do you reconcile this with the fact that the medical industry has moved towards more automation, more machinery, and more reliable systems, in spite of all this?
  Are you really implying that doctors, nurses, and pharmacists would PREFER killing someone through a medical error? Because that seems to be what you're saying, and that doesn't seem to match up with reality in any way, shape or form.
why a touch screen AT ALL by RobertLTux · 2012-11-01 03:53 · Score: 1

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.

--
Any person using FTFY or editing my postings agrees to a US$50.00 charge
1. Re:why a touch screen AT ALL by h4rr4r · 2012-11-01 03:57 · Score: 1
  
  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.
2. Re:why a touch screen AT ALL by Anonymous Coward · 2012-11-01 04:40 · Score: 0
  
  Medical devices, especially those in hospitals and other places like that, are recommended to have a maximum of something like five buttons (one of which is power).
  This leads to simpler interactions, and fewer problems.
  People don't need to remember what to key in or whatever, they just "follow" the UI. This is important when multiple people are using the same product all day (various nurses for the same patient, etc) and also when a single person is using multiple products (same nurse for various patients).
bacteria....is why by bodland · 2012-11-01 03:56 · Score: 1

Touchscreens can be made to allow for MUCH easier cleaning...and coated with bacteria resistant covers and still function. It is a big problem in healthcare...you know...
1. Re:bacteria....is why by h4rr4r · 2012-11-01 04:00 · Score: 2
  
  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.
2. Re:bacteria....is why by Anonymous Coward · 2012-11-01 13:32 · Score: 0
  
  Easier, and a terrible idea. This is about a device that (rarely) can fail into a mode in which it becomes unresponsive to inputs... and your response is to remove the input interface from the device?
This happens all the time by ahabswhale · 2012-11-01 03:59 · Score: 4, 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.

--
Are agnostics skeptical of unicorns too?
A big thanks, timothy by Anonymous Coward · 2012-11-01 03:59 · Score: 0

About to be hooked up to one of these in about two hours. Will be making inquiries, and probably insisting they use one of the older Aspira brand pumps.
Thanks for the nose news, neighbour!
1. Re:A big thanks, timothy by Anonymous Coward · 2012-11-01 05:30 · Score: 0
  
  Well when I was hooked up to a pump last year in hospital, it was an older one that slowly pushed the plunger on a pre-filled syringe attached to the infusion line. The nurse worked out the dosage needed (very carefully, I was pleased to see), and then got her calculations double-checked by another nurse - two if around, and then set the machine at the correct rate to slowly push the plunger. They also checked periodically that the plunger was moving on the marked syringe the amount they would expect from the dose set on the machine.
  The only touch-screen around was on the monitoring system - and that seemed to always cause problems with false alarms and difficulty setting it up.
no moving parts, easy to clean by Chirs · 2012-11-01 04:01 · Score: 1

As soon as you introduce physical keys you have moving parts that can get gummed up, are hard to sterilize, and wear out.
1. Re:no moving parts, easy to clean by serviscope_minor · 2012-11-01 04:09 · Score: 3, 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
  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.
  
  --
  SJW n. One who posts facts.
2. Re:no moving parts, easy to clean by h4rr4r · 2012-11-01 04:16 · Score: 2
  
  Capacitive buttons work fine with latex gloves. I used one that way frequently due to an injury for the last week or so.
3. Re:no moving parts, easy to clean by Americano · 2012-11-01 05:38 · Score: 2
  
  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.
4. Re:no moving parts, easy to clean by plover · 2012-11-01 06:25 · Score: 1
  
  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 buttons to exactly match the current state. Rather than mapping all controls to a generic set of "up / down / select / cancel" buttons, you can match the controls to the type of input. For example, you might use a slider between "loudest beep" and "silent" when in the beep volume state, but a 10 key pad for entering an exact dosage. On a medical device, clarity of meaning may be the most important attribute of the user interface - if it's confusing, or hard to read, or hard to enter, someone could make a mistake and get the dosage wrong.
  
  --
  John
accountability... by schlachter · 2012-11-01 04:19 · Score: 2

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.

--
My God can beat up your God. Just kidding...don't take offense. I know there's no God.
1. Re:accountability... by wvmarle · 2012-11-01 05:27 · Score: 1
  
  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.
2. Re:accountability... by Anonymous Coward · 2012-11-01 10:17 · Score: 0
  
  There is an army of medical liability lawyers eager to sue medical equipment providers for both real and imaginary defects. Just watch late night TV ads as they troll for clients.
Re:under the mitt romney plan pre existing conditi by JustOK · 2012-11-01 04:35 · Score: 0

Depends on their underwear and color of their skin.

--
rewriting history since 2109
My own medical device software mistake. by deathcow · 2012-11-01 05:15 · Score: 4, 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.
1. Re:My own medical device software mistake. by Anonymous Coward · 2012-11-01 07:07 · Score: 0
  
  This is the Ethan Hawke thing from "Gattaca" right? That's a real process? That's pretty awesome!