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.
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
Who could have ever predicted that connecting a life saving device to a machine most people use for watching 6 hrs of TikTok could be a bad idea?
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…
Even worse, what happens when someone unscrupulous discovers an exploitable bug. That would be a nasty piece of ransomware, quite literally your money or your life.
Well it’s either that, or another proprietary, not right to repair device, with it’s own downsides.
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.
Not everything needs to be, or even should be IoT. Especially with a “fail-deadly” configuration in the event of disconnection.
But I though Apple never crashed…
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.
That joke is much less funny then back in the OS7/8 days.
Back then MacIdiots didn’t even understand that we were laughing at them, not with them.
Ok, so someone made a thing that will kill you if the battery dies and you do not notice it and no one put a beeper in it like a $6 smoke detector?
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! humans are stupid.
https://en.wikipedia.org/wiki/Therac-25
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.
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.
This kind of reminds me of Robin Cook’s novel Cell.
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…)
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.
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.
“, 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.
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.
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.
Context: I’ve been working on some broadly similar things and have attended talks by the original design team, but have no financial interest in this product.
The phone component is basically what you said it should be. The whole system is supposed to be a closed loop controller, but in diabetes, you have delays in the system (I want to say that it is on the order of an hour) — plus unpredictable humans — that make simple versions of control theory difficult. The phone is a pretty good interface to do things like enter in things like “i’m about to exercise” or “i’m about to have a meal” which need to be communicated to the controller. That, plus data transfer to a web portal and visualization, is it. i.e. no direct control of the insulin pump. The problem seems to be that the phone was waking the controller up too often. It’s supposed to be every half hour, but this is more like however long it takes the app to crash.
Is it encrypted? Or anyone can connect?
It’s encryotee