Issues with the Omnipod 'suspend' option and why it shouldn't be used where 'temp basal' can do the job

Diabetes Technology Insulin Pumps
1

On Tuesday I went swimming/diving with my Omnipod. As is normal I entered the water with a blood sugar of about 150 mg/dl and, before doing so, suspended insulin delivery for one hour.

Well, it took 53 minutes to swim/walk up the river to where we wanted to dive and, at the end of that time, the pod was beeping about the end of the suspend. That's fine; a resume then would have started raising my insulin levels in about half an hour.

Unfortunately, however, according to the Omnipod manual even though the pod is beeping every few minutes and (therefore) knows it is time to resume delivery this doesn't happen.

Well, we did the dive and swam back down the river and, by the end, I felt my insulin level was pretty low. It was difficult to be sure because the water was only 70F and so we were both also cold (we had hoped for higher temperatures.) My blood sugar was 100 at the end and, of course, I immediately resume insulin delivery. (I might have needed some food if the basal had resumed.)

The problem is that had there been any delay or accident I could have been stuck up river for a lot longer and then the suspended basal would be a serious problem.

It's an issue for any outdoor activity where carrying the PDM is not an option. The issue is created by the Insulet design - it makes no sense to me to limit the suspend time to 2 hours but then not resume after 2 hours have elapsed! Indeed, what is the point of entering a suspend time at all?

So far as I can see the practical answer to this is not to use suspend except for those pieces of broken PDM behavior that require it (correcting the clock.) Instead it's really only safe to use a temporary basal to set insulin delivery to "off" for the required period of time, or maybe program a complete modified basal scheme with a really low basal rate (0.05IU/hour - the minimum.)

After the event I remembered that in the past I have used the 'temp basal'. In fact I've use a 0 rate temp basal for 8 hours and simply cancelled it when I no longer needed it, though given the possibility of being stranded without access to the PDM I don't think I'll do that again either.

What I'm going to experiment with in the future is a 1 hour temp basal 'off' combined with a basal program that runs at a fraction of my normal basal (probably one fifth - 0.1 IU/hour - initially). I want enough insulin to perform basic functions without so much that I have to eat large amounts of food to keep my blood sugar up.

John Bowler

2

Hi John! I always felt that the suspend delivery option was a good one on occasions where my glucose was dangerously low. Were I to lose consciousness, while alone or alone with my young daughter, it would be best that the insulin delivery not resume until I was conscious to prompt it to do so myself.

Otherwise, I use the temporary basil so the insulin delivery will resume on its own.

3

Thanks for sharing. Good point.

4

I have wanted to use the suspend at times when I am going to bed and a little low. I don't want to have to wake back up and confirm the ok. Also I don't understand why there isn't a resume and/or don't resume option. Since my basal won't decrease to 95% - only 90% - (I think why it won't decrease any further has been discussed before -having to do with the basal setting I think.) suspend would work better for that and keep my dexcom from alarming at that inconvenient time.
I get the unconscious point though.

5

I agree. It's a quick easy option and it does the right thing for low blood sugar.

6

John, you point out a very important distinction between the operation of the SUSPEND feature, and the operation of the TEMP BASAL feature.

I do think we're being a bit hard on Insulet about this, however. Rather, I think they've done the right thing by offering flexible features that allow for suspension with automatic resumption (temp basal), or suspension requiring user interaction to re-start.

It would be far worse if we didn't have both choices. Further, I don't think the suspension feature is really intended for managing basal for different circumstances, like exercise... That's what the temp basal feature is designed for.

Remember the suspend feature is "suspend all insulin delivery" -- it stops any extended bolus you've programmed as well, which in theory shouldn't be interfered with regardless of what you're doing -- you ate that food, it still needs to be covered.

Rather, I think the suspension feature is for exactly the sort of thing you posted about: Issues, like changing the clock, that require the system be inactive while performing that operation.

7

>Remember the suspend feature is "suspend all insulin delivery" --
>it stops any extended bolus you've programmed as well

Well, yes; it permanently cancels it without warning you. Another reason for not using suspend.

This is a real problem with the suspend functionality; if you have to change the clock while an extended bolus is active the bolus is killed. You only find out afterward; there is no warning. If there was a warning it would be possible cancel out of the suspend, go back to the main screen, write down the remaining bolus on the side of the wall of the immigration area, suspend, change the clock, resume, re-enter the extended bolus, scrub the wall of the immigration area clear of the ink and resume your place in line...

The system doesn't have to be inactive to change the clock; it's just a clock. Neither does it have to wipe the temporary records when the clock is changed.

John Bowler

8
Well, yes; it permanently cancels it without warning you. Another reason for not using suspend.
This is a real problem with the suspend functionality; if you have to change the clock while an extended bolus is active the bolus is killed.
I agree 100%! It's a bad design in that respect.

Further, I believe you've suggested the enhancement elsewhere in other discussions that boluses should be restartable after a pod change too -- a missing feature that baffles me. I ate the food -- now I have to go through a bunch of mental gymnastics to ensure I cover what I already ate and "took care of"? Ridiculous.

9
The system doesn't have to be inactive to change the clock; it's just a clock. Neither does it have to wipe the temporary records when the clock is changed.
Not knowing the design of the system, I can't say. However, being familiar with very inexpensive SOC chips (like the PIC as an example), it doesn't surprise me other operations being performed by the pod must be suspended to change the clock. I highly doubt there is a real-time clock IC in the design (way too expensive).

However, it isn't impossible -- probably simply an engineering trade-off, given that changing the time of day is a relatively rare event in the overall operation of the system.

10

I think it's just mis-design in the PDM. I'm sure the pod doesn't have a clock; it does everything in time relative to activation.

I believe the issue is that basal programs are, effectively, programmed into the pod and that means they really operate in relative time - not by time of day. The PDM design solves the wrong problem; there really is an issue when handling basal programs while changing time zones because our own biological clock doesn't suddenly update when we update the PDM clock!

I haven't tried changing the clock while the pod is out of communication range (tinfoil over the pod). I think I'm going to try that to see if the PDM will let me change the clock when there is no extended bolus but the pod is incommunicado. If it will it makes no sense cancelling the extended bolus because the fact of an outstanding basal change at (apparently) the wrong time is clearly a more serious issue. (That is to say, some people might think it is an issue, whereas cancelling the extended bolus simply makes no sense.)

John Bowler