bjornoleh
commented
2 days ago Thanks for the report! I checked that the default is indeed to be off for a fresh install.
Open JELCRAWFORD opened 2 days ago
bjornoleh
commented
2 days ago Thanks for the report! I checked that the default is indeed to be off for a fresh install.
JELCRAWFORD
commented
1 day ago I think toggling off with fresh install is great. In our case (maybe an edge case) as we were switching back and forth from medtronic and omnipod there was no fresh install in between.
Might be good in the docs to alert ppl that the use case for this setting is most likely for medtronic (or any other tubed /pump). If there are other settings that are similarly specific to a tubed pump, then maybe a general identifier in the docs that they may not behave as expected in a patch pump vs. a tubed pump for which they were designed.
Just my thoughts though. :)
Equipment: Omnipod Dash, iAPS, Iphone 13 - at the time of this incident, we were switching between a medtronic pump and a Omnipod
At the time of the incident, the omipod was in use, but we had recently switched from medtronic as we were regularly switching back and forth at that time. Due to a prolonged low in the middle of the night, we suspended the pump for 1 hour. We were surprised to discover that the pump had resumed insulin deliver after only 10 minues. As a consequence, due to (-) iob the pump had reinitiated basal insulin and smb's as predictions were for a high bg - this was driving blood sugar lower and was an undesirable behaviour. This behaviour was repeated when we re re-suspended the pump and we observed the suspend be cancelled. In background, low blood sugar was due to increased sensitivity due to significant exercise, not the fault of the closed loop in general, and we had suspended the pump knowing there was (-) iob and wanting to ensure no more insulin was delivered until the low BG was fully recovered. In the end, the unexpected behaviour extended the duration and severity of the low.
We entered a bug report into iAPS as well as sent in logs as the pump did not stay suspended as we had expected. The problem/reason for the suspend could not be identified and, under the premise that nothing had been changed in iAPS from Oref, for this feature, it was closed. Over the following weeks, after reviewing multiple times and repeat testing whereby the suspend was cancelled immediately instead of at the set time, we realized that iAPS was cancelling the suspend pump due to the fact that we had toggled on the "Unsuspend if No Temp" setting when using Medtronic but did not turn it off with the Omnipod. Of course, Oref was not originally written for Omnipod, so this problem would not have been observed by openaps users previously. While it was a consequence of a toggled on feature that we should have toggled off, it also was easy to miss this and it could have created a dangerous situation, especially if we'd suspended the pump and gone back to bed for the hour.
The Unsuspend if No Temp feature is beneficial to medtronic users for times the pump is disconnected (ie. showering) so that when you put the pump back on it will restart delivery when the temp basal expires. This feature may not be useful for Omnipod users who do not have the reality of disconnecting the pump and would reasonably presume that if they have selected it to be suspended for a set time frame, it should stay suspended for the duration of time selected.
Describe the solution you'd like Ideally settings should specify that the behaviour of "Unsuspend if no Temp" is geared towards Medtronic users for situations listed above - times where a pump has been purposefully disconnected and may produce undesirable behaviour for omnipod users who have suspended. It should also be noted in written documentation as a warning to Omnipod users that this setting, when toggled on will turn off a pump suspend command based on the presence or absence of a temp basal, not necessarily at the end of the selected duration.