Allow bolus below Target Range via user setting

[CrushingT1D]

Many (dozens, as found in history of Gitter channel) of users have expressed a desire to have the Loop bolus wizard pop up with a suggested bolus even if their current BG is below the bottom of the Target Range. Users indicate their desire to bolus in preparation for an upcoming meal, even if their BG is below that target as long as they are not "low". Different users have different values to what they consider to be "low".

The concept is to add an an optional setting that allows the user to enter BG value to indicate their preference. Single field entry for BG (in preferred units as determined by which unit value is used in BG in Apple Health)

• If the lower of currently or any future predicted BG is at or below entered value, then do not suggest a bolus
• If the lower of currently or any future predicted BG is above the entered value, then attempt to recommend a bolus and display to the user if one is in fact suggested
• If no value is given by the user, then use the bottom of the Target Range (as it works today).

As to not add additional entries to an already long list under Settings, this could live under the Maximum bolus setting.

If the community supports this feature design, I will code up and submit a PR.

[ps2]

It does seem that what people consider 'low' is often lower than the bottom their target range. I've been thinking about what that means. The bottom of our target range is also higher than we would treat for.

What is the reason for this? Should the bottom of the target range be the value we'd consider treating for a low?

[beached]

I am of the mind that the number shouldn't be below 3.9mmol/L/70mg/dl without hacking the code.

[beached]

Also, why not under target range settings? Like workout but with a different lable? It's where I would look for it

[loudestnoise]

I support this idea Mr. Crushing T1D.
On Sun, Oct 9, 2016 at 1:05 AM Jim is CrushingT1D notifications@github.com
wrote:

Many (dozens, as found in history of Gitter channel) of users have
expressed a desire to have the Loop bolus wizard pop up with a suggested
bolus even if their current BG is below the bottom of the Target Range.
Users indicate their desire to bolus in preparation for an upcoming meal,
even if their BG is below that target as long as they are not "low".
Different users have different values to what they consider to be "low".

The concept is to add an an optional setting that allows the user to enter
BG value to indicate their preference. Single field entry for BG (in
preferred units as determined by which unit value is used in BG in Apple
Health)

• If the lower of currently or any future predicted BG is at or below
  entered value, then do not suggest a bolus
• If the lower of currently or any future predicted BG is above the
  entered value, then attempt to recommend a bolus and display to the user if
  one is in fact suggested
• If no value is given by the user, then use the bottom of the Target
  Range (as it works today).

As to not add additional entries to an already long list under Settings,
this could live under the Maximum bolus setting.

If the community supports this feature design, I will code up and submit a
PR.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#223, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL5JWLMSxJmZ-vKt2jcyJzmmB8XZRnPks5qyIQ3gaJpZM4KR6t8
.

[beached]

Sensor calibration error, blood test error and tue calibration factors being out. So my range is 5.2 to 5.8 to keep it around 5.5. But if i dip below as far as 4mmol oh well. Target is the goal but im safe to about 4mmol

[scottleibrand]

@ps2 with oref0 we use a target range of 100-100. The only benefit to a wider range would be to minimize the number of temp basals set. We would rather maximize time in range by getting the algorithm to temp aggressively as soon as it sees any indication of predicted BG going low or high. If the Loop target range were only used for setting temps, and the minimum allowed BG for recommending boluses were separate, I suspect Loop users would find something similar: that they can maximize time in range by setting a very narrow target range.

[beached]

@scottleibrand how does oref0 deal with sensor variability? Is it based on more than 1 value?

[scottleibrand]

Our primary calculations are based on just the most recent value. However, deltas are calculated comparing the current value to three different options: the five minute ago value, the average of the values from about 15 minutes ago, and the average of the values from about 30 minutes ago. We use the minimum of those three delta when determining how to modify the dosage calculated from the current value + IOB * ISF. So, for example, if the BG starts falling, we will react very quickly to that and will begin low temping (or canceling high temps) immediately. On the other hand, if BG starts to rise, don't take that fully into account until it shows up in the 30 minute average. The net result of this is that we will vary the temp basals more when BG data is highly variable, but are overall very good at preventing any overreactions for more than a few minutes from such variable data. And we bias towards being conservative against any high temps that might become problematic if we lose connectivity and they are allowed to run for the full 30 minutes.

[ps2]

I would support a change that always pops up the bolus interface, but adds more information to that screen so that the user can decide what to do.

To make an informed decision, the following pieces of information would be very useful.

• IOB
• If a low (below target range) is predicted, what is the min bg, and at what time. This should be displayed in a highlighted fashion, to be noticed as a warning.
• Bolus amount calculated to bring eventualBG back into range.

I think this is simpler from both a coding standpoint and from a user burden standpoint.

[beached]

One thing to keep in mind too is that the pump already will do a subtraction of insulin for a bolus that falls below target range but isn't low.

[CrushingT1D]

@ps2 I believe that the range used by Loop is not high/low marks. I believe the way Loop works is that it tries to adjust your BG to the center point of your range IF you are out of the range. However, if you are inside this range then Loop will NOT try to adjust you to the middle anymore. I believe this was done by design to save battery. Excessive very small temp basals on the system is this avoided (exactly what Scott mentioned).

Due to this, I use a tight range with a 10-20 point mg/dl gap such as 90-100. I do not use something like 100/100 or 80-130. I also believe that Loop users using very tight numbers may be having a yo-yo effect with things like high temping and low temping too soon as it is easy to blow past your range.

Another option would be to allow the user to enter a target point rather than use the calculated average (of the range). Then the range based functionality could remain and bolus decisions could be based upon that value. We could use some sort of rounding or averages to figure out how much standard deviation from the target BG is optimal for both user and battery life and then use this new value for the target (which is currently simply a /2 division as seen here:

Loop/Loop/Managers/DoseMath.swift

Line 83 in 8444e1d

let targetGlucose = HKQuantity(unit: glucoseTargetRange.unit, doubleValue: (minGlucoseTargets.minValue + minGlucoseTargets.maxValue) / 2)

and

Loop/Loop/Managers/DoseMath.swift

Line 97 in 8444e1d

let targetGlucose = HKQuantity(unit: glucoseTargetRange.unit, doubleValue: (eventualGlucoseTargets.minValue + eventualGlucoseTargets.maxValue) / 2)

[beached]

@CrushingT1D Not just battery but memory. Lots of little adjustments create a load of history records.

But I agree, and a non-diabetic does not have a rigid flat line of glucose and that should not be the goal. I like the idea of a target scalar and a setting for the tolerance from that value. The only caveat is that the target - tolerance > the log bg mark(e.g target 5.5mmol/L with a tolerance of +-0.5mmol/L would not go below the low mark of 4mmol/L) Not sure of the correct way to deal with this though

[CrushingT1D]

Hoping others will chime in on my last alternative idea in comparison to the initial suggestion and Pete's. I am not convinced that Pete's suggestion is easier to implement since it will require a new screen with messaging, content, visualizations and design, but if the group prefers that method usability wise I am happy to consider it.

[ps2]

@CrushingT1D Yes, for temp basals Loop uses the mid point of your range. For boluses it corrects to the top of the range.

The original focus of this ticket was to allow boluses when below range. I think we can do that without changing fundamental aspects of how Loop does its calculations, or adding new configuration.

The modifications I proposed do not involve a new screen, or visualizations. Just additional text on the bolus entry screen, showing IOB, and info about the low (if one is currently happening or predicted to happen).