Automatic Bolus

[erikdi]

This will add an option to automatically give a Bolus instead of higher temping the Basal rate.

The logic is pretty straightforward if enabled:

• recommendedTempBasal() will never return a higher basal rate than the scheduled one.
• the calculated recommendedBolus is adjusted downwards to 70% and a minimum threshold of 0.2 units is applied (configurable in code in LoopSettings)
• a minimum gap of 7 minutes is enforced between automated Bolus (~2 glucose readings for Dexcom)
• no automated bolus will be suggested if the carbs got changed in the last 2 minutes to allow time for correction.

This just ports the core logic without any UI changes apart from adding a single setting. If the setting is disabled, the behavior should be exactly the same. It is based upon the other two pull requests which add IOB limits and refactor the bolus code.

I have extensively (~9 month) used this code as part of my large changes here https://github.com/erikdi/Loop/tree/dev . This particular branch is only lightly tested in isolation. I think there is enough safety code in here to not accidentally give too much insulin, but it is probably best to test carefully (e.g. start with even lower thresholds above).

I'd consider this as a start of a discussion how to get this feature merged. It tries as best as possible to fit in the current code and many further optimizations are possible which I intentionally left out to make the initial review simple. It would probably be best to get the 2 dependent pull requests reviewed and merged first.

[ddaniels1]

Erikdi, have you eliminated the pre-meal button for the note button? did you eliminate this feature? It was useful, perhaps we can add it to the pre workout button and change that to a temporary target which includes both workout, pre meal and suspend pump options. I will work on this.

[erikdi]

@ddaniels this does not eliminate the pre-meal button (or at least should not). That change is in my main "dev", please leave a bug report there.

@ps2 this updates to latest upstream/dev and incorporates the latest change from the IOB push.

[ddaniels1]

We have been using this branch for the last two weeks and I think it works really well. Thanks @erikdi for your contribution. One thing we notice is that it works great for meals when we have either intentionally, for example in a pasta/equivalent meal, underbolused up front, or unintentionally done so for a bad carb count.

I think for fasting periods particularly overnight it is perhaps less than ideal. See the attached image of last night which is typical. The swings used to be more intense before i dropped the <automatedBolusThreshold> to 0.1. I am going to increased the insulin sensitivity to attempt to get a smoother landing but at this point the boluses cause an overshoot and then loop zero temps, then gets too high, etc. I may try to drop the suspend threshold a bit as well. Have you had any of these issues?

One option would be to code in to use the feature only if there are COB and if not default to temp basals for the carb free period. Thoughts?

[francesc0-cgm]

@ddaniels1 This is the same issue i had using smb on openaps when i tested it. 0.1 it is also too much for kids or when isf is higher. When with openaps i edited the code using 0.05 bolus it worked really well. But you need a x23 or above pump to do that. On adults with lower isf you won’t have that issue. If it can be coded only where cob is on and with 0.05 bolus i will give it a try. Another problem i found using smb on a kid is that after a smb zero temping for long time could break the cannula. Last Thing is after a meal if the kid starts to run everywhere basals could be stopped in a while and not so much insulin has been released. With smb once insulin has been injected nothing could stop it. However This could be partially corrected using 0.05 bolus

[francesc0-cgm]

Ah, i forgot! If basals or isf are wrong on smb you could get severe lows too

[erikdi]

What @francesc0-cgm said I observed as well. SMB is much more sensitive to too aggressive basal and isf settings as it delivers the insulin much earlier than high temping and can't adjust on the fly if it is overshooting. It might be worth experimenting with making them less aggressive at night at least.

The resolution of 0.1 or 0.05 shouldn't be that much of an issue in theory as you could do high temping in between 0 and 0.1 (the current branch does not as I didn't know how to program the interlock), or alternatively a combination of bolus and low temping.

[francesc0-cgm]

I should try with my 723 to set automatedBolusThreshold to 0.05. Next week i will give it a try

[scottleibrand]

For now I think SMB refers just to the oref0 microbolus implementation; which is usually paired with a zero temp for hypo safety, and implements a “super bolus” approach to front-loading the insulin that would normally be delivered via basal. Do I understand it correctly that this implementation is a microbolus based approach of delivering the insulin that Loop would normally deliver over 30m? If so, we can probably leave off the S in describing it. :-)

I agree tha microbolusing is only safe to do with well tuned basals and ratios. For that reason, we require the use of autotune and autosens in oref0 before turning on SMB. I don’t know what other mitigations might be appropriate in Loop where autotune isn’t integrated, and/or if it makes sense to implement Loop’s equivalent of autosens first before making microboluses widely available.

Happy to provide any input needed on that or anything else we’ve learned in doing SMB.

[erikdi]

Scott, thanks for your feedback. I agree that good tuning of the loop is more important in the automatic Bolus case. I can recommend having autotune running; we use this script https://github.com/trixing/nightscout_tools/blob/master/run_autotune.sh which makes it rather simple to setup as a cron job.

The "S" in SMB you can control with the automatedBolusRatio variable which by default is set to 0.7, which essentially translates to giving 70% of the calculated dose automatically .

The second variable is the automaticBolusInterval which tells it how often it gives bolus. With the default of 7 minutes, it translates back to 2 CGM measurements, 10 minutes in practice.

This means with the default it delivers 70% immediately, 81% after 10 minutes, 85% after 20 minutes, etc. Tuning it down to 50% or lower makes it more similar to SMB IIUC (50%, 75%, 88%, ...), or even 20% (20%, 36%, 48% ...).

It would be a major enhancement to do be more aggressive with COB. That is currently not implemented though.

There is no insulin front loading going on right now, though that would be easy to implement by adding to the recommendedBolus the scheduled Basal insulin.

For the brave - we have been running with 0.9 - meaning we essentially can go without worrying about manual bolus even after food.

[peterlynton]

@erikdi I'm trying out your Automatic Bolus code using Spike as CGM source and mmol/L as units. All is working well for me and could well be a great solution for my son who often forgets to bolus. The CGM reading and Glucose graph in Loop are now displayed in mg/dL, whilst the Widget continues to show mmol/L. Do you know where in the code to look so I can get back to mmols please?

[erikdi]

@peterlynton This sounds like #747 and not specific to this pull request?

[peterlynton]

@erikdi Yes looks like #747 is the cause thanks.

[scottleibrand]

In our experience an automatedBolusRatio of 50% and automaticBolusInterval of 3m (which usually means every 5m synchronized with the CGM) is safer than larger less frequent boluses, as you can be more responsive when the CGM data changes direction.

I would also consider not using eventualBG directly to calculate the insulin dose when the eventualBG is higher than current BG. In oref0 we use the minimum predicted BG starting at 90m from now out to DIA. That prevents us from dosing too aggressively when BG starts rising with negative IOB, which otherwise can cause rebound lows like in the screenshot above, as actual insulin needs at the time are likely lower, and IOB is not as negative as it appears. The same approach helps when dosing for COB, too.

[erikdi]

Alright, the ratios are easy to change if there is consensus.

One worry I still have with the current approach as coded is that we are always underdoses, as I disable high-temping for safety reasons - to not give a bolus and have a high-temp which I cannot cancel. The final dose is rounded down. Hence we can be up to 0.049 short. I actually considered rounding always up to have the bolus be slightly more aggressive and then relying on low temping.

I'd like to keep the calculation changes to the insulin correction out of this pull request as I think they should be as consistent as possible between delivery methods.

The way I see it DoseMath.swift currently uses eventualGlucose as long as minGlucose and eventualGlucose are above minimum target. @ps2 what do you think about that change? I could create a separate pull request for that.

[francesc0-cgm]

I haven’t already given it a try but i will shortly.
I thought about it however. Using it with spike i have often big jump on BGs and it could become dangerous...any protection on sensor issues @erikdi ?
Another question...reducing to 0.05 to make tiny bolus on a kid i will increase the frequency of bolus so with a bad sensor or when my kid starts to run and bg starts to lower will i have more problems?

[Lytrix]

@erikdi, this feature is working great for me especially with Fiasp. It really solves having longer higher values for me big time. Also nice job in integrating all the functions in the current code! (I am also working and testing on parts the OmniPod Rileylink integration codebase)

I tried the SMB on OpenAPS, but I really missed the offline flexibility and stability of the RileyLink+Loop.

Regarding merging this feature I do agree with having at least a stable ISF and Basal Rate before using this. But the AAPS required walkthrough steps are not something that is really a 'Loop' way. Loop wants to give you the 'less is more' way.

@scottleibrand do you think integration in Loop like AAPS is a must have solution based on your experience with implementation, or can we keep the Autotune development outside of Loop and implement a simple checker externally like a setting up a heroku docker image with an simple API which can be used to perform an autotune on the latest version?

My 2 cents would be for a first release:
1. More strict max Bolus. I really like the failsafe of SMB of not issuing more than 0.6U in my case. I think it would be good explain some safe values or restrict them in the code itself even.
(In the first run Automatic Bolus gave me 2.4 and multiple 0.8U's for 30 carbs, that was already too extreme even having done some autotune tweaking after 3 months. So this could get really dangerous. Part of my issue was that my Carb rate was too low, so after correcting that all was well)

2. Warning message. A warning message for users who want to be using this feature, how (un)safe it is to use. (Like ludicrous mode on a Tesla):

• Do you really want to do this? Basals and ISF < 70% in range based on Autotune is not advised.
• Basal rates and ISF > 90% in range after check with Autotune, enjoy autoBolus!

3. Automated Bolus Ratio in configuration settings
The 0.7 automatedBolusRatio is ideally part of the configuration on the settings page to be able to change this setting and increase when it feels all is working as expected.

4. Communication page
A how to page that explains the needed steps you need to make to make this a safe option with the current solution available like autotune and some FAQ's on when it goes wrong, like the OpenAPS does. That really helped me how to adjust settings accordingly.

[rsilvers129]

@erikdi I am interested in trying this but it needs to be updated to work with the current dev. Also, that feature where it would only work when carbs are on board seems important. And then @scottleibrand comments about timing, ratios, and about not directly using eventualBG when it is very high seem important. He is the SMB expert so it makes sense to just use his experience. I have had eventualBG's show 600-800 when I was perfectly level and under control at 110 BG. If you take everyone's commends and push an updated version of this that works with dev, I would love to try it.

[erikdi]

Based on the feedback on #707 I'm not willing to put further work into merging this. For G4/G5 users the current branch seems to work pretty perfectly (minus backfill).
I'll probably have to figure out how to back port G6 support in the coming month.

Rant

The constant refactoring which is going on upstream (CGMBLEKit, PumpManager, etc) means that keeping up branches is a pretty time consuming job (dev...erikdi:dev has 139 commits, 7000+ lines added). Plus also all the recent bugs filed makes me think that the current head is actually less stable than what this is based on. I have been using my branch with SMB (erikdi@65e13d1 is the latest stable revision I deployed I believe) now for close to 1.5 years without major issues.

Based on the feedback on the pull request above I've little to no hope to get any of the features merged anyways (Food Manager, Kids mode, etc.).

Sure there are a few bugs and features I could add but nothing really game changing. "Autotune" and "Autosense" would be nice for sure eventually. But then, why not put the time into developing an offline Rileylink driver for AndroidAPS instead?

Re the eventualBG: I have only see this happen for really large carbs entries (where the high eventualbg uncorrected work as intended). "Jumps" in CGM value are smoothed over using the current prediction algorithm. MaxIOB and MaxBolus prevent the worst.

/rant

Probably time to close the pull request.