Bolus Recommendations not as expected for shorter carb abs times

[Kdisimone]

Describe the bug Bolus recommendations are getting smaller when carb absorption times are lowered, everything else being equal.

Attach an Issue Report Issue reports were gathered for each of the various carb absorption times, attached to example below.

To Reproduce

1. Set up Simulator CGM and Simulator pump, run in open loop mode so that no additional IOB happens while testing.

2. Set a static, unchanging BG value so there is no BG momentum, etc types of differences.

3. enter a 50g carb amount with 3 hours carb absorption (at present time), gather the bolus recommendation. Don't accept the recommendation, instead cancel bolus and then delete carb entry. Add new carb entry of 50g (at present time) but lower absorption duration to 2 hours, gather bolus recommendation. Don't accept the recommendation, delete entry. Repeat for 1 hour and 30 min carb absorption. Compare recommended boluses. They are decreasing.

Expected behavior When lowering a carb absorption time, you'd expect the bolus recommendations to get larger (all other things being exactly equal), maxing out at the full bolus based on carb ratio and total carbs.

Phone

• Hardware: iPhone XS max
• OS Version: iOS 12.4

Loop Version

• Version Number: 1.10.0dev
• Repo: LoopKit/Loop

CGM simulator CGM

Pump simulator pump

Additional context

Settings: Basal rate: 1.0 u/hr BG: 100 mg/dl steady (using simulator, no change in BGs at all over time) ISF: 75 mg/dL/U Carb Ratio: 10 Insulin Model: Rapid Acting - adults Suspend Threshold: 50 mg/dL Correction Range: 100-100 mg/dL

At these settings, a 50g entry at present time, would expect a 5 unit bolus based on carb ratio alone if a person were at target, perfectly flat, for a quick absorbing meal.

Enter 50g of carbs at present time and the following bolus recommendations happen:

3 hour carb abs (taco): 4.95 units 3hr-Issue Report.pdf

2 hour carb abs (lollipop): 4.9 units 2hr-Issue Report.pdf

1 hour carb abs: 4.8 units 1hour-Issue Report.pdf

0.5 hour carb abs: 4.6 units 30min-Issue Report.pdf

[Kdisimone]

Confusing matters further...if I repeat the experiment...the bolus recommendations are not the same (despite no IOB, no changes to settingsopen loop, simulated BGs always at 100mg/dl, single 50g carb entry always at present time, and other test conditions all identical).

3 hour abs: 4.8 units 3hours-second.pdf

2 hour abs: 4.75 units 2hours second.pdf

1 hour abs: 4.55 units 1hour second.pdf

30 min abs: 4.2 units 30min second.pdf

(repeated experiments have the recommendations varying...sometimes the 3 hour abs is down to 4.75 for example...I'm just showing one of the examples, but they aren't always the same for each repeated experiment. However, the trend is always the same...3 hour abs entry gets the largest upfront bolus recommendation and the shorter carb abs times get smaller recommendations.)

[Kdisimone]

[Kdisimone]

just some more bolusing data...if it helps.

Issue Report: bolused.pdf

this time I set a correction range wider to 90-110 mg/dl and entered a 50g at 2 hours abs time. Recommended bolus was 4.8units. I delivered the bolus and the eventual BG predicted was 135 mg/dl, so seems as though Loop is intentionally underbolusing (or a better way to say is that maybe Loop's after-bolus prediction seems to know the bolus should have been stronger?) Based on the eventual BG right after a bolus that had a 2 hour abs with no IOB, no momentum, no RC...would seem like dose math is underestimating bolus recommendation (and not because of an early low prediction)

[scottleibrand]

I did notice that in the 30m reports the predicted BG comes in at around 430, whereas it should be 475 based on the 375 of predicted carb rise, plus the starting BG of 100. For the 3h estimate it’s closer, at 467 or so, but still not exactly 475. I think that discrepancy in predicted eventual BG drives the lower bolus recommendation, but I can’t see anything in the issue reports that would account for it.

[Kdisimone]

same as the bolusing experiment above...except with a 30min carb abs time for the 50g. Bolus recommendation was 3.85units.

Issue report: 30min bolused.pdf

[Kdisimone]

Bolusing for 50g with 3 hour absorption, recommended amount 4.75units

Issue report: 3hr bolused.pdf

[ps2]

What's happening here is momentum effects "eating" carbs. Momentum is blended in after all the other effects are added together. So some of the initial predicted carb effects are swapped out in consideration of momentum. If the amount of carbs in that initial 15m window is greater (shorter duration), you'll see more carbs missing as a result of momentum.

This is expected behavior, and this will happen no matter what your insulin model start time is. It should be noted that if you prebolus > 15m, momentum won't be affecting your carb entry.

The bigger issue of Loop making larger cuts to your bolus is for a different reason. It happens when Loop thinks insulin activity will bring you below this line: https://github.com/LoopKit/Loop/issues/533#issuecomment-326771484 (second graph). If you are having this second issue, splitting your meal into a faster absorption part may help. Loop's current carb model is linear (although dynamic, so it will change as absorption is observed), but typically people do see faster absorption initially. Splitting your meal entry into two parts will tell Loop that you know that you'll have faster initial absorption, and you can use this to avoid Loop trying to save you from the scenario where insulin outpaces your food.

[dm61]

Great explanation, thanks Pete! One minor point:

prebolus > 15m, momentum won't be affecting your carb entry

Momentum is based on the glucose slope over past 15 min, but is then blended over 30 min in the forecast, so I guess the above statement should have been "prebolus > 30m, momentum won't be affecting your carb entry"

[Kdisimone]

Thank you. That explains how when first conducting this experiment, there was one time I got a full 5 unit recommendation, as I had neglected to backfill Bg data that first time. At zero momentum (only on BG data point), Loop did offer a full 5 unit. For some reason, I hadn’t put dots together leading to momentum on that when I first saw it.

[ps2]

Great explanation, thanks Pete! One minor point:

prebolus > 15m, momentum won't be affecting your carb entry

Momentum is based on the glucose slope over past 15 min, but is then blended over 30 min in the forecast, so I guess the above statement should have been "prebolus > 30m, momentum won't be affecting your carb entry"

It's a little complicated, but the effect is blended over 15-20 minutes. Loop computes forecast effects for a period of timestamps adjusted to even 5 minute points on the clock. So if current time is 10:31, the forecast points would be 10:30, 10:35, 10:40, 10:45, 10:50. The forecast is 100% momentum between 10:30 - 10:35, and there is no momentum component in the 10:50 - 10:55 segment. But between the 3 other segments there is a blend.

I think you might be seeing that the linearMomentumEffect method defaults to 30m for duration, but it's called from getRecentMomentumEffect with a value of 15m.

[Kdisimone]

So then the “minute mark” (where the carb entry is within the 5min interval) may explain why sometimes the experiment has a 4.9 vs 4.75 bolus recommendation with all other things being equal?

[ps2]

Yes, that's probably the case, though I haven't analyzed the issue report to confirm that.

[Kdisimone]

So then I have another related question about where the bolus recommendation is aiming for as a lower bound (suspend threshold vs. lower correction range). The two examples...

first image is a bolus for a 50g meal (settings same as above, nothing changed) based on a single BG data point, so no BG momentum. The bolus recommendation came in as 5 units (full carb ratio expectation) and the predicted BG after giving that full amount shows all the array is still above the suspend threshold of 50 mg/dl, but definitely below the lower correction range.

[Kdisimone]

Second example...basically the exact same situation as above with the exception of Loop having a BG history and therefore some BG momentum component in the recommendation. This time the prediction after applying the recommended bolus (4.75 units) appears to only dip to the lower correction range.

[Kdisimone]

So my question from those two situations is "does loop have different bolus thresholds for different situations?" I'm trying to figure out why one bolus recommendation would allow the early part of prediction curve to go below the bottom of correction range vs the other would be preventing that dip.

[dm61]

why one bolus recommendation would allow the early part of prediction curve to go below the bottom of correction range vs the other would be preventing that dip.

Because the threshold actually slides from suspend threshold for the first half of DIA and then linearly to the mid-point of the correction range at the and of DIA. See the bottom diagram here.

[Kdisimone]

Well I’m just learning a ton here. Thank you both Pete and Dragan! Very useful

[Kdisimone]

Last semi-related question (as this pops up in Looped)...when the temp basal enacted is below max basal delivery limits but there is also a recommended bolus by loop...this is because the correction insulin for basals vs boluses could be targeting different BGtargets then? example (max basal delivery limits for this Loop is 6 u/hr):

[ps2]

Loop calculates a bolus and temp basal recommendation with each Loop. You're seeing the bolus recommendation from the same forecast that generated the temp basal.

[Kdisimone]

Loop calculates a bolus and temp basal recommendation with each Loop. You're seeing the bolus recommendation from the same forecast that generated the temp basal.

Thanks. So to confirm my head is going the right direction, Do you mean the recommendations in Loop pill are more read like this: "Based on this single prediction curve (1) either bolus this recommended amount but (2) Loop is covering that same need via high temps now?" So either/or...not both at once?

[jdsnyc]

Sorry to chime in, but I would like to comment; not because I think I know the answer, but just would like to find out if I am anywhere even near understanding the calculation process.
I believe that temp basals are adjusted every 5mins. So, if a recommended bolus is dosed, the temp basal will re-adjust based on the new IOB value once dosed. If no bolus is given, the temp basals will continue its calculation based on current IOB (not including suggested bolus).
The recommended bolus is suggested for a faster administered dose. Rather than the .65unit bolus being given immediately, the temp basal would space that dose out for the next hour (.0325u every 5mins for next hour) , delaying the effect on bg level. Sorry to inject my thoughts, but I really am trying to understand the process. Please let me know if I am totally off course in my understanding. thanks, john

[Kdisimone]

John, I may be reading between the lines a bit of what you wrote...but it sounds like you think Loop may include the currently running temp basal’s insulin contribution before the insulin is delivered (like once the temp basal is set. Instead, what you’ll actually see is a “pending insulin” amount in the bolus tool’s info and that represents the amount of insulin scheduled to be delivered if the currently running temp basal finishes to the end of its scheduled time.

[Kdisimone]

And temp basals are only set for 30min, not an hour. Loop doesn’t offer a “faster option”....but you could give the pending insulin option as the equivalent of a quicker administration of the correction, but loop doesn’t offer that in the bolus tool.

[ps2]

Loop calculates a bolus and temp basal recommendation with each Loop. You're seeing the bolus recommendation from the same forecast that generated the temp basal.

Thanks. So to confirm my head is going the right direction, Do you mean the recommendations in Loop pill are more read like this: "Based on this single prediction curve (1) either bolus this recommended amount but (2) Loop is covering that same need via high temps now?" So either/or...not both at once?

Yes, basically. We could talk about triggering another forecast for NS uploads, so it matches closer to what you'd see if you opened Loop. But we should remember that what's shown in NS is a snapshot in time, and generally you'd actually be bolusing from Loop itself with a fresh recommendation.

[Kdisimone]

I don’t think we’d need another forecast just for NS. I think I can put some useful info about this in the docs. It’s come up before and I’ve kept forgetting to look into it. This helps...and saves me from having to try to reproduce on a test rig to verify my understanding of code. Super helpful. Thanks. Closing issue now as I think all My questions/concerns are answered. Thanks.

[jdsnyc]

Thanks for your responses. I appreciate your knowledge and hope to getter better understanding of the whole calculation process and the many variables involved. John On Friday, September 6, 2019, 01:02:43 AM EDT, katie disimone notifications@github.com wrote:

And temp basals are only set for 30min, not an hour

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or mute the thread.