Repository navigation
Allow bolus below Target Range via user setting #223
Description
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.
Activity
[-]Allow bolus below range via user setting[/-][+]Allow bolus below Target Range via user setting[/+]ps2 commentedon Oct 9, 2016
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 commentedon Oct 9, 2016
I am of the mind that the number shouldn't be below 3.9mmol/L/70mg/dl without hacking the code.
beached commentedon Oct 9, 2016
Also, why not under target range settings? Like workout but with a different lable? It's where I would look for it
loudestnoise commentedon Oct 9, 2016
I support this idea Mr. Crushing T1D.
On Sun, Oct 9, 2016 at 1:05 AM Jim is CrushingT1D notifications@github.com
wrote:
beached commentedon Oct 9, 2016
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 commentedon Oct 9, 2016
@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 commentedon Oct 9, 2016
@scottleibrand how does oref0 deal with sensor variability? Is it based on more than 1 value?
scottleibrand commentedon Oct 9, 2016
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 commentedon Oct 9, 2016
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.
I think this is simpler from both a coding standpoint and from a user burden standpoint.
beached commentedon Oct 9, 2016
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 commentedon Oct 10, 2016
@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
Loop/Loop/Managers/DoseMath.swift
Line 97 in 8444e1d
beached commentedon Oct 11, 2016
@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 commentedon Oct 11, 2016
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 commentedon Oct 11, 2016
@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).
10 remaining items
johnmales commentedon Oct 12, 2016
I agree with the approach that @ps2 has suggested, which is similar to what I suspect most will expect when dealing with some form of bolus wizard. The currently confusing behaviour of the app is not suggesting a bolus when one would "normally" be given, and not bringing up the bolus wizard.
The common scenario is blood glucose below target range but still "acceptable" with carbs being ingested. Under this circumstance insulin is likely to be required and the bolus wizard should suggest insulin based on the eventual blood glucose.
The other common scenario is where the blood glucose is already "low", and I expect most will wait until blood glucose is "acceptable" before bolusing, however "low" and "acceptable" are defined.
elnjensen commentedon Oct 12, 2016
I think the solution proposed by @ps2 would work well for me. Info about IOB and predicted BGs would definitely be helpful there. Another thought would be to also explicitly show the negative correction as the pump bolus wizard does - I sometimes find myself trying to puzzle out exactly how the suggested bolus was determined. To some extent that's a separate issue, but related to the overall theme of having more info right in front of you when bolusing.
Thanks, @CrushingT1D for bringing up this issue.
ps2 commentedon Oct 12, 2016
This is what I'm working on right now:
dm61 commentedon Oct 12, 2016
I think the approach proposed by @ps2 and illustrated by the screen above would work really well. Including IOB on the Bolus screen is also a great idea. One minor issue would be the case when the lowest predicted bg is now, i.e. at time zero. In that case, the message would look a bit awkward, e.g. "Low BG of 48 predicted in 0 minutes...." but that's fine - I do not think this would confuse anyone or require a special-case announcement.
eszcloud commentedon Oct 12, 2016
In @ps2 's example above, I think it would be helpful to have a few more fields: recommendation based on carbs and recommendation based on correction of eventual bg.
eszcloud commentedon Oct 12, 2016
I like @CrushingT1D 's idea to have that info all the time in the bolus screen regardless of prediction and to be particularly in the spirit of YDMV.
Having Loop do as much of the bolus arithmetic as possible is helpful. Even if the user will override it, it makes decisions more informed.
One place that comes to mind immediately is that if a blood sugar is high and I correct, I'll get extremely low predictions based on the bolus because I take into account decreased insulin sensitivity for high blood sugars. (This may be a place to enhance Loop's prediction algorithm as I don't think that this is in there yet.) If during that window when I see really low predictions I eat something, I still want to bolus for the carbs and having the arithmetic done for me would be very helpful even if Loop recommends a 0 u bolus as it eliminates having to pull out a calculator to precisely calculate the dose for 1 u to x g CHO. Giving information as @ps2 suggested makes this easier.
CrushingT1D commentedon Oct 12, 2016
To respond with a clarification above. My example did have a recommended bolus that was taken into account.
" They are currently 91, but if they bolus we predict they will drop to 68 before eventually finishing at 125?"
If they did not bolus in this example they would spike to 200+
CrushingT1D commentedon Oct 12, 2016
Sounds like most folks are support @ps2 's solution. Let me know if you'd like any help.
eszcloud commentedon Oct 12, 2016
To calculate the correction, would you use current bg or eventual bg? I know of people who use each, and both would be useful.
eszcloud commentedon Oct 14, 2016
@ps2 What are you envisioning would be in the bolus screen when carbs haven't been entered? Would it provide the calculations for a correction (both + and - depending on whether blood sugar is above or below target)?
ps2 commentedon Oct 15, 2016
@eszcloud As it does now, it will provide a recommendation for carbs if your eventual BG is above range. Otherwise, it will recommend no insulin.
trixing commentedon Oct 22, 2016
I like ps2 suggestion.
My Animas Ping (soon to be replaced by the Medtronic) has a very similar screen on the bolus wizard with all the details. It also shows for reference though the calculated bolus based on carbs taken so you can verify the math (it's actually on 2 screens as it is a lot of information), e.g.:
IOB: 0.7u
BG (manually entered): 50
Target: 120
ISF: 140
Insulin based on bg: -0.5u
Carbs (manually entered): 30g
I/C: 15g
Insulin based on carbs: 2u
Recommended dose: 2u - 0.5u - 0.7u = 0.8u
Would be nice to have all the detail on the Loop app as well to give some level of confidence. Especially important it seems when transitioning between systems.
ps2 commentedon Mar 29, 2017
Minimum BG Guard has been implemented: #365
Add mock settings for testing purposes (#223)