Buggy app for insulin-delivery device puts diabetes patients at risk of hypoglycemia The maker of the Omnipod 5 insulin-delivery system is warning customers that its controller device isn't registering decimal points in every case, potentially leading to dangerous doses being administered. Insulet says it received two reports of "adverse events" directly related to the issue, without detailing exactly what …
>>"However, many forget to test different scenarios where behavior is not normal, such as inputting invalid data into the system
If there only was a branch of Computer Science focused on tackling this kind of scenarios... I know: perhaps I can take some programmers aside and task them with testing, or assuring if you will, the quality of the software products.
I am so clever, no one ever thought of this before!
"The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers' ignorance before they started the job."
-- Douglas Taylor Ross, NATO Software Engineering Conference, 1968
"If there only was a branch of Computer Science focused on tackling this kind of scenarios"
It is part of computer science -- it's an element of algorithm design. The problem is that computer science is not being taught to software developers. Mostly, they just learn languages and the knobs, levers and libraries of dev systems. Software development is the sole branch of engineering where compliance with objective common standards is not required to 'qualify' as a professional.
Absolutely - always use a javascript library with almost the same name as one written by some guy, and updated randomly from a package repository when someone thinks it's a good idea to "improve" it.
Pro Tip: You can avoid single points of failure by using libs written by as many different random people as possible, so no one person is responsible for too many of your routines.
If you want to know more, my Web 2.0 advanced software reliability course is available on Youtube U.
I'm sorry to say that I often roll my own, because sometimes libraries can be *too* comprehensive for the task in hand.
For instance if someone were to type in an E instead of a decimal point, which could involve administering a very large dose of insulin.
(E being a perfectly valid input, in certain positions of a numeric string).
The Dash siftware isn't much better... I've not tested for this specific issue (for obvious reasons) but there is a bug in it where when you change a pod it doesn't lock until after the first bolus is administered (normally it locks when you turn the screen off like the cheapo android phone that it is). Not a big one but could be a pain if someone has a "play" with the device without you knowing.
Reminds me of my time at university:
Friend: "I've finished the end of year project. Can you test it for me"?
Me: "Sure <click, click, click>".
Computer: Core dumped
Friend: "It asked you to enter a number. Why did you enter qwertyuiop"?
Me: "Because you asked me to test".
I would have entered "a number", because that's what it asked me to enter.
Similar, when helping a friend test a program:
Friend: OK, the test machine has given you a number. Enter it here (points).
Me: OK ... ::types in "it<enter>::
Computer: Core dump.
Friend WTF! That's not what I told you to do!
For those unfamiliar with diabetes, the symptoms of of severe hypoglycemia are confusion and anxiety followed by coma and possibly death. The treatment -- Glucose. 15 or 20 grams. Perhaps followed up by more Glucose or some starchy food. The starch breaks down after a while into more Glucose.
From Honolulu to Vienna and all points in between lawyers are sharpening their pencils. And their knives. They are smiling. 2024 may be a very good year for lawyers.
2024 may not be such a good year for diabetics and for Insulet shareholders.
This post has been deleted by its author
In between confusion and coma, also likely to encounter sweating, rapid heart rate, and eventually seizures which don't respond to conventional treatment.
Footnote: electroconvulsive therapy (still in use for psychotic depression, because, well... it sometimes works) was preceded by insulin convulsive therapy. Which had the downside that sometimes people didn't come out of the hypoglycaemic coma. Some bits of the brain don't respond well to even a very short absence of glucose.
The history, even quite recently, of treatment of severe mental illness was quite experimental and quite barbaric.
In between confusion and coma, also likely to encounter sweating, rapid heart rate, and eventually seizures which don't respond to conventional treatment.
I've had a lot of mild hypos recently (I'm T2 diabetic, GP put me on gliclazide which increases insulin production and, initially, I was taking one in the morning and one in the evening. Trouble is that, unless I ate more food than I wanted to, I'd get hypos during the night.
I use Freestyle Libre 2 monitoring patches and the app will generate an alarm if blood glucose drops too low.
I now take both gliclazide in the morning so, mostly, the overnight hypos have gone. And my sleep quality has improved!
《The history, even quite recently, of treatment of severe mental illness was quite experimental and quite barbaric.》
Ghastly pointless lobotomies with ice picks aside, horrible as ECT is I don't think there were any effective treatments for severe endogenous depression and ECT was an improvement on insulin shock. ECT is still used - I guess its a NMI which resets the registers and clears the ram.
Surely someone a has a chunk of formally verified code to capture floating point numbers? This is a safety critical application. Running this on an android device is a bit like trusting a chatgpt brain surgery robot to remove a brainstem tumour.
How did diabetics calculate insulin doses previously? I would think a paper worksheet and a calculator might be more reliable. I hope ICU staff aren't using some dodgy android app to calculate acid/base corrections.
You know how many units of insulin to cover 10g of carbohydrates. You know what the amount of rice that contains 40g of carbohydrates looks like, or you weigh it out. You know how many units of insulin you need to cover a particular delta of desired blood-sugar level. And you perform some mental arithmetic. (Naturally you would never ever multiply by a fudge factor just because you know that you're unwell today and will probably need more insulin.)
Naturally it helps to choose nice round numbers. And it helps to know that a 10% error is probably not the end of the world. A 1000% error, on the other hand, is very scary.
"Surely someone a has a chunk of formally verified code to capture floating point numbers?"
Why does it need to be floating point surely fixed point would do in this case? Its not like you need a huge range or to have high precision. The more limited the input string is the better, an input string in decimal fixed point with a limited range and precision is all you need whether you then calculate the values using fixed or floating point and binary or decimal. Furthermore sensible error handling messages and range checks/confirmations within that limited range for excessive or unusual values would be desirable.
"This is a safety critical application. Running this on an android device is a bit like trusting a chatgpt brain surgery robot to remove a brainstem tumour."
Whilst android is overkill if it is a mobile app you run on your phone it's also one less device to carry. Furthermore you can then typically provide a better UI with better history and better error/confirmation messages.
Diabetes devices have really come a long way , we have insulin pumps, finger prick glucose monitors,continuous/flash glucose monitors that go on your skin and pierce the interstitial layer of your skin and last for upto 14 days or are implantable and last longer. When you combine the two you get an artificial pancreas system like ÀPS or openAPS.
> Diabetes devices have really come a long way , we have insulin pumps, finger prick glucose monitors,continuous/flash glucose monitors that go on your skin and pierce the interstitial layer of your skin and last for upto 14 days or are implantable and last longer. When you combine the two you get an artificial pancreas system like ÀPS or openAPS.
That's a marketeer's misuse of the term "artificial pancreas". What you're talking about is merely an insulin pump with some automation. Scary.
A real artificial pancreas would be an implantable device which produces (the right amount of) insulin. Trouble is, that wouldn't make obscene profits for the pharmaceutical companies, so they won't develop it.
And we haven't come a long way at all in Type 1 diabetes treatment. There have been no Earth shattering developments in the 58 years I've been in this game. I needed one injection a day then, I need three now. So much for progress. The expectation then was that insulin injections would soon be a thing of the past. Hah!
"A real artificial pancreas would be an implantable device which produces (the right amount of) insulin. Trouble is, that wouldn't make obscene profits for the pharmaceutical companies, so they won't develop it."
That's not entirely true: The implants can't produce insulin, so would need a reservoir, so the focus has been on fixing the issue with the pancreas and that needs an understand of what causes the issue in the first place. Last I heard was it's an auto-immune response to a virus that triggers the immune system to attack cells in the pancreas, so if true, the reason why that happens needs some attention.
But funding has mostly been on Type 2 diabetes as that's more common. However, as that's reached a point where they think Type 2 can be put into remission, the focus is moving more onto Type 1 now.
So here's hoping they get some positive results on type 1 now and that insulin injections won't be needed for much longer.
And yes, Type 2 here, and happen to know a few diabetic nurses (more now since I've been diagnosed, and hence introduced to them), so been having some very enlightening chats about what's going on.
However, as that's reached a point where they think Type 2 can be put into remission
Colour me sceptical - my GP (conveniently) is a diabetic specialist and he hasn't heard of it..
(T2 diabetic (non-overweight - just bad genetics inherited from my mother) for 30 years. )
The problem isn’t insulin. Pricing of artificial insulin is an issue in the USA, but elsewhere in the civilised world, availability of insulin is not the barrier to more effectively treating diabetes.* The problem is glucose detection. Right now, detectors all rely on an enzyme whose useful life is quite short. Recent improvements in signal processing have got that lifetime up to 14 days or so, but the sampling frequency is still very low.
A purely electronic detector would allow minute-by-minute monitoring, so that existing insulin pump could regulate blood sugar just as smoothly as a healthy pancreas. Sadly, everyone who’s tried to solve this problem has drawn a blank, and it’s not through want of trying - it’s the one thing in medical research that would guarantee you a Nobel and enormous wealth.
__
* there is an optional comma after “elsewhere” in that sentence.
The problem _is_ insulin. It doesn't cure the disease. We've had insulin, as a drug, for over 100 years now, and we're _still_ having to use it. There have been no advances in insulin (and its analogs) formulation in the last 50 years. What we have now is no better (and in many cases dangerously worse) than what we had then. Where, for example, is the insulin formulation which works more strongly when blood glucose is high than when it's not? All the new insulin analogs are merely me-too drugs which replace their predecessors when their patents are about to expire.
Your proposed solution of "more effectively treating diabetes" by wiring diabetics up to machines 24 hours a day would merely exchange metabolic problems for severe psychological ones. It is in no way a cure.
Just watched a recap video of the radiation therapy device with a bug that led to six deaths back in the 1980s.
For all of the regulations touted around data privacy in healthcare, one would have hoped that episode would have been enough to prompt something similar for required development practices in medical device embedded software.
I was once asked to review some code for an embedded medical device (I never knew what it was) that had a radio to allow settings to be changed.
The code for message processing was split over a number of functions (and mainly used global data), so was a nightmare to follow.
I came to the conclusion that byte 'n' of the message defined the number of bytes that would be received into a 15-byte array - there was no code to validate that 'n' was correct, and the radio channel was not secured...
How crap do you have to be that you cant even parse text into a number ? How can this even pass any quality control process ? Surely the leaderhip who claim bonuses for their company's achievements need to also be personally responsible for pathetic efforts like this. Jail time for all involved.
What kind of a complete idiot is still writing their own numeric parsers? Okay, now I’ll sheepishly hold my hand up and say “me”... because I’ve had to work with fixed-precision maths on microcontrollers. And that’s what’s happened here, I think. The device most likely uses only integer maths, so the “decimals” are possibly held as millis (i.e., three digits of decimal precision).
That is, however, not an excuse for this bug - you’d have to go out of your way to not automatically handle what happens when you get to the decimal point, regardless of whether there’s a digit in front of it or not. The only way I can think of is that the values are always less than ten, so someone is padding the end with zeros, doing replace(".","") on the string, then passing the result to whatever passes for atoi() on their platform and using that as a millis value. That’s so much fucking harder, more longwinded and more error-prone than actually writing a proper conversion function, so I suspect it’s exactly what happened.
But even with such a bodge of a solution, the most basic of unit testing should have found this; let alone quality assurance testing. That’s where I get angry: I don’t know how they’ve managed to skate around the approval process for medical devices, but this is a clear safety-of-life issue and one that should have been found with even the most rudimentary of testing.
The manufacturer should at least be hit with a massive fine, if not a charge of criminal negligence. Agile development is fine when your fuckups misalign some text on a form; when they put people at risk of potentially fatal hypoglycaemia, you need to take a bit more fucking care and think before you hit “deploy”.
Please don’t get me wrong.. by speculating on what may have happened, I am in no way condoning this kind of thing. Regardless of “why”, this is unacceptable behaviour by whoever wrote it, whoever was supposed to test it and whoever was responsible for the company releasing it needs to be hauled over the coals.. someone could easily end up in hospital (or worse) as a result of this laziness.
Putting all of this on the developer would be a dick-move: maybe they didn’t know their own limits, or maybe they did but were distracted or overworked - I’ve worked with brilliant programmers who have let stupid bugs creep into their code. Requiring every single person to be perfect all the time is not a solution.
First, accept that people will make mistakes, no matter who they are, and put in place a process to catch and fix those mistakes whenever they are found. The failure here is with the company management for assuming that their code would be fine just because the developer said “it works”, as if the dev had enough time to comprehensively validate that.
Of course the developer is to blame, they wrote the code. The next to blame are those thaat are supposed to be managing the project and that also include sthe QA part of verification. After that the upper management that selected the team should also be to blame for guess what selecting team or not givint them adaquate time and resources etc.
You sound like you want to let everyone off because its too hard, thata doesnt cut it when y ou have peoples lives as your responsible. Your attitude is part of the problem.
A Rabbi, a horse and an aspiring actress walk into a simulated bar test environment.
The Rabbi says "What, no real beer? I'm outta here!" and leaves.
The horse pisses on the floor, with the splash killing the development server.
The DevOps manager hits on the aspiring actress and is immediately rebuffed, so he tries again. And again. And again ...
Management ships the untested prototype software from last month on Pilot build hardware to meet Sales' goals and declares the quarter a success.
Maybe as many as possible of us should contribute to the CISA Request for Comment on Secure Software Development Attestation Common Form as the present proposals essentially concentrate on "cyber attack" protection and the NIST standards relied on hardly stress protection against this kind of (logical) hazard. It closes on 11 Dec. so we'd have to move fast.
The other part of the problem is why is the device carrying so much extra. Insulin needs to be refridgerated, because the longer it is warm the more it is destroyed and its effectiveness reduced. I would have thought that the device would have carried small amounts and required frequent top ups instead of carrying such a big unnecessary load.
Its like milk, parents wouldnt carry 30x the amount they need for the day that doesnt make sense, becque milk goes bad and all that.
They are from the Greek, not the Latin.
Essentially, "hypo" means under, 'hyper" means over. The Latin is "sub" and "super".
The word boffins say that the roots of the Greek were from the proto-indo-european upo and uper.
There is very little difference in meaning other than position, thus similar words.
Is your showerhead a hyperdermic?
"The health and safety of our customers is our number one priority. " - it clearly is not.
And all inputs need to be sanity-checked. if a value 10x bigger than expected is about to be dosed, it really - REALLY - needs a double check. The unit could beep until the user confirms. ANYTHING but dose too high!
This is really basic stuff and smacks of poor design, and programmers who work isolated from the full product. They need to do a lot better than this.
I don't use the omnipod but I have a max dosage set on my pump as a fat finger warning. I would expect that Omnipod does the same thing.
Pumps are only just starting to release software to allow management from a phone app rather than just reporting - I hope this doesn't give the manufacturers cold feet.
You got to be kidding me
1) where is the testing
2) assume the users entering the data knows nothing
Normalize the data ( this is taught in CS101 in 1980’s, yes)
3) who approved this ( agency)
Reason to hire experienced developers and testers
The company should be shutdown, as they are dealing with people’s health (life)
I just saw leap year issue REALLY it goes to show the level of coders ( again this was taught in CS class in 1980’s. We had leap year in 2016 and 2020 so the systems were update/developed with in the last four years. The developers and testers should be fired
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
