-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Target autotuning #363
Comments
This seems useful for days with the same level of activity. From the bg curves I checked it seemed that activity (or activity in combination with active insulin) seems to have a major impact on the bg levels. So maybe we should also take activity into this autotune target equation as well (e.g. steps per hour). I don't know if it would work to get some kind of indicator of BG impact for "low" (sitting), "normal" and "high" (sporting) and decrease the target for low activity and auto increase the target for sporting. |
I think you also need to take into account carb/insulin muck ups with this. The majority of lows come for me when I've got my carb counts wrong (even after 28 years of doing this) and it's not always easy for autotune to identify where that cause and effect comes in to play. |
I think those are more complicated than would be necessary to make this work. They might be useful, but I think they'd be separate features. For the first version of target autotuning, I think it would be sufficient to set more conservative targets for any hours leading up to times of day when we see BG levels dropping more than the loop can deal with. It doesn't really matter whether that's due to activity levels, miscounted carbs, or anything else: if there's a time of day when you sometimes go low, we can set a higher target than for times of day when you almost never do. |
I am using myself as an example but I think it would be hard to pin down a specific "time" that my blood sugar goes low. It's usually a set of specific "circumstances". And, as @PieterGit, @tim2000s mentioned, these circumstances would be something such as exercise or miscalculating carbs/insulin. I would have to be essentially living the same day over and over, making the same mistakes, and consistently going low at the same time for an iteration to correct for/spot this. And I do not tend to eat the same food at the same time every day while also miscalculating the carbs/insulin. Therefore, the only "mistake" I think that would result in a trend that was noticeable (by examining timestamps alone) is exercising daily at the same time while using a too-low target. Even if you were to extend Autotune to just examining one day a week for a trend (Mondays, I always go low because I'm running to my next class and I don't have time to eat, for example), it would likely just be telling something you already knew. (Mondays are the worst + running across campus on an empty stomach is inadvisable.) Which is why it might be useful to anticipate the need for changing targets by supplying some sort of warning that exercise was about to occur? (A different feature entirely, I know.) I saw some mention of syncing with a calendar in Loop's issues (LoopKit/Loop#373). It might also useful to pull in some sort of exercise data to trigger the target automatically and then later use Autotune to decide what target would have been best for that kind of exercise in the future. For example, I am using Loop and when I exercise, I set my exercise target to 150-170 and some days that is perfect and some days that is entirely too high and a lower target would have been better for pre/during/post-workout numbers. Also (slightly related) there was some mention of Nutshell (http://tidepool.org/products/nutshell/) trying to help you with recurring exercise errors (not sure how, exactly?). |
Rather than thinking about regularity in times when you go low, it might be useful thinking about regularity in times when you don't go low. Particularly, overnight when you're sleeping (not exercising, and not bolusing). For those times, target autotuning could safely lower your target and bring down average glucose, without increasing severe hypo risk. Maybe it would be useful to open up a new issue re: new ways to predict lows based on machine learning pattern detection or similar? Seems like a lot of folks think that would be possible and useful, but it's probably not something I could tackle as easily. Maybe someone with ML expertise would be able to, though... |
Okay, I think I see what you're getting at and I agree that getting recommendations for changing your target at night (or other times that are trend-producing) would be useful. I like the idea of getting to the point where the goal is to get your numbers as low as possible without actually going low. Pre-closing-the-loop, I found my internal target would angle towards 150 because this allowed me enough time to correct for a sudden swing in any direction. And it would be useful to be able to iterate and discover that I (for example) would be able to get away with a 110 target during certain times of the day. |
The usage pattern I have in mind would be to actually have target autotuning happen automatically in the background if desired (the same way autotune does currently), so it can adjust the targets without the PWD having to set up multiple schedules or otherwise mess around with them. |
This seems resolved via exercise mode et al. Closing due to lack of recent activity. |
Using oref0 with well tuned basals and ratios, it is often fairly straightforward to achieve very high time in range percentages overnight, and avoid lows at most times. It would be useful if we could have oref0 figure out when it's safe to shoot for a lower target, in order to lower average BG and A1c, without increasing hypoglycemia risk.
One idea for accomplishing this would be to apply the iterative basal autotuning logic from #261 to targets. As with basals, we'd want to tune each hour's targets based on the outcomes from the following 3 hours. For a given hour, if BG drops below 80 (or a configured low threshold) for the following 3 hours, raise target by the area under the curve below 80 and above actual BG, in hours*mg/dL. So a 1h-long low averaging 75 would increase the target for the 3h prior by 5mg/dL. But when 3h-after BG is > 80 and average BG is above target, we can safely reduce that hour's target by 1 mg/dL.
An iterative target autotuning algorithm of this sort should keep targets high at times of day when BG would otherwise risk dropping too low, but would lower targets (possibly even into the 80s) during times of day when OpenAPS is able to keep BG from dropping very low for very long. It should therefore allow users to achieve lower average BG without increasing the time spent low or the severity of lows.
Thoughts?
The text was updated successfully, but these errors were encountered: