Repository navigation
Maximum Correction IOB Limit #797
Description
There are situations where having additional control target of maximum correction IOB would be useful. One such example is pre workout where BGs are rising fast, and Loop predicts an eventual BG of higher then the pre-workout target. Loop then corrects, adding to the user’s IOB pre-workout. In these situations, particularly for sustained exercise (2-5 hours) it would be ideal to have an IOB limit – so that Loop can add a bit of IOB since the user is higher then their target, but not so much that its going to cause the user to crash once exercise related effects kick in and increase sensitivity.
@kenstack and I have implemented it here: https://github.com/Kdisimone/Loop/tree/plgs-issue
In this implementation, once the user sets a maximum correction IOB limit, Loop will default to the scheduled basal rate if the correction would cause IOB to rise over this threshold. If the IOB limit is set to zero, Loop then reverts to only reducing basal if BGs are trending below target, ie Predictive Low Glucose Suspend mode. Boluses for food and direct user boluses are unaffected by this limit.
This feature might also be helpful for new users who are just getting into closed looping
Activity
erikdi commentedon Sep 4, 2018
#707 has some discussion on this topic
kenstack commentedon Sep 4, 2018
@erikdi yes thanks Eric I did see that. This is a bit different then an overall IOB limiter - this is simply limiting corrections, not limiting boluses or changing bolus recommendations. My son on race day for example will eat and bolus, but only if he has enough time in between races for his IOB to come own to a point that is manageable. The idea behind this is to make sure auto corrections from Loop don't create an IOB that is unmanageable while the user isn't watching, but it lets the user bolus on their own, though I understand your point about potentially limiting total IOB as well particularly for small kids and caregivers who may make mistakes.
ps2 commentedon Sep 4, 2018
We face this issue also; if there is a fair amount of insulin on board before activity, because of the heightened sensitivity, bg can plummet fast, particularly on the trampoline.
However, additional configuration settings that are indirect to the problem make the user experience confusing. Contrast this to a mode where you could tell loop (in a variety of ways, some which may be fairly automatic) that you were going to exercise in the future, and it would know the heightened sensitivity and take that into account.
kenstack commentedon Sep 4, 2018
@ps2 I think I see where you are going. Maybe some additional functionality added to "workout" mode that allows setting of other limits in addition to BG targets? I see this not only for exercise, but more of a "safe" mode. Example - small kid is going to stay over someone's house 3 hours away with bad cell coverage - you'd want lite corrections and aggressive suspend.
scottleibrand commentedon Sep 4, 2018
One UX pattern that has worked well in other DIY closed loops is to have workout mode trigger a different profile, with lower basals and higher ISF/CR, in addition to changing the target. When workout mode is triggered (either manually, via calendar, or by some other method), the loop then recalculates a higher IOB based on the new profile, and begins taking appropriate actions to bring IOB down to a level suitable for the new profile and target. (You'd probably also need to do some experimentation to figure out whether such a profile switch should apply retroactively to Integral Retrospective Correction, or only for the time period when it's active: I don't have a strong intuition which would work better.)
bashem commentedon Sep 4, 2018
For consistency, would "eating soon" have the same? ability to override sensitivity in addition to targets?
scottleibrand commentedon Sep 4, 2018
I think that's a usability question for Loop users and developers to answer, based on how y'all want it to work. In OpenAPS, we have a preference that enables that behavior for low temp targets. In AndroidAPS it requires a manual (but fairly easy) profile switch, which I think people only tend to do for exercise, not for Eating Soon.
kenstack commentedon Sep 4, 2018
@scottleibrand yes I personally think profiles for various "states" or situations would be useful but as of today they dont exist in Loop. But you could certainly trigger them via the temp target methods Loop uses with some extensions. @ps2 any thoughts on having a multiple profile type approach ? Or is your thinking that for typical users this will lead us down the path of configuration issues where there are too many choices and too many conflicting parameters. This generally leads down the path of an "auto" or normal mode and an "expert" mode where everything is configurable (not that I think any of us will ever be experts at managing t1d :) ).
scottleibrand commentedon Sep 4, 2018
If you want to avoid multiple profiles but still have strongly configurable behavior, the OpenAPS approach is to scale all of the basals and ratios proportionally to the magnitude of the temp target, based on a single hidden preference (that almost no one adjusts). https://github.com/openaps/oref0/blob/master/lib/iob/history.js#L500-L510
I don't have any real opinions about what's best for Loop, but happy to answer any questions about what has worked well in other contexts.
ps2 commentedon Sep 4, 2018
@scottleibrand "recalculates a higher IOB based on the new profile"? This doesn't make sense; IOB is independent of ISF. In general OpenAPS UX lessons are not applicable to Loop as the user experience in OpenAPS revolves around the command line, and many of the design choices in OpenAPS are antithetical to Loop's goals in UX. This is a ticket for Loop, and if you're not a Loop user, and have no opinions about what's best for Loop, then it comes off as if you're just here to proselytize.
scottleibrand commentedon Sep 4, 2018
Sorry if I'm stepping on any toes. I originally commented to share how it's done in AndroidAPS (the multiple profiles approach), not in OpenAPS, as I agree the UI/UX differences between OpenAPS and the phone-based solutions mean that many of the design decisions we've made for OpenAPS are based on different design constraints than apply on a phone.
scottleibrand commentedon Sep 4, 2018
@ps2 to answer your question, the IOB is recalculated based on the different basal rate in the new profile. If you switch to a workout mode where you indicate the need for 80% of your normal, and have been getting 100% of normal basal, then when the IOB is recalculated such that the extra 20% is considered a "high temp" against the new basal, so the resulting IOB is higher. The new ISF in the new profile is also used to calculate the expected impact of prior insulin delivery, which affects prospective projections of BG, as well as affecting retrospective calculations of things like dynamic carb absorption. If you'd like, I'd be happy to explain all the implications in more detail, and why that kind of approach works well for temporary changes in sensitivity, but I don't want to derail the conversation about what's appropriate for Loop.
ps2 commentedon Sep 4, 2018
@scottleibrand Thanks. If I have questions I'll ask.
dm61 commentedon Sep 5, 2018
Ultimately, would be great to have an intuitive and effective "activity mode" as discussed above, and in #593, and elsewhere. In the meanwhile, your approach looks pretty good to me, thanks @Kdisimone and @kenstack. What do you think about linking the IOB limit to the "Workout button" so that the limit is active only if the workout glucose targets are active? This would remove the need to go into settings and modify the IOB limit when needed for exercise and then back to some higher value otherwise.
kenstack commentedon Sep 5, 2018
@dm61 I completely agree in a more advanced activity mode and a lot of what was discussed in #593. And yes we can definitely link it with workout mode so it turns off. I think there are tradeoffs between a more advanced profile capability (ie let people set each setting and create lots and lots of profiles) versus something that is more of a slider or even just a default scaling that moves a bunch of the settings with a simple swipe. I see the ease of use side on the one hand and I see the personalization side on the profile end. The UX experience that @ps2 is driving will be the key decision maker here so Ill let him weigh in and we can go from there.
francesc0-cgm commentedon Sep 6, 2018
I agree that a solution has to be found. For young kids for example after a day on seaside when you reattach the minimed loop will get in a ton of insulin to get iob positive again and there is always the risk for severe lows (my son in this situation yesterday got a 28!!). I don’t know which solution will work better (multi profile or iob cap) but only an higher target seems not effective to avoid severe lows and undermines overall Loop safety
francesc0-cgm commentedon Sep 6, 2018
It could be also an option to prompt the user to make null negative iob after workout and pump suspension
trixing commentedon Sep 6, 2018
francesc0-cgm commentedon Sep 6, 2018
When you swim you have to suspend pump...
Edit: sorry i understood... you leave pump on to avoid this issue...i will try
trixing commentedon Sep 6, 2018
Kdisimone commentedon Oct 10, 2019
closing my own issue as I think that the addition of overrides significantly addresses the ability to better control IOB loads during exercise and post-exercise with a UI that makes the implementation accessible enough to succeed. ;) Thanks
Remove adult/child insulin model selection (LoopKit#797)