Repository navigation
Dose calculations based on eventual glucose at the time that may extend beyond DIA #440
Description
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.
Activity
scottleibrand commentedon Apr 4, 2017
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 commentedon Apr 4, 2017
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 commentedon Apr 5, 2017
Yes, I believe we do want to change this behavior. Was actually just discussing it on Monday. Thanks for opening a ticket.
dm61 commentedon Apr 25, 2017
This has been taken care of in 1.3.2 - thanks!
ps2 commentedon Apr 25, 2017
Please wait until the fixes are in a released version of loop to close the ticket. Thanks.
dm61 commentedon May 17, 2017
fixed in Loop v1.3.2
[LOOP-2179] mutate settings for each case (#440)