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 https://github.com/openaps/oref0/issues/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 https://github.com/LoopKit/Loop/issues/293

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

[scottleibrand]

Except https://github.com/LoopKit/Loop/blob/00ce83da068ecc566bb8bec171ff8c5c3a1cc7d5/Loop/Managers/LoopDataManager.swift#L549 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?

[ps2]

I assume there is some level of BG you consider too low and would want to do everything you could to avoid it. :) That's where you should set the threshold, and I believe that should be clear how you'd do that. Let me know if it's not.

The other aspect is whether to make that decision based on current bg or predicted bg. Right now it's based on predicted bg. If you want to make it based on current bg, then you'd change minGlucose to glucose.first! on this line: https://github.com/LoopKit/Loop/blob/d4bdf59f46cf21024fef7cc8eedeaec8823a11f9/Loop/Managers/DoseMath.swift#L82

[ps2]

And also, just to be clear, this doesn't change behavior of Loop when your minBG is above the alwaysLowTempBGThreshold. If you are below range (but above the threshold, and minBg is above the threshold), and eventual BG is in range, Loop will let basal go up to scheduled, as it currently does.

[bharat]

I mentioned this in the pull request, but I'll reiterate here. My Dexcom has a non-cancelable urgent alarm that goes off at 55. I understand that there's a fair degree of error, but from a quality-of-life not-waking-up-everybody-in-my-room-in-the-middle-of-the-night perspective I'd love to see a min threshold at 60 not 55.

[eszcloud]

@ps2, thanks for the clarifications and further explanation!

While there are definitely low BGs that I don't want to have, given the time lag of insulin, I wouldn't want to have insulin delivery suspended based exclusively on a number, either predicted or current. I think that I would want to set it up so that it doesn't zero temp at all (as it does currently) based on either current or predicted bg values. The current setup works well for me because of how makes decisions with numbers in a broader context, and I would expect such a change to lead to more rebound highs, which would probably lead to more lows, and on and on.

A bg of 50 mg/dL with a derivative of 0 mg/dL/min is different from the same bg falling with a rate of 2 mg/dL/min or rising at 5 mg/dL/min. I want Loop to treat these scenarios differently rather than letting the single value that they have in common result in a single predetermined action for all three situations.

The differences between these situations are important in terms of how insulin delivery should be handled given the lag time for insulin to become active and also the lag for it to leave the body. By making dosing decisions within a broader context, Loop executes more nuanced actions. This is Loop's strength and is what allows it to perform effectively as a BG dampener, mitigating highs and preventing many (but not all) lows. Having Loop perform an operation based on a single value (and thus removing that value from context) reduces its power and ability to be effective. I understand why some would want this feature and hope that others would respect that I do not. As with all things diabetes, your mileage will vary.

[ps2]

@bharat Since this is forecast based, most likely you will be being zero temped long before your alarm goes off.

[ps2]

@eszcloud I understand what you're saying about wanting to generally use the full forecast in decision making, and I think that Loop still behaves mostly that way.

But I'm confused about why this small corner seems like a big issue to you. I'm really trying to understand. Let's say you set the threshold to 45. Are you saying that if Loop was predicting a low that dropped to 45, but later came up into range, that you would prefer Loop continue your normal basal rate?

[ps2]

@eszcloud Also, reading your comment above: "I would want to set it up so that it doesn't zero temp at all (as it does currently) ". It does zero-temp currently if minBG is below range and eventualBG is below range. I feel like maybe I'm not understanding you, because you would likely have seen this happen.

[eszcloud]

It's not the dropping part but rather the rising part that concerns me. I definitely want Loop to do what it can to prevent a low. Once the low has happened (or is still happening) but bg is rising and a high bg is predicted, I don't want Loop to wait to start letting some basal insulin on board. If Loop has been low-temping to avoid a low, then there isn't much iob, which makes the rebound really strong from carbs used to treat the low.

I think that this is probably so important to me because this is one of the aspects that has led to the largest improvement in my quality of life by reducing pinging back and forth once a low happens.

[eszcloud]

I can see how that wording would be especially confusing here.

I see zero-temping all the time. It's been a great thing. What I meant to say was more along the lines of that I would want to set it up so that it doesn't automatically zero temp based on a single value.

[ps2]

This really is an edge case in terms of how often it will affect loop's decisions, even at 55, I think. The way you're talking about it making a large effect in general makes me think we're not on the same page.

Reducing the threshold will make it even more of an edge case.

Can you describe a specific (actual numbers for threshold, minBG, eventualBG, currentBG) hypothetical situation that you think would be somewhat ordinary for you where this change would affect your treatment? That might help me understand either what I'm not seeing or how I can explain what this change does better.

[CrushingT1D]

Feels similar to the safety feature for disallowing a calculated bolus if below range except instead of bottom of range it is 55. I support having a single user setting that can be used in both places ( here and #223 ) that defaults to 55, but can be customized by the user to whatever they want.

[ps2]

@CrushingT1D Yes, I considered that as well.

[eyim]

Obviously I am on the other side of the arguement. This to me seems to be such a basic safety feature to prevent the worst case scenario of low blood sugars causing someone to pass out or death. Many things can go wrong to cause the predictions to be off or incorrect from bad ratios to incorrect info being entered. I understand the arguments others are making but to me the consequences of someone being at 55 and below and Loop not doing anything is worse.

[walker0]

I agree with @CrushingT1D I think the default behaviour should be a hard limit with a relatively simple way to adjust it. Users can change or disable this in the code if they wish for a different behaviour.

[ps2]

The main thrust of this ticket has been implemented as min bg guard: #365