After resume pump, temp basal is set too high, resulting in very low BG

[cfaagaard]

Describe the bug
We have been looping since October 2018 and have our settings dialed in.

My kid (teenager with T1D) was the other day out with friends and driving gocarts. He had taken the pump off during driving and stopped the pump (on the pump).
When he was finished driving he put the pump on again and resumed the pump.
Just after the pump resumed the basal was set to max basal by loop.
And one hour later he hit 2.2 BG.

Time	Action	BG	Basal
16.41	Pump Suspended	7.2	2.0
18.35	Pump Resumed	6.0	0 (not shown in NS)
18.35	Normal loop	6.5	7.0 (max basal)
19.12	Normal loop	7,4	0
19.47	Normal loop	2,2	0

If you see the screenshots below, the "prediction" before "pump resume" is around 5,5.
After "pump resume" it is set to around 10. And therefor turn up the basal.

We have stopped/resumed the pump several times before and not seen this before.
I can see the IOB change. Maybe this the reason. Is the "missed" basal during "pump suspend" that gets calculated into the IOB?
ISF: 1,9
Max basal: 7

Phone

• Hardware: iPhone X
• OS Version: iOS 12.0.1

Loop Version

• Version Number: 1.9.5
• Repo: LoopKit/Loop, Master

CGM

• Device: Dexcom G6
• Manager app: Dexcom App

Pump

• Manufacturer: Medtronic
• Model: 522

[scottleibrand]

Did he really have the pump suspended and no insulin delivery for 2h? If so, then yes, IOB would be highly negative when the pump was resumed, and the proper action would be to try to deliver additional insulin to offset the missed basal and avoid a high. I doubt his IOB even got back up to zero before drop started, which leads me to believe the drop could not have been caused just by receiving the missed insulin, but rather by something else (physical activity maybe?) that was making him highly sensitive.

[cfaagaard]

@scottleibrand Thanks for replying.
Yes it was off for 2h.

That is why I wrote about the Go-cart.... Adrenaline….. But in our experience adrenaline makes BG goes up, but he is pretty flat during the race (cool kid). :-)

There was no physical activity after.

But then it is correct that after resuming pump the IOB takes into account the missed basal?
So if we suspend the pump for ex. 24 hours (and goes on pen)? What would happen then when we resume the pumpe?

Some data details for our issue-scenario:
Here are some data from devicestatus from mongodb:
Last entry when pump is still suspend:
"iob": {
"timestamp": "2019-08-13T16:30:00Z", (+2 hours, so 18.30)
"iob": 0.11901894434607519
},
First entry after pump is resumed (5 minutes later) on a BG 6.3:
"iob": {
"iob": -2.9864776688176719,
"timestamp": "2019-08-13T16:35:00Z"
},
…. "recommendedBolus": 3.175,
…. "rate": 7,

The IOB goes over zero (25 minutes later, BG 7,8):
"iob": {
"iob": 0.2774567715093703,
"timestamp": "2019-08-13T17:00:00Z"
},
…."recommendedBolus": 0.575,
…."rate": 6.475,

The basal is set to 0 (15 minutes later, BG 7)
"iob": {
"timestamp": "2019-08-13T17:15:00Z",
"iob": 1.0373684628423786
},
"recommendedBolus": 0,
..."rate": 0,

[scottleibrand]

The IOB being reported while the pump is still suspended is likely incorrect, as Nightscout doesn't know at that point that he's been missing basal for so long. The highly negative IOB just after pump is resumed appears to accurately reflect the missed insulin, and is the driver for the high basal that brings IOB back up to zero, until BG stops rising and it starts zero temping.

You had a situation where he needed way less insulin than his normally scheduled basal for some reason. If you hadn't been suspended, he would've gotten that insulin earlier and BG would've started dropping earlier, forcing the loop to respond.

You should check your basal settings and ratios are accurate (by manual testing and/or running autotune), and consider setting a high target if there are situations where you know less insulin is required than normal.

[cfaagaard]

Does the IOB-number not come from the Loop app? ("Nightscout doesn't know at that point that he's been missing basal for so long.")

We have not touched our settings in months, but hey, it is diabetes so who knows.

So you might be right about setting a higher target after ex. sport (if you suspend pump).
That might be to much to remember for a teenager. :-)

But then is it not easier not to suspend the pump at all?

[cfaagaard]

I am pretty sure if he had not suspended the pump (But still taken the pump off) in our scenario then he would not have gone low.

But you are saying that the behaviour "On 'resume pump' IOB calculates the missed basal during suspend" is by design and not a bug/issue?

If so, should I close the issue?

[scottleibrand]

@cfaagaard that is correct: if no insulin is delivered, that contributes to negative IOB. There may be improvements possible to the way negative IOB is handled (and I'd be happy to discuss what we've learned with other DIY systems on that front if anyone's interested), but the current design is to fairly aggressively counteract the negative IOB with high temps to get the predicted eventual BG back down to target. If you're in a situation where you'd need to suspend basal insulin for long periods of time (and not have that insulin backfilled) to avoid a low, you should probably use a high temp target to inform Loop of that.

[ddaniels1]

Another option would be to use a temporary override designed for this situation that both sets a higher temporary target range and also chops basal. Theoretically because the code is designed to decrease basal and increase carb ratio and isf by the set %, it may increase the eventual bg, because the higher the isf with negative IOB, the higher the eventual bg. I've seen this in practice. We may also consider adding a delivery limit specific to the override. That way, in the more insulin sensitive situation, which would likely be the case with negative iob and a significant or impending low we can drop the max temp. Alternatively in a resistant situation one could increase it. Lastly, as a safety issue I think we should consider limiting max temp basal to a reasonable x of the basal rate. This would solve all the above issues. Perhaps a selector that allows 2x-5x the current set basal as the max temp basal. Then it would apply in both standard and override situations. @ps2 @Kdisimone putting them on for thoughts as well.

[cfaagaard]

@scottleibrand @ddaniels1 Thanks for replying.

My kid only suspend the pump when he take/click off the pump (Medtronic). And he takes off the pump for various reasons: sports, on the beach with friends, swimming pool and so on.

And for my teenager (boy) to remember to suspend the pump is a big thing :-) and resume the pump even a bigger thing (yep). But we are getting there. What you a proposing may not be doable for us if my teenager also has to remember to set a higher target or an override.

But I have an idea for suspend/resume:
For my teenager the more he can control via the phone the better. So if he could suspend/resume the pump via the phone that would be great.
Ex. if he could could click the pump-icon -> Get a dialogwindow where he could click suspend (maybe even with a timer ex 1 hour like "sportsmode"). After clicking suspend the usual security check (faceid or code) and then the pump-icon has a red-cross.
When he wants to resume the pump -> he click the pump-icon -> get a dialogwindow where there is a button "resume" AND here there could be some more options: higher target or override. Maybe even showing the calculated IOB and asking if you want to "use" that or not -> after clicking resume and chose an option the usual security check.

That would be a great feature for my teenager.
(and yes, this feature asumes that it is possible to send commands to the pump to suspend/resume)

[elnjensen]

Half of what you're asking for already exists (in the current development versions, and will be included in the next main release version). When the pump is suspended, the line at the top of the screen (where you normally see the recommended basal rate, just below the top row of icons) says "Pump Suspended Tap to Resume."

[ps2]

Overrides get us a little closer to a "sports mode" for loop. You can use an override, which is now in dev, if you're up for testing, to tell Loop to assume less insulin is needed. This way, negative IOB will not accumulate so fast.

[ps2]

Going to close this issue, as I believe the algorithm is working as expected here, despite the unintended effects of how it is being used.

[cfaagaard]

@elnjensen Thanks. I said it was a great idea (but it was just not my idea :-))

@ps2 I agree.

[cfaagaard]

@scottleibrand I think you are right that he did "something" so he did not needed the "missed basal during suspend" after resume. This is the first time we have seen this. The other day we had another suspend/resume and Loop handled that perfectly (again).

@ps2 I think you can close this issue.

Related small "issue": I think NS-upload should set the temp basal to zero during suspend instead of the normal basal rate.
Maybe fixed in #1059 (can't tell :-) )

[ArkonPhoenix]

Glad someone started this.

We've run into this as well. And have had to make the max basal be just above the highest basal fr now until something else can be done. So we currently get the benefit of it turning the pod off, but not giving lots of extra insulin for highs.

And while I get the calculation of missed negative basal and the system playing catch-up, but maybe there should be a setting for when a pump is suspended, that it doesn't count that time suspended as negative iob? So when resumed, it picks up where it left off instead (since we took over control by suspending for a reason) and then it will bolus for the the amount that rising at that time only, instead of the rising and negative iob.

[Kdisimone]

closing this issue (as @ps2 mentioned above)