Feature to disable inclusion of bg momentum in bolus calculations.

[ps2]

Users have questioned the inclusion of BG momentum in bolus recommendation calculations. If a bolus recommendation is made while BG is rising, then the bolus is delivered, and then BG starts dropping, the forecast can change rapidly.

I see a few options here:

1. avoid including BG momentum in bolus calc when momentum is positive.
2. avoid including BG momentum in bolus calc always.
3. limit the effect of bg momentum by the slope of BG momentum; i.e. assume a faster rise/drop will level out more quickly than a slow rise/drop.

[thebookins]

Proposing #372 as a fix for this issue. My preference currently is for option 1, as it is the most conservative (results in the smallest bolus). Loop can always correct with temp basals if the bolus was underestimated.

#372 currently ignores any retrospective effect when calculating the glucose prediction without momentum. It's not clear to me at the moment whether or not this effect should be considered.

[loudnate]

The only reasons I've seen cited for this issue are anecdotal, and removing momentum from prediction just a theory. I'd suggest you log the difference in predictions over some period of time to quantify how much impact this change has. You should see an example of how that's done with retrospective correction.

[thebookins]

Good idea. I'll do that.

[thebookins]

Decided to follow the suggestion of @loudnate to log some data on this issue...

Here's an example of a 24-hour period with some messy glucose data (on holidays, lots of swimming and different foods) showing the three different glucose predictions.

Ignoring the discontinuities in the traces when boluses are given (blue circles), the three predictions are significantly different, and the predictions with momentum and retrospective effect are both more 'peaky'.

Zooming in on a four-hour period:

If a bolus was given at the time represented by the red arrow, the correction bolus calculated using momentum and retrospective effects would be twice as large as the bolus using the prediction without momentum. Also, if the bolus was given just 15 mins later, the bolus with momentum and retrospective would be almost the same as the one without. I think it's this rapid variability in bolus suggestions that is concerning for users - particularly parents.

In my opinion it's fine to use the momentum and retrospective effects for setting temp basal rates, because the recommended temp basal is re-evaluated every five minutes. What I am wondering is whether such a variable signal should be used for bolusing since once the bolus is given it 'locks in' those calculated effects.

I agree completely with @loudnate that the reasons for this issue are largely anecdotal, and that it's a significant change to the algorithm. I'd love some suggestions on data that might support / contradict these assertions. Both would be useful.

[walker0]

@thebookins If you have a branch that logs the different predictions I'd be happy to test it for a while and add some more info into the mix.

[trixing]

Instead of disabling, maybe we should expose "weights" in the UI to being able to experiment with the influence of all these factors? I have some examples I can dig out later where momentum was actually also not helpful (fast rise after meal+bolus essentially, where eventually insulin catched up, amplified by the fact that we have a 6x factor between normal and temp-basal.

…

On Thu, Jan 26, 2017 at 10:42 AM, Matt Walker ***@***.***> wrote: @thebookins <https://github.com/thebookins> can you overlay those graphs on the same scale or post raw data. If you have a branch that logs the different predictions I'd be happy to test it for a while and add some more info into the mix. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#370 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE2akxJYxeNoh4K0BY044csL_jGkiRNks5rWGp8gaJpZM4Lprc_> .

-- Jan Dittmer <[email protected]>, http://l4x.org

[thebookins]

@walker0 I've pushed another commit to #372 that logs all three eventual BGs to mlab. I also have a very hacky Python script that pulls the data from mlab and graphs as per above, which I can share if it would be helpful. Great to have some more data in the mix!

[tynbendad]

also, most bolus wizards i've seen show separate numbers for the contribution from carb correction and the contribution from BG correction (less the IOB), as well as the total. loop gives no such help, i know its simpler the way it is, but even if it uses prediction with momentum to calculate the result, it could also show a carb-only correction separately - i could then at least teach my kid to click on that one instead when bg is rising...

[thebookins]

@tynbendad I agree - I often find myself mentally calculating the carb-only bolus using the carb ratio, to make sure that the bolus makes sense. It wouldn't be difficult to calculate a 'correction bolus' from the prediction before the carbs are credited, and then the total bolus with carbs taken into account.

[tynbendad]

fyi, we're now using the change (#372), after testing on backup rig for several days.

[beached]

One option, maybe I am missing something, is to limit the total current momentum corrections to that which can be adjusted by a temp basal(active insulin) to reverse up to a comfortable time period(maybe DIA/2).

[thebookins]

@tynbendad and anyone else who might be testing #372, we are finding that if a high temp is running when a bolus is given, Loop subtracts from the bolus whatever net basal is yet to be delivered and this can result in very small boluses when upward momentum is turned off. One potential problem with this is that if Loop is at or near the max basal rate, for the next 30 mins the temp basal is effectively dealing with the carbs, and not 'available' to deal with any unexpected rise in BGL. Curious whether you have seen similar behaviour.

[tynbendad]

Paul, i looked thru the graph for the last 48 hours and see at least 3 bolus's while high temping near max (our max basal is 1.8U/hr):
58g / 4.2U = 14g/U, @1.8Ubasal,15IC
40g / 1.75U = 23g/U, @~1.5Ubasal,18IC
30g / 2.15U = 14g/U, @1.8Ubasal,15IC

It doesn't seem to be subtracting the basal for us, but I can't really see when the basal's start/end from the graph - I can PM you our site if you want to look closer...

[rsuvalle]

We're having the same issue with our daughter. I think BG momentum is great for temp basals, but for corrections it has proven problematic for us. For example, last night my daughter was 180 going straight up (after Loop under bolused her for dinner) so I hit the bolus button and it wanted to give her 2 units. Her ISF is 130 so 2 units would drop her 260 points and I could already see that she was starting to level off, so if I gave her the full 2 units she would most certainly go low. Instead I gave her 1 unit and she still ended up going low. So I'm hoping there's an easy fix for this in the works, perhaps a way to suspend BG momentum within the app would be ideal.

[Kdisimone]

closing issue see comments at #454