Carbohydrate Absorption Time x1.5 multiplier after update

[rkingman]

Hello all,
Hoping to get some light shed on this. After the last update, Loop seems to be much less aggressive (to a greater extent than expected).
It seems to want to deliver only ~70% of carb ratio calculated meal insulin, and then tries to cover the rest by matching basal modulation to carb absorption (the opposite of a superbolus). Its initial calculated meal insulin is so low it's as if it thinks my meals are being absorbed more slowly than they really are...

Which brings up some evidence of this: on the active carb menu, it shows 2 values for each bolus: the entered absorption time (2, 3, 4 hours) and another absorption time (3, 4.5, 6 hours). It seems to be multiplying the entered absorption time by a factor of 1.5x, and underbolusing each meal up front as a result, resulting in post-prandial peaks.

Can anyone explain this?

Edit: Thanks for the explanation to everyone. I'd been using a DIA of 3.25, which worked well prior to update (even if it wasn't physiologically realistic, it allowed for more aggressive hyper prevention). After the update, having such a fast DIA limited the initial bolus causing those postprandial highs and gave uptemping basal a hard workout. I think that most of us on Loop were likely using much too quick DIA's, and so I'm surprised that more people didn't have issues after the (fantastic) dynamic carb absorption update. I saw huge benefits immediately after switching to a longer DIA (5h).
The new insulin models seem to have taken care of this as well by using a more physiologically realistic DIA.

[ps2]

A good overview of how carb absorption and dosing works in 1.4 is here: #507

In 1.4, Loop will still bolus for 100% of carbs that are expected to be absorbed within DIA. That has not changed. What has changed is that Loop is a little more conservative about estimating carb absorption off the bat, and its initial estimate is that the carbs will take 1.5 times as long to absorb than entered. If Loop does see fast absorption, the estimate is updated, and the loop will start high temping as carbs are brought within treatment range.

Some examples. If you have a 4 hour DIA, and enter 2 hours CA time, Loop will expect it all to absorb within 3 hours, which is within DIA, so it will bolus 100%.

If you have a large meal that you think is going to take 6 hours to absorb, Loop will start out with an initial conservative estimate of 9 hours, and only carbs expected to absorb in the first four hours will be bolused for. This is what you want, actually. If you have a meal that you don't expect to absorb within DIA, and your ICR is correct, then bolusing for it up front will certainly bring you low. By holding out some of the insulin, Loop can accomplish what manual pump users typically use square wave boluses for, but in a more responsive fashion.

When absorption happens faster than expected, Loop will bring more carbs into treatment range, and will add more insulin to cover them.

Sometimes it's easier to talk through an example. Feel free to post screen captures if you have one you'd like to work through. If you do, the state at 1-2 hours after the meal, and when you think absorption is probably done would be good points to capture.

[dm61]

You may take a look at #507, which provides a a detailed description of how dynamic carb absorption algorithm works. More specifically to your question, Loop will give full bolus recommendation as long as the carb absorption time multiplied by 1.5 is shorter than DIA. For example, assuming DIA = 5 hours. CA = 3 hours, Loop will initially assume the carbs will be absorbed uniformly over 3x1.5 = 4.5 hours. Since 4.5 < 5, Loop will give a full bolus suggestion. As another example, if CA = 6 hours, Loop will give a bolus suggestion for 5/(6*1.5) = 55% of the carbs entered, and will then high temp for the rest in the form of a dynamic square-wave bolus. This is expected and desirable.

Oh well, while I was about to click on the comment button, I saw @ps2 has already provided a (better) answer :)

[jeremybarnum]

After much thinking, we are currently running with this parameter set to 1.0. This is because large slow burning carb meals are very rare for us, and we think that for other use cases 1.0 is better. Also, I believe the interaction between RC and using 1.5 is not exactly correct. It's a subtle difference, but if RC is making changes when the BG is different from what you expect, and the definition of what you expect is based on 1.5, then it will pretty much always produce high temping even when everything is going exactly as you expected. In practice no one has been complaining about this so it must not be causing problems for people but it's, at the margin, aggressive behavior that is offsetting the conservatism that is intended by 1.5. For me part of the beauty of loop is that it trusts the user and doesn't have a lot of hidden, complicated "conservative" rules that interact with each other in unclear ways. I don't thing 1.5 is an example of that, but the interaction with RC is a little bit that way.

But the main issue for us is illustrated if you modify @dm61's example and imagine user-expected absorption of 4 and DIA of 4 (i.e.: 4 is the number you type in). If you expectation turns out to be right, you will be playing catchup for 1/3 of the bolus, leading to more highs than you think you should have. (because bolus will be DIA/(CA*1.5), so 4/(4*1.5). Important to note that for most normal meals with absorption times that are less than DIA/1.5 there is no difference in the bolusing behavior so it's really about longer CA meals where this is relevant.

[dm61]

@jeremybarnum I often have large mixed carbs+protein+fat meals that take a number of hours to digest. For such meals, the 1.5 factor has worked well, with a reduced up-front bolus and enough time available for high temping to work really well. With #533 already implemented in dev, I think the up-front bolus safety offered by the 1.5 factor becomes superfluous, and too conservative. So, I am also going to set that parameter to 1.0. One (undesirable) consequence of setting the parameter to 1.0, however, is that the same parameter (if I understand the current dynamic carb implementation correctly) also sets the maximum possible CA, which could adversely affect predictions and dosing if the meal actually had longer CA than initially assumed and entered. The best option I can think of would be to have 1.0 as the default initial value (trust the user!), but allow dynamic carb algorithm to stretch CA by up to 50%, based on observed absorption.

I also appreciate your comments about interactions with RC, which I think are correct.

[jeremybarnum]

@dm61 I complete agree and in fact was thinking right after posting that I had ommitted the critical point you raise. absorptionTimeOverrun also serves to "expire" the carbs - and for that purpose it makes sense to keep it at 1.5. So recap your suggestion, in the end state, it seems that maybe:

• Dosing algorithm #533 takes care of avoiding lows from over-bolusing for slow burning meals
• in general, expected CA is equal to user input which addresses RC issues (i.e. absorptionTimeOverrun = 1.0, or simply isn't used for the forecast, other than as below)
• max CA is something like CA*1.5. This "expires" carbs if there are carb counting mistakes, exercise or other effects that mean that the carbs never show up.
• users who are concerned about a high uncertainty meal can always manually lengthen the inputted CA, thereby decreasing the bolus while still keeping loop aware that the carbs are coming, but without worrying about that input in turn getting multiplied by 1.5.

[chadharper0131]

wouldnt the aggressiveness of (1.0 vs 1.5), or lack thereof, also be a function of your max temp basal rate? because i do see my initial meal boluses being smaller. <-- compared to just running bolus wizard - non looping.(this is my first week looping) I dont have any experience with comparing 1.0 vs. 1.5 or any loop settings comparisons, obviously. ---When i bolus for a large carb meal = i am seeing a large percentage of high temping, last meal it high-temp'd up to appx: 8.5u/h & my initial carb bolus was much much smaller. (~~~ My current max temp basal is 10u/h. )

Could someone tell me how the loop algorithm decides how to approach mealtime boluses and what % of bolus it tries to modulate by using basal temps?? ** Secondly, im also assuming that the higher ones usual basal rate, the more "flexibility" the algorithm has to be more aggressive (due to the fact that it if overestimates -- and gives too much insulin, with someone who has a higher avg. basal rate, they have more room to low-temp or 0% basal to recover.

thoughts???
-chadharper0131

[chadharper0131]

what do most of you keep your temp max basal at? and why?

[dm61]

@chadharper0131 https://loopkit.github.io/loopdocs/algorithm/overview/ provides an overview of the Loop dosing algorithm. Yes, a higher max temp rate allows Loop to be more aggressive in high temping. Versions of Loop prior to 1.4 had a different carb absorption model, which in some cases resulted in too much high temping up front. Conservatively limiting max high temp rate was a way of mitigating that issue. With dynamic carb absorption algorithm in 1.4, this is no longer necessary. However, there is always a more general safety concern related to high max temp limits.

[Kdisimone]

I wrote up a bit about how Loop determines boluses, and in particular the times you'll find Loop offering less than your full carb-ratio-only expected bolus. DIA and carb absorption time play a huge role.

http://seemycgm.com/2017/08/09/why-dia-matters/

Also, we have had tremendous success with the new Loop version bolusing this way (and using the 1.5 multiplier). We typically prebolus by 20 min for large carb meals, we let Loop know we are prebolusing and the recommended boluses have been decreased (from carb ratio alone) because the carb absorption has been longer than DIA.

However, Loop has been very effective in picking up the "missing" bolus using high temps as soon as the danger of close-to-eating low has passed. We did have to up our max basal rate to accomplish this. We now have a max basal rate about 10x her typical basal rate. It hasn't given us any problem and has eliminated our need to manually split boluses for large meals now. Small meals we still get our whole bolus up front and the behavior is no different from on versions really.

[Kdisimone]

@chadharper0131 I assume you have notifications turned on for this issue, but if not...I'll tag you so you can see my reply above. Hope it helps.