"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."
If you wanted 0.66 units and got 66 units, I am pretty sure you would die. I would count on the tissue around the infusion site not having enough throughput to release it all into your system at once and swelling up. This would mean the problem would spread over a few hours, but it would be an extreme emergency anyway.
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...
Heh, yea, this is why when I went to DEFCON I disconnected the feed to my body. I mean it's not likely someone's going to try to murder me via bluetooth, but why take the risk when I didn't have to.
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.
For software like that, not sure how anything other than formally proven correct software is acceptable. And note, no type system is gonna help you with a bug like that.
With the right type system, any formal proof can be represented in it, and the type checker will verify the proof. Any fault that remains can also remain with a formal proof. Look up Curry–Howard isomorphism.
Type inference is largely orthogonal to the question.
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.
No, that's not the point. There is no point to a general type system without automatic type inference. Because otherwise, it's just a kind of cumbersome and cobbled together logic.
Theory meets practice. An automated theorem proves that knows about Android view hierarchy, Parcelables, Android kernel well really entirety of SELinux not to mention whatever Bluetooth firmware drivers seems quite a bit of boiling the ocean.
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.
In a way you are right, but all that stuff (Android, Parcelables, Android kernel) is garbage. Time to replace all of that with a proper formally proven stack. It's not that Apple or Google don't have the money to do that. They just don't have the will, knowledge and engineers for that.
I don't know very much about formal methods but I would assume the type system plays an important role for encoding that specific states can or cant exist.
But a high reading is a state that can exist. I don’t really see how formal methods would exclude a multiplication/unit error with respect to the displayed unit.
This is quite the overreaction. There is both a confirmation screen and a maximum bolus setting to ameliorate the issue until an OTA update can be provided.
Stranding users who use the app without access to our lifesaving medical device is... Bold, to say the least.
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.
What you mean to say is completely correct. What you actually said is wrong, there's a huge delta between hostile and unproven. The pump firmware should assert it's own safety and sanity checks. Which is different from hostility.
You are making the assumption that the app is the real app and that the app is under the control of the user. Both may turn out not to be the case so 'hostile' would seem to me to be the only proper classification unless the communications have ways of verifying that either of the above scenarios is not in play. Better safe than sorry with this stuff.
I think it should assume its hostile since physical harm could be done in the case of someone hijacking the app.
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!
My same thought, Max Dose in an hour setting should prevent severe hypoglycemia as a fail safe, but I did not see anything mentioned in the article about that on Insulet website. My son has this model but we use controller that comes with it, not the Android app, which is where the issue is. Closed loop OmniPod 5/Dexcomm is a game changer for Type 1 management. As a software developer I worry about this sort of thing but hopefully max dose fail safe gets this.
Wow, that seems extremely serious. In any reql engineering field, this kind of thing would have serious repercussions for the engineer, and not merely the poor consumer.
In any real engineering field, the engineer wouldn't compete for a job with "engineers" who went through a two month boot camp to be an engineer. They'd also have power to say "No" when a project manager insisted on pushing out an improperly tested product.
I know the department of defense used to use Ada because it was a “safety critical” language. I feel like when it comes to this devices there should be more stringent guidelines around coding practices. Is that not the case?
I smell unoxidized metal! I love rust, use it almost exclusively. And ferrocene just certified it for industrial and automotive.
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.
there are, that's why insulin pump firmware is developed using obsolete and error-prone methods by substandard engineers and why you can't get the source for your insulin pump firmware and reflash it with a bug-fixed version
I see where you're coming from, but I don't think letting anyone mess with the equipment keeping them alive is a good idea either.
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.
> 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 do, because not 'letting anyone mess with the equipment keeping them alive' is, obviously, condemning some of them to deaths that they would avoid if they were allowed to
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
I will say that my company did have an engineer that could write proper lock-free algorithms. Unfortunately, they were completely unable to retain him and he didn’t help matters.
There are: ISO 13485 and 62304. And different levels of design and testing for different classes of medical device.
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.
As someone working on Class III medical devices, it is true that the FDA does not check if your design is "safe", only that the documentation and process seems to have been followed, but on the other hand you are also required to monitor your install base and report any hazardous event, and in case no adequate remediation/plan to your adverse events, they have the real power to stop the commercialization of the product.
But I agree this is coming a bit late in the process if people have already been harmed.
I had the exact same thoughts and I was about to bring up this very same point. Ada is still use heavily in medical devices and even has a decimal type.
Why? Safety Critical Software engineers are expensive. If you write a webstack with Node.js and React to run the insulin pump you can hire web developers. They are much cheaper. And who would be able to tell the difference? Boomer lawyers and judges working on the lawsuit targeted against us won't understand.
Judges have the benefit of experts spoon feeding them information, and no deadlines other than the ones they impose on themselves. The judge I worked for wrote the panel decision throwing out the Communications Decency Act, at age 64. In addition to covering packet routing and caching, it did a pretty good job of capturing the decentralized ethos of the Internet: https://archive.nytimes.com/www.nytimes.com/library/cyber/we...
> 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.
That's the opposite of the conventional wisdom on the strengths of the judiciary, so much so that there's a norm that courts defer to legislatures on findings of fact, since they're so comparatively hamstrung at generating facts.
> That's the opposite of the conventional wisdom on the strengths of the judiciary, so much so that there's a norm that courts defer to legislatures on findings of fact
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.
> 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.
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.
No, they (the manufacturer) are saying that users might "inadvertently" enter and confirm an incorrect value, which is not the same as the users enters one value but a bug causes it to be parsed, displayed and confirmed as a different value. The latter is what the Tweet claimed. Very confusing.
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.
I can't comprehend how that kind of bug even happens. Not that insulin pumps should have any bugs, but it doesn't even sound like an integer overflow or use after free which is "understandable". Are they doing some kind of scuffed string parsing?
At my first job out of college, we were hired to create a point-of-sale system.
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.
We had a similar issue with random four-letter codes. The simplest and easiest solution was to remove vowels from the pool of candidates. Consonant only codes are much harder to generate real words.
I once worked on software that interfaced with Omnipods just to read and display its data and it was an unholy assemblage of Java applets, Pascal, and out of date C#. (The software that is, I think the Omnipod DLL was just C)
It's probably caused by a shitty spec instead of bug. Some PM insists that you must sanitize the user input 'when' user inputs. And '.' alone isn't a proper number. Which led you to this. No. You should NEVER change user input when user action is not finished yet. That's a giant UX hazard.
With low level devices, I have been amazed at how many hackish things are done by people who don't have sufficient experience developing such things. I would not be surprised to find out that they are parsing or storing the value without the leading decimal, and depending on code in some other place to prepend the leading decimal, and there be a corner case or something that misses this, and no safety checks or even sanity checks.
In the t.slim they have a maximum dose in time range setting on the device. I don't use the app for it, so I don't know if the phone app could override that setting. If I remember right that is triggered while pumping so if you hit the limit in the middle of dose administration it will stop.
People think it's a race condition. Not knowing anything about this or having seen the UI, I would guess it's something really dumb.
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?
I worked for a bank - a bug (arithmetic overflow) tried to charge a customers credit card for more than a million kabillion on a payment - thankfully it was caught upstream and declined.
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 :).
I'm not sure about this unit, but with my Tandem there is a maximum dose setting on the unit. I don't use the app to dose, so I have no idea if the app obeys that.
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.
I'm very curious to see this in action. Are you able to get a video of it showing typing in the dose and showing the confirmation screen missing the decimal point?
Both the Omnipod and Dexcom apps prevent screen recording. Possibly for user privacy, but I'm suspicious of that. I don't really have a way to get a second video recorder at the moment.
Yep, when you use something a few times a day it's very easy to get interface blindness. I use a t.slim myself and catching something like .10 and 10 is going to be very, very easy to miss. Probably need a leading zero like 0.10 to make it stand out. And even then most the time I'm clicking the conformations to get on with my life and do something else.
For those unaware, misjudging a dose of rapid-acting insulin by even a few units can prove fatal. Can’t fathom expecting a quarter of a unit and getting 100x the amount.
Oh good! I agree, perhaps some of it can be defined as a social good. I remember the idea that was posed of having government created social media. Something open source and with a transparent algorithm. I really can't see a downside if it's done well.
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.
Maybe, rather than "open source" it should at least be "source available"? I mean, to allow everyone to see what's actually going on, and spot possibly critical bugs. This doesn't remove the responsibility from the entity who accepts the legal responsibility for what the software does.
Eh. The bug is in the Android app. It is probably roughly as easy to identify this bug by staring at the dalvik bytecode as it is to identify this bug by staring at the source (though it is odd that this appears to be nondeterministic - hard to know why that would be the case).
This is a really really bad bug, but I don't think this is especially related to open vs closed source products.
No. Just saying that there comes a time where a company may be refusing to fix bugs because they aren't earning enough money associated with that software.
So, open-source may win there. It's worth thinking about it.
IIRC, both the ipod and the Zune media players independently ended up with nasty date/time bugs due to errors in open source libraries they used. More eyeballs can be a good thing but given the number of willing eyeballs and the amount of open source code, it seems like the effectiveness of eyeballs on code is going down. Probably still better than just company eyeballs but far from something that should be relied on to filter out defects.
It may well be, depends on whether anybody died on account of this bug. 100x... mindbogglingly irresponsible to not have multiple safeguards that caught this before production.
This device can hold up to 200 units of insulin in it's cartridge. I'm not familiar with it to say if it has any safety interlocks to administer some sort of max dose lower than that at a time though.
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).
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.
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.
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.
> 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.
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.
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? :-\",
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.
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.
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.
I'm not familiar with insulin dosing, but I'm guessing a sharp 10x jump should warrant my app telling me to go to the hospital?
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.
Good software would certainly include that kind of multi-layered defense. Insulin dosage does not vary by a factor of 100. Sadly, medical software is not written any better than any other software.
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.
I can't speak for Omnipod in particular, but insulin pump firmware is absolutely written with user error in mind. There is probably an entire team at the company ("human factors") that will do testing to make sure that the planned UX for the device would not (or, better yet, cannot) be misinterpreted or misused.
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.
I nearly died in my sleep 2 years ago from about 10 units unexpectedly releasing into my system from swollen tissue left behind by a broken infusion site. What the author describes is potentially lethal.
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.
Like all business communication (and communication in general, really): Fashion. While you occasionally find some trailblazers to set what is new in fashion, mostly people just copy what other people are doing.
Business people don't know what they are doing so they ape whatever they see other people doing. At the heart of a suit is a great deal of insecurity and fomo.
They are 100% mitigating risk. If someone suffers, or dies, the company is seriously at risk, and any communication needs to be as foolproof as possible from litigation. They have an obligation to release a statement (and greater legal risk if they didn’t) but want to avoid whatever litigation they can.
"Warning: Inattentive users could experience diabetic comma. If the user insists on diabetic comma, they might experience death. Completely their fault for not paying attention."
Now I know why my wifes insulin pump's (Medtronic) Android app doesn't support setting the bolus and only allows observation :D
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.
The app and firmware for the Tandem T-Slim were updated last year or so to allow dosage from the phone app. People on Twitter and reddit were very excited - finally! How convenient! My thought was wow, that is something I really don’t want at all, from a standpoint of possible bugs, security risk and accidental dosage. I don’t want someone who hacks my phone or insulin pump to be able to kill me. Of course, nobody on reddit took my opinion seriously.
From the twitter description it wasn't clear whether this was just a display bug or the device actually failing to record the user input.
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...
>I don't know why it irks me so much more than "normal" number entering
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.
Because there are countries that use '.' and countries that use ',' interchangeably and some are so messed up they use both. So entering pennies is the safest option.
One other thing to note here, with the Dexcom and Omnipod running together you really shouldn't be giving yourself boluses directly. Instead you type in the number of carbs you intake, and let the system make adjustments. In my experience taking direct insulin messes with the algorithm that tries to manage your sugar.
I suspect this is why this wasn't noticed immediately.
Hi medical software researcher / professor here. This is definitely a bad bug! I’d like to use it as a teaching example — any chance you could post a video of the bug? Especially one that shows how it sometimes takes the value correctly and sometimes changes it?
171 comments
[ 3.9 ms ] story [ 67.2 ms ] thread"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!
See: https://en.wikipedia.org/wiki/Therac-25
https://maude.innolitics.com/
But yes, this general type of event is inevitably what happens when the entire field prides itself in not having any standards.
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...
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?
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.
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.
Confirmation screens are notorious for becoming habituated and then ignored. Yes, even important ones.
https://alistapart.com/article/neveruseawarning/
♫ "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.
Note that these are marketed to children as well.
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).
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.
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.
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."
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 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.
I suspect this is why this wasn't noticed immediately.