Software Bug Results In Insulin Pump Injuries, Spurs Recall

Managing Type 1 diabetes is a high-stakes balancing act — too much or too little insulin is a bad thing, resulting in blood glucose levels that deviate from a narrow range with potentially dire consequences on either side. Many diabetics choose to use an insulin pump to make managing all this easier, but as a recent recall of insulin pump software by the US Food and Drug Administration shows, technology isn’t foolproof.

Thankfully, the recall is very narrow in scope. It’s targeted at users of the Tandem t:slim X2 insulin pump, and specifically the companion application running on iOS devices. The mobile app is intended to run on the user’s phone to monitor and control the pump. The pump itself is a small, rechargeable device that users often keep on their belt or tucked into a pocket that delivers a slow, steady infusion of insulin during the day, plus larger bolus doses to compensate for meals.

The t:slim X2 insulin pump.

But version 2.7 of the t:connect mobile app can crash unexpectedly, and on iOS devices, that can lead to the OS continually relaunching it. Each time it does this, the app tries to reconnect with the pump via Bluetooth, which eventually runs down the battery in the pump. Once the battery is dead, no more insulin can be delivered, potentially leading to a condition called hyperglycemia (“hyper” meaning an excess, “gly” referring to sugar, and “emia” meaning presence in blood — excess sugar in the blood.)

Untreated hyperglycemia can progress to a much more serious state called diabetic ketoacidosis, which can lead to coma and death. Thankfully, nobody has suffered that fate from this bug, but the FDA has received over 200 reports of injuries, hence the recall. Tandem sent out a notice to all affected customers back in March to update their apps, but it’s still possible that some users didn’t get the message.

Apart from the human cost of this bug, there’s a lesson here about software design and unintended consequences. While it intuitively seems like a great idea to automatically relaunch a crashed app, especially one with a critical life-safety function, in hindsight, the better course might have been to just go into a safe mode and alert the user with an alarm. That’s a lesson we’ve learned by exploring space, and it seems to apply here as well.

Images: AdobeStock, Tandem Diabetes

23 thoughts on “Software Bug Results In Insulin Pump Injuries, Spurs Recall

    1. I mostly agree, though as you mention folks are looking at it 6 hours a day it does also mean any alerts delivered by the device are likely to be seen and acted on in a timely fashion. So double edged as is so often the case.

      But ultimately the method here is problematic bit, and in part I’d blame using Bluetooth. Though there are many elements I don’t like about this execution of the idea from the outside, but as I lack enough information on living with this particular condition to make good judgements on what is important to the user…

    2. For the cost of the device itself and associated cost of the medication etc they should literally purchase iPhones, and use them as dedicated controllers without having to dev their own. That way the iPhone battery will last ages.

    1. It’s the app that crashes, not the OS. Apple actually has a good beta system, testflight, where apps are tested before release in production. Users are invited to join so you get a very diverse testing population and app crashes are reported with all details. The way to test with medical devices is to provide the beta testers with a test device, so you are always testing the app, the interaction and the desired outcome.
      It can be something of a knee jerk reflex to discard the complete solution when something bad happens, but it’s important to always look at the complete picture. I can imagine that having a portable insuline system and an app is great when one is a diabetes patient. Of course you want this tech from a company which has it’s safety testing thoroughly done and has catered for all worst case scenario’s. There are structured methodes to do this process.

    1. It’s always easier (and cheaper) to blame someone else for your own design flaws. Also it’s quite weird that the battery can be drained by repeated Bluetooth connection attempts. This could possibly exploited just by hammering the device with a Bluetooth scanner app.

    This deeply buried software bug injured and killed dozens of people in 1985 – 1987.
    After that, you had to go to almost ridiculous lengths to document and verify every piece of code in medical systems and devices to the FDA. I remember you had to keep a 100% record of typing errors and very strict revision tracking.
    I guess they eventually stopped doing it since that does cost a lot of labor just to write code that won’t kill you.

    1. Only if your software is class C medical. Very likely they classified the app as class A, which IMHO is wrong. If it can control the pump then failure of the app can cause death, which is class C.

  2. Instant restart is in most cases a very stupid concept.

    Why? Because there might be a reason why the application crashed. And that reason might not get away with starting the app again. So this might result in a circle of crash-restart, pulling down system resources and not helping at all. (as seen above).

    The valid way to go is to protocol the crash. And have some sort of stable load process that analyses the protocol and how often (and in what time frame) the crashes occurred. This might need a dedicated app loader, that loads the target app.

    And with that information it is possible to inform the user and let her make a reasonable choice, what to do now. App telemetrie (aka phone home) could help a lot to make useful information out of raw crash infos.

    Some of our very important boat software does that and the overall user feedback is that quality hugely improved. (that said, it was not very liked before that change…)

  3. the app tries to reconnect with the pump via Bluetooth, which eventually runs down the battery in the pump

    The fact that the device doesn’t have (any?) rate limiting or identify and report excessive activity is a serious design flaw. The fact that their app is total trash is unsurprising but disappointing.

  4. I think there are multiple bugs here. For one the logic in the pump receiving the Bluetooth signal, should also be checking the battery level and should start beeping like hell if the battery voltage drop below a certain level.

  5. “, in hindsight, the better course might have been to just go into a safe mode and alert the user with an alarm.”

    Umm no. the better course absolutely is to not use a non safety-critical rated system in a role that requires its participation to keep someone alive. Putting that functionality on an Iphone.. or any consumer level device was the wrong call and should have resulted in massive punitive lawsuits against the company, their creditors, and investors, not just a recall.

    From the Apple website:
    “Not a medical device. iPhone is not a medical device and should not be used as a substitute for professional medical judgment. It is not designed or intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of any condition or disease.”

    “High-consequence activities. This device is not intended for use where the failure of the device could lead to death, personal injury, or severe environmental damage.”

    Use the right tool for the job, especially when selling medical devices.

    1. I agree with you as far as control goes. And there should be a low battery beeper someplace on the thing. But as far as displaying things goes, unless the display is necessary, who cares what it is displayed on? I am not a lover of iphoens and I am dunious of android, but if all you are doing is watching the thing work, and that is not part of it’s operation, who cares. However, this may be an unintended consequence of that, in that something that is not necessary can take out the battery and stop necessary function. Also, it is odd that outside of rate limiting, there was no auto cut off of non necessary things when the battery starts to reach a low point. The folks in Apollo 13 would have all been dead if they only had one big ON/OFF switch and could not cut systems they did not need. Smart phones ought to have something like that built in. That last 10% of the battery is reserved for the phone and gps.

  6. The problem here is that the original design ‘concept’ is fundamentally flawed. The phone should be no more than a data recieving device for the pump, and provide alerts etc as needed. The PUMP itself should be the controller and do all the heavy lifting of manging insulin delivery.

    Phone batteries go flat, get turned off, dropped in water etc etc…having that device as a critical control for a medical device is just madness. The device is undoubtely cheaper to produce without having the extra microcontroller overhead, that was possibly being the main driver on the design descions in this case.

    Glad my wife has another brand pump … where her phone is information screen, alarm and bolus calculator only.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.