Safety Feature - Suspend on low BG regardless of projections

[eyim]

We ran into a potentially dangerous situation where bg went low but the projections predicted him to go high so it stopped low temping him. I think that there should be in the algo, a limit that if the bg falls below, it will suspend the basal regardless of projections. This could be because the carb count is incorrect, iob is incorrect, setting could be incorrect, or any number of different issues. For oref0, we put a hard limit in place at 55. Something similar would be good to implement in Loop.

You can see the discussion around this for oref0 at openaps/oref0#84

Attached is the chart showing the scenario of what happened with Loop tonight

[eyim]

Yes Loop was working. During the previous period when bg was dropping where it was low temping, the predicted eventual bg was below target. It was predicting eventual bg to be 55. This is because of the impact of glucose momentum and the retrospective correction impact outweighs the carb and insulin impact. Once you hit the low point, Dexcom basically gives you either a low or 40 bg reading. After a couple of these flat readings, the impact of glucose momentum and potentially retrospective correction are minimized and the projected bg went back above target. In reality though, you are in an even more dangerous place because the Dexcom reading don't show a low below the 40 / low reading.

[eyim]

I have not changed any settings related to the allowPredictiveTempBelowRange flag

[eyim]

Loop for me definitely doesn't 0 temp all the time he is below range. It is always based on projected bg. If he is below range and is projected to go above range, it will resume normal insulin basal rates but won't high temp him.

And generally I think that is the right thing to do rather than have a hard cut off at the lower end of the target range. What I am thinking is a hard cut off at much lower level --55 or 65.

[eyim]

Yes, with negative iob (or any other factors) causing the prediction to be above target range, it will not low temp you if you are below target. It will instead return normal basal levels. Here is an example from last night where it kept turning off the basal and then turning it back on throughout the night as the negative iob built up and caused the prediction to go above target even though the entire time he was below min target of 100

[scottleibrand]

@CrushingT1D I don't think that is correct, per #293

The "default" is only used for tests. The "real" default is True.

[scottleibrand]

Except

Loop/Loop/Managers/LoopDataManager.swift

Line 549 in 00ce83d

allowPredictiveTempBelowRange: true

where it actually calls the function sets it to True, as noted in the issue. The PR just removed the confusing default of false and instead set false in the unit tests that expect it. For @eyim's issue, I believe the code matches the behavior he is describing.

[ps2]

Yes, the issue described here is how the code works. If you have a minBg below range, but eventual is in range, Loop will let your basal go up to the scheduled rate. This is of course what would happen without Loop, or if Loop was not functioning.

@CrushingT1D The PR with the change for default setting has been accepted and is in dev; the ticket just hasn't been closed, as that change hasn't hit a release yet. Hoping to do that soon.

I've been considering a couple options for dealing with this; I think @eyim is correct that we'd want to shut off basal completely when low enough. The current behavior is to handle situations where you're low, but rising. The situation @eyim shows is more dire.

[ps2]

@scottleibrand is right that it's only called in one place from non-test code, and it's set to true there.

[eyim]

@ps2 Thank you Pete. I think this does add an extra layer of security for the nightmare scenario.

[ps2]

I believe oref0 threshold was 60. I used 55 mg/dL here, as we will low temp based on any forecasted point being below the threshold, not just current bg.

[eszcloud]

Women with t1 who are pregnant or who are trying to become pregnant often target a blood sugar of ~ 65 mg/dL and go to great lengths to avoid high blood sugars. This is a scenario in which Loop would be extremely beneficial at keeping bg on the lower end while avoiding lows and mitigating rebound highs.

With a target bg of 65 mg/dL, a deviation of -15 % (not unreasonable given the accuracy of current devices) would register a blood sugar of 55 mg/dL even though the blood sugar was on target. Preemptively zero-temping would lead to an unwelcome rise in bg at a time when someone is likely going to great lengths to avoid just that.

When I have used the equivalent algorithm without allowPredictiveTempBelowRange set to allow temp basals even while low, I saw more rebound high bgs and have been very happy having those minimized with the current configuration. If bg is 50 mg/dL with a rate of change > 3 mg/dL/min, having Loop automatically zero-temp would exacerbate rebound highs. I have found that minimizing rebound highs not only avoids a high but also avoids the subsequent ping pong effect of lows and highs that can persist. As I understand it, the proposed changes would undo that feature.

Although hardcoding this feature may work for many, it also fundamentally limits Loop's utility for other people who have different considerations.

In the interest of ydmv, what about setting this as a toggle switch that individuals can turn on/off and perhaps even with a user-definable value so that individuals can select when they would want this to come into effect, particularly given that it operates based on any forecasted point?

[scottleibrand]

(Personal opinion only, as a non-Loop-user myself.)

I think @ps2's approach is safest overall. If someone has different requirements like @eszcloud outlines, then the threshold below which low temps are always triggered is a single variable in the code, and they can change it to a lower value like 45 to get some extra buffer, or set it even lower to disable it. If some people actually end up doing that and having better results than with it at 55, then it might make sense to make it easier to change, but for now it seems to me that editing the code is the best approach overall to allow for (partially) disabling hypo safety features.

[ps2]

Thanks for your feedback @eszcloud. I haven't heard from any others keeping their target that low, so that's good to hear about that use case.

I think the current option would be to change that number yourself when building your loop. If this becomes a more widely requested change, then we could look at configuration options.

[eszcloud]

Thanks for being so receptive to another perspecitve, @ps2.

Separate from considerations for women who are and are trying to become pregnant, I really like the way the current algorithm works on this front with using the predicted bg values rather than a single point that may dip low. As I mentioned, I used it previously before temps could be enacted while bg was below target, and I have found the change to be a large improvement for me.

As I understand the proposed implementation, it would undo a feature that has benefited me and thus be a step backwards for me.

With the implementation that you envision, will it be possible to completely disable this feature, particularly given how it is integrated and looks for any predicted bg value below the set threshold?