Suspend threshold uses predicted BGs but not current BG

[elnjensen]

When determining whether or not to recommend a bolus for carbs entered, Loop appears to be ignoring the current BG value and only using the array of predicted BG values. This can lead to unexpected behavior when the current BG is slightly below the suspend threshold and carbs are entered. If all of the predicted BG values are above the threshold, Loop will recommend a bolus even if the current BG is below the threshold.

Steps to reproduce:

1. Wait until BG is flat or rising.
2. Set suspend threshold to a value just slightly above the current BG (e.g. just 1 mg/dl or 0.1 mmol/L larger).
3. Enter a large number of carbs. Typically this will result in a bolus recommendation even though current BG is below threshold. (If it doesn't, scroll over the glucose prediction graph and you'll see that the first predicted value is above the threshold you set.)
4. Delete the fake carbs and set your suspend threshold back to a normal value! 😄

This is admittedly an edge case, but nonetheless doesn't match the documented function of the suspend threshold. I tried to follow the logic through the code, but I had a hard time figuring out where the current BG value is stored. There are some comments (e.g. this) that imply that it is included as the first element in the array of predicted BG values, but if that were the case, then I think the code should work as-is.

This seems like possibly where the current BG needs to be considered if it is not in fact part of the prediction array.

[kenstack]

@elnjensen I was looking at the same line but for other reasons. I am completely new to loop but in discussions with @Kdisimone my understanding is that the line in question is serving more to prevent excessive lows from interim BGs from bolus / temp basals. Ie if the math says that based on your required BG correction give say 3 units to end up at target in 5-6 hours, but 3 units in 2 hours based on older IOB would put you below that threshold, then it keeps reducing the bolus or basal until that threshold isnt violated. It is not a true threshold BG suspend (based on actual), but that is only my understanding and those closer to it should correct me.

I was actually thinking of opening an issue and implementing a true predictive suspend that is only based on true velocity, and add it as an OR to that line. My reasoning is that most APs today have a similar insulin based model to Loop - but there is always a "true velocity" override to guard against drops that are outside of the model. Examples include exercise, post exercise liver store rebuilds, bolusing for a meal and not having carbs absorb. The current IOB based prediction does a fine job normally I think, but to truly turn your liver back on "full" and have it raise BG when you are dropping requires a fairly long time window - longer then 60 min for novolog per the literature and my experience. The window on the current predictor I understand is a 15 min velocity predictor then it blends other effects. So I think a suspend should be a combo of ORs - the test that is currently done and a longer window true velocity predictor (BGactual+velocity*timewindow) where velcoity is of course negative if you are dropping and timewindow is at least 60 minutes. I can provide references if people are interested to this window. Your case would be an additional hard cut off OR.

[kenstack]

@elnjensen Ive been looking into this further - perhaps the way forward - since recent BG, velocity etc are not part of DoseMath, is to actually change the prediction that is handed to DoseMath. If you think about how many APs work, there is usually a multitude of predictions - model predictions (like loop - driven off IOB or whatever the model is), pure actual velocity predictions, hard cut offs like threshold suspend, and often 2-5 others based on heuristics (though Loop does blend in some heuristics via retrospective). So perhaps following that logic, we should offer multiple predictions, choose the one most appropriate for the situation (would have to decide on the logic here obviously), then DoseMath simply uses that choice (or blended choice as some APs do). Anyway, just a thought - this of course might be non-ideal for the longer term prediction that is shown to the user, but you should show multiple or some blended version or the one that was chosen. Or we can expose recent BG and velocity etc to Dosemath and put the logic there.

[dm61]

Hi @kenstack I've just read through the issue opened by @elnjensen and your follow-up comments. I think the issue opened by @elnjensen is just about an edge case of current bg possibly not being included in the prediction array. This a good point and should be addressed (I do not know how), but as far as I can tell it is a relatively minor technical issue within the context of current Loop algorithms. Please correct me if I am wrong.

@kenstack I understand your follow-up comments as addressing Loop algorithms in a much broader sense. If so, it would probably be better to open separate issue(s), but I'll still provide some thoughts here. I personally very much like how Loop is structured, with clear separation between prediction and dosing, and very little in terms of heuristics. So, whatever algorithm improvements we may consider, I think we should keep the basic Loop architecture as is. In particular, while there are few relatively small points we could modify (see #654 for example), I think DoseMath is generally fine as is, and we should instead focus on improving predictions in any further algorithm improvements.

As is well know, Loop bg forecast includes insulin, carbs, momentum (i.e. velocity) and retrospective correction (RC). In that sense, dosing (including suspend) is already "true predictive", based on given inputs. A prediction based on just velocity would seem completely arbitrary in comparison. Having multiple predictions is an interesting idea (btw, OpenAPS does that), but it seems that hopping between predictions or blending them in some ways is opening doors for more heuristics, which I am not terribly excited about.

In contrast, RC is not really arbitrary, and I think it could be further enhanced and improved. For example, I've been working on a version that takes into account not just the most recent discrepancy, but also past discrepancies, and have been running an experimental implementation of the approach for several weeks now, with promising results. I hope I'll have something ready for broader discussion soon (in a separate issue).

[kenstack]

@dm61 thanks much for the comments! I agree that there are lots of advantages to having a single algo. But would like to talk thru the disadvantages. Happy to separate the issues - Ill create one.

[elliroux]

@elnjensen @dm61 @kenstack @Kdisimone

Hello all. I'm wondering if there has been any movement on this issue (also documented here #668)?

Fast forward into the future and I am now running Loop through the microbolus workspace. I have run into the issue described above, where Loop recommends boluses while BG is below suspend threshold (and eventual BG is predicted to be higher).

My daughter's BG was low before dinner. I treated the low, entered meal carbs and issued a partial bolus for her food. Before her BG began to rise, Loop recommended a bolus (it happened twice before I figured out what was happening). Luckily, Ivan has built in several safeguards limiting the size of the microboluses - so the full recommended boluses were not delivered.

Still, it's frightening that a bolus would be recommended when actual BG is below suspend threshold. This is unexpected behavior, as it directly contradicts Loop's bolus safeguard information, described both in LoopDocs and directly on the Suspend Threshold screen of the Loop app.

Thank you for reading. If there is a better way to address this issue, I am happy to do so.

Hanne

[Kdisimone]

I can fix the error in Loopdocs to be more clear.

The current BG is not a part of the insulin dosing, it is from the predicted BG array (as the other Issues have correctly noted).

But I think that this (whether or not to use the current BG) is really not the issue that you are having problems with.

1. Bolus recommendations in Loop can only be administered manually. That IS part of the safety features that the microboluses is side-stepping.

2. Loop doesn't recommend boluses when any part of the future array is below suspend threshold. So fixing the issue about whether or not the current Bg is included (in the situation where current is below but prediction is above suspend) would only affect a single 5 min period even for the microboluses branch you are experimenting with.

3. The real issue is the bolus recommendations being automatically implemented by the microboluses branch. That work is not written to respect the safety logic that Loop has....nothing more than scheduled basals when (1) current and predicted BGs are above suspend and (2) current Bg is below target and (3) eventual BG is above target.

[elliroux]

Thanks for the insight, Katie. So far, the microbolus experiment has been a happy one, with the only complaint being an unexpected bolus during a low BG. I think a reasonable person could make the case that accounting for a person's current BG while calculating a bolus would be... logical. But, if the code is not changing then there is no need to harp on the issue. As for your other points:

1. I fully understand bolus recommendations in Loop are meant to be administered manually. Let's face it - the entire Omnipod Eros system was meant to be administered manually via PDM, but I digress... I am resorting to microboluses in an effort to ensure my daughter w/smaller basal needs receives insulin consistently. Those five minute temp basals <0.6u/hr simply don't deliver insulin. Microboluses ensure she gets those 0.05 or 0.10 shots of insulin as needed - no more waiting potentially hours overnight for insulin.

2. Fixing the issue about whether or not the current BG is included would indeed only affect a single five minute period. This happens to work perfectly, as microboluses are administered every five minutes when Loop issues a new bolus recommendation.

3. I understand Loop is meant to manage blood sugars with scheduled basals. Unfortunately, as stated above, five minute temp basals <0.6u/hr do not deliver insulin. A segment of Loopers - small children, particularly - have this particular pain point with the current algorithm. It is very difficult to keep our children in range when Loop issues temp basals that will never deliver insulin (until BG has risen so high that it eventually triggers a high enough temp basal).

That said, we are eternally grateful for Loop, its creators and those building on this powerful open source system. Consistent insulin delivery, however, can not be negotiable.

[ps2]

Fixed in 2.2