Dose calculations based on eventual glucose at the time that may extend beyond DIA

[dm61]

I think LoopKit calculates glucose predictions up to a point in time that is the longest among DIA and any active carb absorption times. Then, in DoseMath, temp basal and bolus calculations are performed based on the eventual glucose, which is the last predicted glucose value. In many cases, the last predicted value and the value DIA in the future are the same, and everything is fine. However, if one enters long-absorption-time carbs, or enters future carbs (for whatever reason), the last predicted glucose occurs after DIA, and is therefore beyond the reach of any current temp basal or bolus. The dose is then issued too early and could potentially increase risks of lows.

Not a huge issue, but I believe the calculations in DoseMath should conceptually be done based on the glucose value predicted DIA in the future, not the last predicted glucose.

[scottleibrand]

Doesn't DoseMath also take into account the lowest predicted BG between now and DIA? If so, then only dosing to bring minPredBG down to the target range should be sufficient to prevent lows from dosing too early. Not sure if there is the possibility of Loop recommending boluses that would bring minPredBG down below target, but if it's setting high-temps that do that, it should stop high-temping as soon as the updated minimum BG prediction shows a projected low. Have you seen any examples where Loop dosed (or recommended) insulin for future carb effect that brought minPredBG down below target?

[dm61]

Loop won't dose if it predicts that bg would go below lower target - that's all fine, and everything would be great if the actual bg ever followed the prediction exactly. In practice, I've seen cases where I wish Loop had not high temped too early. It's also a matter of having the algorithm conceptually correct.

[ps2]

Yes, I believe we do want to change this behavior. Was actually just discussing it on Monday. Thanks for opening a ticket.

[dm61]

This has been taken care of in 1.3.2 - thanks!

[ps2]

Please wait until the fixes are in a released version of loop to close the ticket. Thanks.

[dm61]

fixed in Loop v1.3.2