My insulin pump controller has a bug
twitter.com
twitter.com
"Notified today that my insulin pump controller has a bug where the leading decimal point will be dropped, ie: changing a dose of .21 units to 21 units. I can reproduce randomly ~1 in 5 times so probably a race condition. Easily one of the worst software bugs I have ever heard of."
To put it into perspective (at least with my insulin to carb ratio, it varies from person to person), if you wanted to drink a regular sized can of coke, you would dose 3.3u. 66u is therefore enough insulin for 20 cans of coke.
Another way to put it is that 10g of sugar ~ 1u of insulin. You'd have to eat 660g of raw sugar.
There is a medication called Glucagen which is used to treat severe hypo. It works by triggering release of stored glucose from the liver. The thing is, from what I've quickly googled, a typical 1mg dose is usually only enough to raise your blood sugar by about 100mg/dl, and then your store is depleted and further doses have no effect. With my insulin/carb ratio, I would only need about 2.5u to reduce my blood sugar by 100mg/dl.
All of a sudden it feels scary to think that the reservoir in my pump holds about 300u of insulin...
In the days before I had a pump I did something similar to myself. I had a short acting insulin and long acting insulin both in pen form. Managed to give myself the large overnight dose which should have been the long acting with the short acting pen. After about 15 minutes I realized something was up when I felt the low coming on and spent the next 2 hours drinking a disgusting amount of orange juice.
I have had exactly the same experience. One glass of orange juice is great. 3/4 of a gallon.. not so much.
And Curry-Howard is the most overrated isomorphism in history. It may make computer scientists head explode, but mathematicians can live without it.
And yes, I know that Lean is based on it, and Tao is using it, and he just doesn't know better. Sorry.
The point is, any formal proof you could do outside a type system you can also do within a type system, so yes the right type system would help you avoid such bugs.
The actual device (not the app) does seem poorly engineered and not at all fail safe / provided with ‘might kill the patient’ error handling.
Seems like double whammy where an app and hardware conspire against its user.
(dose > MAX_DOSE) ? return DOSE_TOO_HIGH : return DOSE_ACCEPTED;
20 units is obviously dangerous for a single dose.
Stranding users who use the app without access to our lifesaving medical device is... Bold, to say the least.
https://www.northwoodsendocrinology.com/wp-content/uploads/2...
Presumably whoever provided you your pump has a similar instruction.
Risking using an app/pump combo that has a known flaw, especially a non-deterministic one is bold, to say the least. Safer to switch to the regular controller (assuming you have it) until this is fixed.
The users phone could be stolen, or the device compromised, or many other things. A compromised device should not be able to cause physical harm to a human!
edit: someone else already said basically the same thing but I didn't see it because I opened this tab a long time ago and didn't refresh it!
I love this - I've never heard the euphemism impact your experience used to mean that your life may end. What a wild PR assignment
(language off the company's safety notice https://www.omnipod.com/en-gb/fsn-11-2023)
"The issue only occurs if you don't notice it's occurring."
https://twitter.com/Tims_Pants/status/1730515134731182490
It's wild that this sort of bug got through testing.
As a diabetic it feels like our insulin pump software is very conservative and lacking in features especially compared to what some of the "closed loop" things would like to do.
That seems reasonable if the manufacturers are having to do lots of safety testing.
But if bugs like this are getting through then the testing obviously isn't anywhere near as robust as we'd like.
Also, since it happens intermittently with that kind of input I have to seriously question how the software is put together. If the input box shows the decimal there's no way it should slip past the parser. Something smells very wrong with how their app is put together, and that would make me concerned about other issues we just don't know about yet.
If I've just entered "0.21" then when the confirmation screen reads "21" it's not immediately obvious that it's wrong.
It's so much less obvious that I'm going to ask you to explain the difference to me because for the life of me I can't see it?
It happens when you put in ".21", not when you put in "0.21". If you omit the leading "0" it might drop the leading "." too.
That's exactly my concern. This is not the kind of bug that you fix and move on, this is the kind of bug that makes you go back, fix your process, ensure your QA would catch this next time and then you audit all of your code to make sure that your broken process hasn't missed anything else.
> Once the bolus dose is confirmed and you tap START, the value that is shown on the screen will be delivered by the system...
> As stated in our User Guide, it is important to review the bolus amount before you confirm and start the bolus. Omnipod 5 will always deliver the amount you confirm and that is shown on the Confirm Bolus screen (Figure 2).
Is this saying there's no way to stop it, even if it hasn't performed the injection and killed you yet?
"Hello, Insulet customer support? My Omnipod is going to kill me. Quick, what do I do?!?"
"Didn't you read our Guide?? Omnipod will always deliver the amount you confirmed! RTFM!! click"
--
Seriously though, what's the intended recovery procedure for this? Can the device be removed quickly? Batteries taken out? Emergency Stop?
Or are users expected to carry a firearm at all times to "rapidly disassemble" a murder-happy medical device? :-\
Totally agreed on the communications failure here, they all but blame the user for not noticing their error. That's not how a responsible medical device manufacturer should deal with this.
I mean, this is clearly a bug, but under normal operation it would be much much worse if the system silently overrode a user dose. People's insulin sensitivity varies a lot. A 350lb person may regularly dose 10 units for a single meal, whereas that dose would kill a small child. If you are 350lbs, and your BG is 400, in DKA, and you're dosing 15 or 20u as a correction, you do not want an automatic early termination of the dose.
You can always cancel a bolus in progress. The override/cancel bolus is likely the highest priority task in the entire system. In the worst case, you can physically disconnect.
Personally I want a (mandated) hardware Emergency Stop button, like any other machine with potential to malfunction dangerously.
A button needs protection from accidental activation, but fortunately that's a solved problem.
> You can always cancel a bolus in progress.
I sincerely hope that's true, but the documentation makes the intended behavior very unclear.
This is indeed a pretty terrible bug. I'm hopeful the confirmation screen prevented any real harm from being done.
E: I can reproduce. It seems to happen around 1 in 10 entries for me.
>I'm hopeful the confirmation screen prevented any real harm from being done.
Confirmation screens are notorious for becoming habituated and then ignored. Yes, even important ones.
♫ "You wouldn't demand open-source software for life-critical contexts instead of the industry-perfected closed software" ♫
The point is that with commercial software is that there exists an entity that accepts responsibility for it under threat of severe penalties.
You don't want somebody to be killed and then have just everybody shrug "it is not me" and not be able to find a culprit.
Personally, I always include a note that my software is offered as is and I do not accept any liability for anything that it might do including damage to property or somebody's health or life.
That, obviously, absolutely disqualifies it from any critical use.
But that's only fair, if I am not compensated for my work I should not be held liable for it either.
Now, once we find out the software pretty much must be developed commercially, there exists currently no way to force the commerce to make the code public and there are valid arguments in the debate that making it public could make it less safe.
There is no reason you can't hire a company to support free software.
This is a really really bad bug, but I don't think this is especially related to open vs closed source products.
If you do you haven't actually worked on open source software.
Even in critical software people just LGTM.
So, open-source may win there. It's worth thinking about it.
I naively assumed it was just failing to display the decimal point. But no, going by the manufacturer statement, the actual value entered and used will ignore the decimal point. You still have to confirm the (correctly-displayed-incorrectly-received-value). If you don't pay attention (because the last 10 times it worked) you might just die... That's unbelievable.
Aside: This is reminding me of the relatively-orthogonal-but-still-awful-imo-UX where entering numbers into payment fields (e.g. card reader or PayPal app) just floods in the numbers from the right, with every digit passing through the decimal places as you type. I don't know why it irks me so much more than "normal" number entering, but it just feels so wrong. I'm entering a quantity in (e.g.) dollars, but I have to type it as a number of pennies. Normally, entering the decimal point would disambiguate my intent clearly even if I type too few or too many decimal zeros...
Because it's a grievous violation of your (and presumably every user's; I know I hate those too) understanding of how a text field works. And certain types of edits are made significantly less convenient by that behavior as well.
However, the document states that "there is no defect identified in relation to the use of this product", which would contradict the Twitter post, so maybe it's a different product or either the poster or the document is wrong.
They're saying that since there is a confirmation screen, it's the user's responsibility to catch the bug.
this-is-fine.jpg
Also, why would you ever post about a potentially dangerous bug in a medical device without naming it? That just seems ... oddly sensational, to me.
They'd need 20 months to manage to notify users?
To my understanding this isn't the same type of bug. Tandem are just saying "it can be confusing to enter fractional rates".
This bug is for a different pump and is "when you enter a fraction rate it will change the rate". That is much worse
We wrote it in Javascript, being unaware of how Javascript treats numbers. (Like a rented mule.)
After the first few days, the client reached out and told us that the end-of-day numbers were sometimes off by a few cents - tax totals, things like that. After a few weeks, they'd be off by significantly more.
Easily the most embarrassing incident of my career, even worse than when I accidentally left a `console.log("FUCK");` in production code as a debugging tool, or when we wrote some code to generate random four-letter codes that would spew out the occasional profanity.
Like maybe every number is sent as it's own Bluetooth packet, but then when you hit enter, that's when the point gets appended.
Because of some other insanity that needed this as a workaround, like, I don't know, maybe it starts out already showing a dot, and the numbers you type go after that, and for some reason they
....and then the Bluetooth stack reorders the enter key and the dot?
Or, maybe the command is sent with the decimal at the end, I'm a packet with other stuff, and the packet length can vary based on the other stuff, and the calculation is wrong.
Or it's even more like Therac, and they have two modes, a 10x and 1x mode, maybe because there's some hardware interlock on the 10x, but they both interpret the value differently and use different units , and there's some bug in selection logic?
It's likely better that way. If the app would allow this, I'd already decompiled the app and tried to reverse engineer the protocol to allow her to set a bolus when she's wearing something that makes it hard to access the pump or carry her phone with her (like a dress). Setting the bolus via e.g. a smartwatch would be really nice, but I'd be very afraid of creating a life-threatening bug.
I'd expect medical devices like this to have a last line of defence safety check against bugs. Basically checking all common sense edge cases like: is this dose lethal to humans, is this dose significantly more/less than historical doses, is this dose below a level in which most humans would get no benefit. These are all easily testable both in terms of software testing and regulatory testing.
In this case, the firmware was probably written by engineers who don't think about possible user errors, because they are focused on the hardware. Meanwhile, the app was probably outsourced to the lowest bidder from Elbonia.
Also, other commenters here are insinuating that it's possible to wash your hands of something like this by just putting some text warning like "you should always check the dose before delivery." That is not true, neither for the FDA nor for the internal standards for the manufacturer.
The thing is, there is no such thing as a lethal dose of insulin per se. If you want to eat half a large pizza and wash it down with a can of coke, you'll likely dose 15 or more units. But dose the same amount and end up not eating your meal and you are in extremely big trouble within half an hour.
One of the reasons why I will never work in the medical field - too much real life consequences - wrong account entries can be fixed by journal entries :).
Even with the maximum dose setting there is a massive range of doses some people need, especially if they have resistance and don't manage carbs well. As others have mentioned in thread they use a 30u max dose setting, which for me would be around 1/3rd of the total daily intake.
And it doesn't sound to me like using rust or ada would have prevented this. It sounds like the android ui, which almost certainly is not in any certified toolchain, had a string handling error. The ui for a safety critical device is safety critical code, it sounds like that isn't how the rules actually work though, or you wouldn't be running it on a phone.
I really love open source IoT stuff for example and I think it's a great that people are trying to take real ownership of their devices. However it's different if the penalty for failure is your lights not working or immediate death.
I think a better solution would be if the source was required to be public so people can identify bugs, but without giving users the ability to flash.
That would be a solution, still has the problem of "how do you confirm the bug if you can't run the code".
Finding those kinds of subtle bugs pretty much requires you be able to execute it.
i think you would need an overwhelmingly large number of prevented suicides and avoided foolish accidents to justify such a monstrous evil
the balance of deaths is very likely to work out the other way around, in fact, because people reflashing their own insulin pumps have much stronger incentives to maximize their survival chances than any possible regulatory regime would, much less the one that actually exists
the policy of 'let us make laws and set up regulatory agencies to prevent people from harming themselves' has such an astoundingly bad track record that it always surprises me to hear someone advocating it in apparent seriousness
For example, I worked on a new ventilator at the start of the pandemic (https://www.cambridgeconsultants.com/press-releases/building...). As a medical device that was "in the loop" of keeping the patient alive, some of the strictest restrictions applied. There were 2 MCUs - one doing the control work, and another monitoring that first one, checking it agreed with the decisions and sounding an alarm if not. These two processors had to be different manufacturers, and had to use separate development teams (all to reduce the chance of a common mode failure).
The regulators are just checking you do the process though: does it look like you have done your design rigorously, and tested thoroughly. There's no way to check that you've done your design well though.
But I agree this is coming a bit late in the process if people have already been harmed.
> 11. No single entity -- academic, corporate, governmental, or non-profit -- administers the Internet. It exists and functions as a result of the fact that hundreds of thousands of separate operators of computers and computer networks independently decided to use common data transfer protocols to exchange communications and information with other computers (which in turn exchange communications and information with still other computers). There is no centralized storage location, control point, or communications channel for the Internet, and it would not be technically feasible for a single entity to control all of the information conveyed on the Internet.
Ironically, in this day and age of Facebook and Twitter, that’s probably not even true anymore in a practical sense.
There... isn't such a norm (at least not in the American system) courts defer to legislatures on matters of policy, not fact. There's a norm that appellate courts in most cases have some deference to lower courts on findings of fact, reviewing them only for unreasonableness, but nothing about courts deferring to legislatures about matters of fact.
That's very much an overstatement, and arguably even flat-out incorrect. See https://repository.law.umich.edu/cgi/viewcontent.cgi?article...
But yes, this general type of event is inevitably what happens when the entire field prides itself in not having any standards.
This is basically Russian roulette with insulin with even worse odds.
A typical pump will contain enough for several days. My pump right now has 100 units and is only half full.
The Omnipod 5 uses pods that the user fills with their insulin, the minimum fill amount is 85 units, the maximum is 200 units (i.e. 0.85ml minimum, up to 2mL of U100 insulin).
I suspect this is why this wasn't noticed immediately.
Note that these are marketed to children as well.