Adding Other Predictors for Loop

[kenstack]

per a discussion in #653, this issue is meant to begin a discussion on the plusses and minuses of using other predictors in conjunction with the loop predictor.

Would love to talk thru the case below as I think its instructive - this was from this morning. You can see that the algo didn't suspend until it was much too late (again assuming you need about 45 min with Fiasp and 60+ minutes with novolog to stop a ~ 1 mg/dl.min drop). Threshold is set at 75. I believe there will be cases where true velocity and BG should be more "dominant" in the prediction, as the algorithm can't account unknown physiological changes (hormone levels, prior exercise or lack thereof, sickness) etc which lead to effective changes in sensitivity. Usually these predictors kick in during situations where the model begins to become inaccurate or someone is at risk for going low. There are tons of tradeoffs on any AP algo idea, so Im certainly not saying this is the right answer (tradeoff here is that you may suspend too often and get rebounds) - just want to start the discussion of how we can improve predictions and if it makes sense to tradeoff predictors based on the situation at hand.

[dm61]

@kenstack thank you so much for opening this issue and for providing a specific example, which makes it so much easier to discuss in concrete terms. This is exactly the type of situation I am trying to address through modifications to retrospective correction. In the current Loop algorithm, RC is computed as the deviation between the current bg and the bg predicted 30 min ago, where the prediction includes only insulin and carb effects. Then, it is assumed that the same RC persists in the future in the form of a modified BG forecast. The process is repeated every 5 minutes. If everything were perfectly modeled, RC value would have been zero. A non zero RC indicates that there is an unmodeled glucose pressure, positive or negative (in the example you posted there is unmodeled negative pressure).

A problem with how RC is currently handled is that it is a one-time correction in each step, which does not take into account past RC values, In control-theory terms, RC can be considered a proportional error term, which is great, but unable to address longer term model errors. In your example, it is clear that negative RC persisted for some time, e.g. due to lower than expected basal need, or whatever. Taking into account not just present time RC, but past RC values would have recognized persistence in that unmodeled glucose pressure, and would have resulted in earlier and stronger downward forecast. Loop would have low-temped sooner and hopefully prevented the low.

If you wish, you may take a look at an implementation of such cumulative or "integral" RC factor in my experimental Loop, with the algorithm changes in LoopDataManager (apologies, my coding is really sloppy, and there are tons of hard-coded constants there I am experimenting with, so I'll need some more time to test things out before even opening this for discussion. Please do not try this version).

[kenstack]

@dm61 yes an "integral" type term would I think be a really really great addition, in particular for persistent highs or lows. Im very interested to help and also to find a way to hook the loop dosing algo up to the simulator - in my prior efforts this really helped with scenario modeling on the unwind method for the integral. Ill take a look early this week at your changes. And never apologize to me for sloppy coding - Im usually the one apologizing :) Thanks!!!

[dm61]

@kenstack sounds good, thanks! Would definitely like to collaborate on this topic - imo, there are treasures in RC yet to be found and made use of. btw, thanks to some time available over the holidays, I now have an almost complete Loop simulator in MATLAB, will put it up on github as soon as I clean it up a bit (that's what I've used to initially develop "integral RC").

[mbieweng]

First post here (hello)...Just wanted to say that I think all of the above are good ideas.

I've been experimenting with something similar (though a bit simpler), where I'm adjusting the carb ratio and ISF based on the RC to deal with persistent RC. The algorithm is basically this:

• If actual BG is reasonably close to previously predicted BG, do nothing
• If actual BG << previously predicted BG, increase ISF and carb ratio by a small (arbitrary, for now) amount proportional to the difference.
• Similarly, if actual BG >> previously predicted BG, decrease ISF and CR
• Limit the adjustment to reasonable bounds
• Continuously trend (exponential decay) the ISF and CR back towards the user-set default values over time.

I guess this is somewhat related to the oref0 autosens algorithm, though I haven't had a chance to study that in detail.

I've gotten some modest improvements with this over the past few weeks. (Average bg down 5 mg/dL, sd down 5 mg/dL, time in range up a couple percent)

That said, my approach isn't ideal - it's an oversimplification because there are other things that affect the RC besides just CR and ISF (carb absorption, for example). I think the integral term is likely a better approach.

One benefit is that I also have the current adjustment factor exposed as a user setting in the app. That provides an easy way to temporarily cut down the ISF and CR for exercise.

Separately, but on a related note, I've also added alerts that will trigger if the predicted glucose is below or above certain thresholds, the retrospective correction exceeds a certain limit, or when a user-entered bolus is needed to help Loop when high temping isn't enough. I think these alerts are an important part of avoiding those situations that Loop may not be able to prevent even with continuous zero or max temping (unexpected exercise, missed bolus, etc).

The code is here: LoopDataManager and elsewhere in that branch. My apologies as well...this code is very sloppy too - I've been hesitant to share it because I'm still learning swift and climbing the learning curve to understand the existing code. The whole thing is a quick hack full of debugging code that I haven't had time to clean up, but here it is. There are some other add-ons in that branch too (garmin watch connectivity...) that are also sloppy but working hacks at the moment. If there is interest, I can try to clean any/all of it up. But, officially, don't use it as-is...

[francesc0-cgm]

Great work @mbieweng maybe You can try to make this a pull request on loop repo

[elnjensen]

Thanks, @kenstack for getting this discussion started, and @dm61 for the insightful observation about the nature of the current RC implementation and the fact that it has no "memory". I don't have a lot to add at this point, other than to say that I think this is a good topic to pursue, and I look forward to seeing more discussion and possibly contributing in the future if possible.

[Kdisimone]

+1

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.