I just received an email from Insulet advising of a bug in the Dash PDM software, so far as I can see no one has posted this yet. The summary from the email is:
You are receiving this letter as our records indicate that you are a current user of the Omnipod DASH™ System. As the manufacturer of the Omnipod DASH™ System, customer safety is Insulet Corporation’s top priority. In line with this, we are writing to you with important safety information regarding the Omnipod DASH™ System’s Bolus Calculator. It has come to our attention that in certain scenarios described below, there is a remote possibility that the Omnipod DASH™ PDM (Personal Diabetes Manager) may suggest an insulin bolus amount based on incorrect information. If the user is not aware of this issue and delivers the bolus, it may result in over- or under-delivery of insulin, which may lead to hypoglycemia or hyperglycemia.
Somewhat ironically a few minutes before I got this I grabbed two screen-shots of the PDM Bolus Calculator going badly, but obviously, wrong. It may be related but all I did to get these screenshots was to enter a BG in the bolus calculator!
Notice that the correction calculation is correct in the second picture but the result is displayed as 0. I don’t know if this is related, but it seems to be the same area. I did a complete restart of the PDM when it happened.
I’ve also noticed the PDM slowing down; sometimes it takes seconds to enter a single digit into the “carbs” field of the bolus calculator although other fields (like entering a BG) seem to work without major delays.
Thanks for the info. I had not heard about this yet.
Their write-up is comical:
If the user is not aware of this issue and delivers the bolus, it may result in over- or under-delivery of insulin, which may lead to hypoglycemia or hyperglycemia.
The bug that Insulet found isn’t particularly serious. In their bug the “old” BG is used for a correction bolus, but think about the math; no corrections have been done meanwhile, delivering a correction “late” merely results in over correction by the amount of glucose that we have pissed out in the intervening period.
On the other hand the bug I found definitely seems to be serious. After all, for their bug they say (emphasis in italics added by me):
How do you prevent the user from giving an inaccurate bolus?
Always follow instructions on the Omnipod DASH™ PDM screen. In Scenario 1, selecting “Yes” or “No” when prompted to confirm the cancelled bolus will prevent this situation.
Always enter a current BG into the Bolus Calculator before giving a bolus. This will replace the old BG value and ensure an accurate dose is calculated based on the current BG.
Always check the “Calculations” before initiating the bolus. The Total Bolus should always be the sum of the Meal Bolus and Correction Bolus.
But my screen shots show this is not true; I did enter a BG but it miscalculated a correction of 0IU when it should have been 3IU. That is a massive under correction. Of course I don’t know if the PDM would have done that because as soon as I saw it I rebooted it (after the screen shots); no way was I going to experiment with a bug like that.
UPDATE: I tried to submit a bug report but there seems to be no way to do this. Their “contact us” form doesn’t actually allow any significant amount of words to be entered! So I posted a link to this thread
Thanks for reporting that, also if you don’t get satisfaction from Insulet and you in the US, you can always go this route to report the issue. Of course you need to pony up for a stamp or use a fax.
Voluntary MedWatch Reporting for Patients , Health Professionals and Consumers (Form FDA 3500):
Complete the MedWatch Online Reporting Form.
Download form or call 1-800-332-1088 to request a reporting form, then complete and return to the address on the pre-addressed form, or submit by fax to 1-800- FDA -0178.
I’m going to call customer service because I had a “PDM Error” 05-10351-06451-008 after the above problem and my PDM seems to be slowing to a crawl. I had also had one on Feb 11, 05-10365-09748-008, but that was at 4AM in the morning so I just rebooted the PDM and ignored it…
Well, I’m on the 'phone to customer service and the guy I’m talking to doesn’t even have a way to enter the URL of this thread into the log! Wow.
UPDATE: eventually got off the 'phone after a callback from the supervisor, who was able to take a note of this URL. Filing software bug reports over the 'phone just doesn’t work; there is too much information that has to be recorded in a very precise way, which is why being able to file reports as written text with pictures (if available) is essential. It seems a little sad that Insulet don’t have a simple bug report form on their web site.
Eventually (this Monday) I got the new PDM; I found a box sitting by the gatepost which, on examination, contained a PDM (nice, small, packaging, no instructions) and yet another Contour Next One meter; so that’s 10 test strips for free
I believe I will also receive yet another PDM in March because of the published software issue. I guess they are dirt cheap; they cost less than the price of two pods based on the Amazon retail price.
The new PDM hasn’t shown the crashing bug or the slow-down bug. Of course I don’t know whether the bug is the result of extended use and gradual memory fragmentation on the phone or whether it is simply a bug in the PDM software, but it is “permanent”; rebooting the old PDM did not make it go away.
For those of you who might see similar problems the test for the bug I found is as follows:
Reboot (“restart”) the phone, just in case. [Hold the power button until the PDM flashes up the shutdown/restart menu then choose "restart’.]
Swipe up/log in.
Tap the “Bolus” icon at the bottom of the screen.
Tap inside the “Enter Carbs” box at the top left.
Observe: a numeric entry pad pops up at the bottom of the screen.
Tap “1” then “2” rapidly on that entry pad.
Observe: EITHER:
A) The digits appear almost immediately in the “Total Carbs” box, or;
B) There is an obvious delay, I observed up to about a second, before the digits appear.
7A) means no bug, a working PDM. 7B) is the bug. Customer support will probably try to suggest it is a touch screen problem but it is not; it only happens in that box on that screen.
@jbowler,
Can you do a bolus without entering BG or carbs?
What is the minimum number of presses you need to just take a bolus? Curious about that.
On the old PDM - including powering it on - I can bolus with 8 button presses.
If the phone is off, and you need to wake it and unlock it and bolus, how many presses does it take?
Also for the Tandem users (who probably won’t venture into this thread), what is the minimum button presses you need?
(@Chris, might be cool to have tags people could opt into. Like if a Tandem user wanted to be included in a @TandemUser tag, they could opt in and would see that. We could also have a @OmniPodUser tag, and a @Dexcom user tag, etc…)
If it can be done, I would propose things like DexcomUsers, TandemUsers, OmniPodUsers, MedtronicUsers, AfrezzaUsers, MDIers, LowCarbers, Loopers, DParents, etc.
Maybe a useful discussion for the Lounge if there is interest in something like that.
Yes. The bolus calculation screen has three fields; one for carbs, one for BG and one for the total bolus. The latter can be entered directly and overridden.
So far as I can see the “PDM error” which caused me to report all this stuff to Insulet is caused by something going horribly wrong in the bolus calculation. It seems to happen after I had entered a BG (on a separate screen provided for this purpose) and this had been returned to the bolus calculation screen. The slowed-down data entry problem only happens on the carb entry field. So the bolus entry field may well be immune to the bug, or bugs.
From the home screen it requires 6 key presses if it is done as a single digit carb count or a single digit entered into the “total bolus” field. It’s quite a lot more to enter a bg because of the extra screen and the extra digits in the bg, however bg entry has a weird circular slider to enter a bg by dragging and this also comes to 6 finger operations, if you regard operating the slider as one. (I find the slider unusable; I’m right handed and it is necessary to grab a disk on the bottom left which means my hand obscures the readout.)
Getting to the home screen from an “off” Dash PDM requires another 7 finger operations. So on the Dash PDM the minimum is 13 finger operations.
