Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
IOS

FDA Recalls Defective iOS App That Injured Over 200 Insulin Pump Users (theverge.com) 40

Jess Weatherbed reports via The Verge: At least 224 people with diabetes have reported injuries linked to a defective iOS app that caused their insulin pumps to shut down prematurely, according to the US Food and Drug Administration (FDA). On Wednesday, the agency announced that California-based medical device manufacturer Tandem Diabetes Care has issued a recall for version 2.7 of the iOS t:connect mobile app, which is used in conjunction with the company's t:slim X2 insulin pump. Specifically, the recall relates to a software issue that can cause the app to repeatedly crash and relaunch, resulting in the pump's battery being drained by excessive Bluetooth communication.

This battery drain can cause the pump to shut down "earlier than typically expected" according to Tandem, though the pump will notify users of an imminent shutdown via an alarm and low-power alert. The company has notified customers to update the mobile app to version 2.7.1 or later, which should fix the defective software. While no physical recall is taking place, the FDA has identified this as a "Class I" recall -- the most serious type, as it relates to issues with products that can potentially cause serious injuries or death. No deaths linked to the issues have been reported as of April 15th. Tandem is encouraging pump users to take particular care when they sleep as it's easier to miss battery depletion warnings, and is asking impacted customers to confirm they have been notified of the recall via this online form. For any other questions or concerns about the insulin pump recall, customers should contact Tandem Diabetes Care directly.

This discussion has been archived. No new comments can be posted.

FDA Recalls Defective iOS App That Injured Over 200 Insulin Pump Users

Comments Filter:
  • ...the user did not hold it the wrong way after all? /s

    Seriously ... when people's lives can be endangered, getting it right must always come before making a buck off of it.

    • Re: (Score:3, Insightful)

      by geekmux ( 1040042 )

      Seriously ... when people's lives can be endangered, getting it right must always come before making a buck off of it.

      LOL, since when?!?!?

      Seriously when someone can go to school for the better part of a decade to be called a certified expert in a field that still calls it “practicing”, getting it right has pretty much always comes with time and experience, not merely tenacity.

      Greed in capitalism hardly allows for that time and experience in development, in favor of chasing the shiny IPO penny.

  • by parityshrimp ( 6342140 ) on Thursday May 09, 2024 @05:52PM (#64460925)

    I'm guessing that the part of this that runs on the phone and iOS itself were not required to be evaluated as safety critical. Maybe they should have been.

    It's hard to imagine trusting something so important to a program that runs on a consumer phone with a consumer OS and that communicates over bluetooth.

    • It's hard to imagine trusting something so important to a program that runs on a consumer phone with a consumer OS and that communicates over bluetooth.

      At first I thought this was an app that simply provided remote monitoring and data collection, then I read the description in the App Store. The very first feature listed is "freedom to deliver a bolus from your smartphone." That's a small injection of insulin typically delivered at mealtime from what I've read.

      While the particular bug caused the pump battery to run down due to the repeated wireless communication, what if the bug triggered repeated insulin injection?

      I'm surprised that such a feature is ev

      • Re: (Score:3, Informative)

        by Luckyo ( 1726890 )

        Your suggested scenario is highly unlikely to be possible. The problem here wasn't erroneous signalling. It was the fact that app kept restarting and getting pump to go into search mode and pair with the phone again and again. Which is what runs down the battery. And even then, the pump itself has fail safes as noted, and warned user that its battery is low. So used can get their backup injector and do it manually.

        Something that pretty much every diabetic who needs insulin injections has done countless time

        • One huge issue - and I know 'cause I'm a user of the pump/app - you *do not* get a warning as the battery drains too quickly. Alternatively, you may get a warning but the battery drains too fast to react. If everything works as it should, once you get the first warning of low charge, you have around 36 hours to deal with it. Not minutes.
          • by Luckyo ( 1726890 )

            Sounds like that is the reason for pulling the product and ensuring its properly updated to non-crashing version. Story does say that you should get a warning though. I'm guessing it's wrong?

      • by tlhIngan ( 30335 ) <slashdot&worf,net> on Thursday May 09, 2024 @06:56PM (#64461071)

        While the particular bug caused the pump battery to run down due to the repeated wireless communication, what if the bug triggered repeated insulin injection?

        Presumably the pump has safeguards for that.

        The pump can work without the app - the app just provides an easier to use interface. There's nothing inherently safety critical to the app - if the app decides "user asked for bolus" then the pump will push once and then have a backoff timer - you need to protect against app malfunction as well as user malfunction (the user might be spamming the button multiple times - a very common event).

        Chances are, there were no safety concerns because well, the pump protects against them - the user is just as likely to spam the button on the pump as it would on the app, so there's no concern there of a bug causing the app to continuously request extra shots.

        The problem was, the app crashed, which had a secondary side effect no one really considered - that is, it caused the pump to use more power since its Bluetooth connection was being used a lot more. This had the side effect of extra battery drain and instead of lasting a day between charges, it might last say, 12 hours.

        This can trigger a recall because if the user expected to get through the day without needing to charge their pump, they probably weren't counting on it dying midway through. Probably took a fair amount of investigation as to why the battery life on the pump was suddenly going from good to horrible.

        That's why the phone isn't safety-critical. It didn't need to. it was just that an external device accidentally had bad effects on the battery life of the device

        • if the app decides "user asked for bolus" then the pump will push once and then have a backoff timer

          I'm not sure if you know, but if the blood sugar is low and you get an extra bolus of insulin, it can make you unconscious pretty quickly. The extra bolus is used e.g. after a meal to deal with the increase of glucose flowing to your circulation. An insulin pump is therefore is not like morphine pump for pain where you have predictable, constant safe upper limit and where missing a dose can cause pain but is not fatal, so yes, I think these apps for insulin pumps are truly safety critical, and should be dea

          • I guess the app needs to be approved by Apple like any app on the App Store, but also needs to be FDA approved. Which Apple canâ(TM)t do. But since Apple has more people with a deep understanding of iOS apps than the FDA, maybe Apple should rent some software experts out to the FDA to help them. With access to the apps source code, not just a black box.

            Such a software expert would have found software defects that make the app crash, and hopefully would have figured out that this will drain the devic
        • by AmiMoJo ( 196126 )

          Very likely the system consists of a microcontroller with certified code that limits the rate at which insulin can be administered. Then there is another separate microcontroller that handles all the wireless stuff and runs uncertified code. Even if it malfunctions and requests more than the safe limit of insulin, the first micro should ignore it.

          I wonder though how it handles a flat battery. Without power there is no way of tracking time, and this no way of limiting the rate at which insulin can be adminis

    • by geekmux ( 1040042 ) on Thursday May 09, 2024 @06:22PM (#64460981)

      It's hard to imagine trusting something so important to a program that runs on a consumer phone with a consumer OS and that communicates over bluetooth.

      Gonna be even harder to imagine the look on your face when you peel the FDA-certified sticker off the $5000 medical version “approved” by your insurance company, and find a Windows Mobile sticker under it.

      You’d be surprised as how “trusting” the alternative is.

      • At least that one would not be as defective as the ios version
        • At least that one would not be as defective as the ios version

          Depends on if the alternative is affordable for those suffering. A perfect $5000 solution isn’t one if you’re dead before you can afford it.

      • You’d be surprised as how “trusting” the alternative is.

        Trust is not implicit at every stage. Just because something runs on Windows doesn't mean it can't be trusted. The question of trust is how the hardware reacts to problems with the software. Safeguards, watchdogs, etc.

        The only thing dumber than trusting windows is the idea that any other software is more trustworthy. Most certified devices be they medical or safety are designed in a way not to trust its own software implicitly.

    • by mysidia ( 191772 )

      The screenshot of the app shows a UI for adding a bolus from the App itself.

      I would say that seems pretty darned safety-critical that the App can signal the thing to deliver more medicine.

      But also; the Pump itself ought to have a safeguard against needed power capacity for the expected runtime being taken up by the radio. I don't know what that would be... Maybe detect if the battery capacity is getting close to a level where it won't be enough for the remaining runtime, then power down the radio ear

    • As someone who is bothe a sw engineer and a victim of this issue, Iâ(TM)ll give a slight benefit of the doubt. The crashing use case that caused the issue would be hard (not impossible) to posit ahead of time. Iâ(TM)ll bet they have use cases defined for this now.
      • Typically, an evaluation of a safety critical system would include a fault tree analysis or similar. They might have uncovered this issue ahead of time had the thing been evaluated.

      • I wonâ(TM)t. This is close to the number one fault case for any device that does wireless communication. Anyone who has ever built a wireless communication device will have seen this problem hundreds of times, and should know it needs to be protected against.

  • by ffkom ( 3519199 ) on Thursday May 09, 2024 @06:19PM (#64460971)
    If in a sentence about an device your life may depend on the word "App" occurs... run... towards a different a different solution. "App" is synonymous with low-quality, low-reliability, hipster-style coding, where data harvesting for the vendor and optical design are everything and functionality and safety come way down the requirements list.
    • This app was written by the company that builds the pump it's connecting to. They already have access to all that data, and more.

      • by ffkom ( 3519199 )
        Does the pump include a wide area network interface to phone home the data? Or is it still the "App" that connects to the pump locally and then abuses the phone's wide area network connection to phone home the data? Pretty sure it is the latter...
        • It has a Bluetooth connection to the pump, and the pump communicates back info like your current bG. The app can be used to deliver a bolus (extra insulin for a meal). However! The app is only a convenience and isnâ(TM)t nec asset. This issue is an edge case where the app crashes, restarts, pulls data from the pump, crashes again, repeat. This causes the pump battery to drain quickly and shut down. That's the issue. Make sense?
          • by HiThere ( 15173 )

            The explanation makes sense. It doesn't preclude the GPs scenario, since the app is on a cell phone.

  • by PongStroid ( 178315 ) on Thursday May 09, 2024 @06:51PM (#64461063)
    Man. Canâ(TM)t remember the last time I commented on slashdot. I have this pump and app. Issue is directly related to unpredictable battery drain on the pump. A charge will usually last 10 days(ish) and once you hit 25% remaining, you knew you had at least 36 hours to top it off. Instead, the app as silently crashing - you might Inuit that it happens because your bG history is empty and it takes a few moments to download the data again. Anyway, the app keeps crashing and forcing a repeated sync with the pump which drains the pump battery really quickly. So, at 25% it could go down to 5% or zero in just an hour. You might not even get a low battery warning I know because it happened to me a few times and no alarm was logged. If the pump shuts down, it means you donâ(TM)t get the hourly base amount of insulin which can eventually lead to DKA. 2.7.1 didnâ(TM)t completely fix the issue but it hasnâ(TM)t happened as often. Which sucks cause I just had it happen yesterday buy at least it was during daylight hours. Deleted the app until they fix it.
  • by Errol backfiring ( 1280012 ) on Friday May 10, 2024 @06:05AM (#64461875) Journal

    Combining devices and apps is generally a terrible idea. When I see a sewing machine sold with an app, I can only wonder what the designers were thinking. The sewing machine should last for a lifetime, the app is almost guaranteed to be obsolete within a few years.

    Especially Apple has pulled a lot of tricks with backward-incompatible changes to what is allowed in the app store, with very short notices to app makers and therefore very error-prone.

    Combining this with medical devices is just insane.

    • Combining devices and apps is generally a terrible idea.

      Not really. Apps provide all manner of *added* functionality. The device in question functions without an app too. The insulin pump is self standing and works 100% without any app. The problem here is the battery running down because of a bug which can happen with an app just as easily as it can happen with any custom designed control interface.

      When I see a sewing machine sold with an app, I can only wonder what the designers were thinking. The sewing machine should last for a lifetime, the app is almost guaranteed to be obsolete within a few years.

      What the designer was thinking is *added* functionality. The sewing machine in with apps functions without an app too. For the most part the app / mobile part just m

  • So the application crashed repeatedly, and each time it did so the re-establishment of communications via bluetooth was costly to the pump's battery.

    To me that says the application sucks, the error handling and recovery method sucks, the pump's power usage is unreasonable for its deployment... the fact that it's hosted on iOS seems mostly irrelevant. The problem is bad end-to-end architecture. A crashing android version would exhibit the same behaviour.

"Trust me. I know what I'm doing." -- Sledge Hammer

Working...