[omh]

A clearer description of the bug is here:

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.

[schiffern]

The user-blaming stands out in their official communication. Bad sign for company culture.

> 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? :-\

[jacquesm]

You can pop the pump off on a moment's notice (there is a needle sticking out of the pod at the back, some other manufacturers use an umbillical that can be disconnected).

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.

[schiffern]

Thanks, good to know. That's something at least!

[jacquesm]

These wearable pumps, especially in combination with closed loop are a very interesting and important medical development that can improve quality of life for a huge number of people, but these sort of fuck-ups are really concerning. Inexcusable, especially because they have failed on multiple layers (code review, automated testing, acceptance testing, firmware development). Shocking, really and it makes me wonder wtf is going on at that company software development wise.

[mlsu]

On the flip side, what behavior would you prefer? The pump to not always deliver the amount you confirm?

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.

[schiffern]

> On the flip side, what behavior would you prefer?

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.

[peteradio]

In case of buggy interface behavior violently rip device from torso.

[fabian2k]

The part that makes this even more dangerous than this description might indicate is that it appears to be somewhat random. So most of the time entering a value as e.g. ".5" would work, but sometimes it would not. This is probably more dangerous than if it would always fail to do that, as the first few times you use it you likely pay much more attention to the confirmation dialog than later when you're used to it.

[phkahler]

That linked description is very interesting. They list 3 steps that need to happen to get an incorrect dose. The 3rd step is that YOU confirm the dose. The next section emphasizes the importance of confirming it. That's all great, and yeah, the user basically hit OK but that does not change the fact that they have a software bug.

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.

[jacquesm]

> that would make me concerned about other issues we just don't know about yet

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.

[omh]

Also it would be very possible to misread the confirmation.

If I've just entered "0.21" then when the confirmation screen reads "21" it's not immediately obvious that it's wrong.

[WirelessGigabit]

It doesn't happen when you put in ".21". It happens when you put in ".21". Little less obvious.

[jacquesm]

> It doesn't happen when you put in ".21". It happens when you put in ".21". Little less obvious.

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?

[WirelessGigabit]

Okay I even made the mistake here.

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.

[jacquesm]

That makes more sense, thank you for the update.

[WirelessGigabit]

This reads like a form validation gone wrong. Like it's set up to parse "0.21" correctly but not ".21".

[alaaalawi]

for these critical applications which require reliable oprations as lives are at stack. formal verfication will help by reducing bugs more than traditional testing. they are not bullet proof but still better. z notation is one of many.