Automatic bolus dosing #1219
Automatic bolus dosing #1219
Conversation
|
awesome wauu! |
|
Can we revisit the discussion from #707 around implementing a maximum Insulin-On-Board limit now? Having run more or less the same automatic bolus code for 2 years I still believe it is a necessary safe guard. Given that most people run this unattended the 40% of max bolus per Loop will not limit the amount of insulin delivered in any meaningful way in practice and makes the use of it unsafe. Let's say you have a max-bolus set to 5. It would deliver 2 units in each iteration, ie. 4U after 5 minutes, 6U after 10 minutes, or 10U in 20 minutes when you realistically start to feel the effects of the wrong dosing. At that point it requires quite a bit of fast carbs to get out of it. Because the carb amounts are not limited either, it is pretty easy to get into this state by entering the wrong carb amount (let's say an inexperienced caregiver mixes up total weight of food and carbs). |
|
@erikdi Yes, I do think a max iob guard might be necessary here. Not as a therapy setting that people use to often limit dosing, but as a protection for the kinds of scenarios you describe. |
|
I agree it makes sense as a safety feature. Very similar issue as with OpenAPS with SMB enabled (OA has a max iob setting, though it is user configurable). Of course this also gets tricky with mealtimes, particularly for those with high carb diets. |
|
Since there are two approaches for this, is the intent that they go head to head and validate outcomes or will the two at some point merge? |
|
Definitely merge👍💕 |
|
@alevar1975 The question would be how. If branch A does X and branch B does Y the union of the branches A&B doesn't mean the union of results X&Y. It in fact makes a whole new thing. |
|
@ps2 Potential safety issue, would like your thoughts on. I just started a new G6 sensors so have no readings. I put in a manual BG entry at 9:12 PST. I have gotten three automatic boluses in that time at: 9:13 for .3U (good) After the last .1U the manual input was out dated and loop doesn't count it. But per entry being able to get 3 decisions seems like a lot because automatic boluses can stack really fast should we be more demanding of recent readings? Loop making decisions 10 minutes out from last reading after already giving two boluses might cause issue. And happy new year! EDIT - I have a report if it at all matters but it'll be cluttered with setup since I also just switched from mdt to pod. |
|
That is expected behavior at this time. Loop will continue to dose as long as BG is < 15m old. It's similar in behavior to how it works with Temp Basals, too. This is actually more conservative than a temp basal would end up delivering. A temp basal over 30m is 100% of Loop's calculated dose. In your case, assuming Loop called for .75 U (based on your initial 0.3 dose being 40% of total), using temp basals Loop would deliver 0.75 U. Using boluses with partial application, you got 0.5 U delivered, or 67% of the total dose. |
|
I thought so but always want to make sure. It was for .85 and I got .6 so that'd be 70%. I don't know if I'd say it's the same though. 70% in 10 minutes where as the tmp basal would be only at 33% in the same time frame. Given enough time they even out. |
|
An update now that I've been running this almost a week. No real bad episodes, or any episodes really, have happened since that first initial scare. Seems to handle long meals better (great for low carb). I think pods like it a lot better than temp basals. |
|
We are likewise quite pleased after a week. I'd be curious to test with slightly more aggressive application of the calculated need. Am I reading the code correctly that by changing "bolusPartialApplicationFactor = 0.4 // %" to 0.5 it would apply half of the calculated corrective bolus each dosing interval rather than 40%? Nothing else would need to be changed? |
|
@jbwittmer, that’s all you need to change. But remember that you need to leave room for loop to react to bg going lower than expected, like overestimating carbs, exercise, etc. 40% is already a huge jump from Loop’s previous effective partial application factor of 17%. |
|
@ps2 so to mitigate the effect of automatic bolus that for my 6 years old son is way too aggressive, i can set it at 0.3-0.25 to put 30-25% ? Thank you Pete.
Inviato da iPhone
… Il giorno 8 gen 2020, alle ore 15:00, Pete Schwamb ***@***.***> ha scritto:
@jbwittmer, that’s all you need to change. But remember that you need to leave room for loop to react to bg going lower than expected, like overestimating carbs, exercise, etc. 40% is already a huge jump from Loop’s previous effective partial application factor of 17%.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Just to verify again, this feature will be able to be turned off/on once implemented? I have not needed a correction bolus in a very long time and sometimes my cgm predicts that I will be much higher than I ever actually get. But I’m on such low doses and low carb, that I don’t need correction boluses. |
|
@francesc0-cgm I think it's best to look at increasing partial application not as increasing Loop's "aggressiveness", but rather increasing Loop's confidence in dosing. The top variables you should play with if Loop is being too aggressive (i.e. calling for too much insulin) are ISF, basal, and target range. So I would recommend you try adjusting those first. Of course all the variables play out together in treatment, and cannot be entirely separated, so moving to a bolus dosing strategy might mean that what was once an effective ISF value under temp basal strategy might be different now. |
|
I've been running |
|
At some point the various parts of the Loop forecast will likely have confidence terms associated with them, which will give us a better way to adjust partial application automatically. For now, tuning Loop is already fairly complicated, and reducing the number of free variables helps most people find their best settings quicker. Adjusting the partial application factor may make sense to vary based on the hour to hour variance of your individual response to insulin, but it is not a good way to adjust the average amount of insulin you need for a given situation. If you're someone with very reliable response to insulin, carbs, etc, then maybe you could consider bumping up PA factor. If you're someone with a very unreliable response to those things (caution! bad settings can look like this, but is a different situation), then maybe 40% is too high. |
|
Hello |
1 similar comment
|
Hello |
|
Search the Looped group for "autobolus spike" and you'll see someone has
put that together.
https://github.com/Andrei0105/Loop/tree/spike-autobolus
…On Wed, Aug 12, 2020 at 5:03 PM macbenoit ***@***.***> wrote:
Hello
Is there a possibility to implement autobolus with spike ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1219 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALFNVQML42P4MRLXN4UR3G3SAMUUJANCNFSM4KAWNJ6Q>
.
|
|
@ps2 How does an override affect autobolus, specifically if the override is turned on after carbs are entered. For example, if I enter 50g carbs with 4 hour absorption time and then after 1-hour turn on an override to increase by 20% for 1 hour are the auto boluses given during that 1 hour to cover the carbs increased by 20%? If so, what then happens in hours 3 and 4 as it will see IOB higher than it would have seen without the increase. Hope that makes sense, thanks. |
|
Pete, can you explain what need's to be done/tested/fixed before this branch can be merged to dev? |
|
@PieterGit A few things:
|
|
Sinc I overlooked the Zulip message of @ps2, I'll repeat it for others that are mainly reading Github and not the Zulip channel: Automatic Bolus dosing strategy is now an option in Source: https://loop.zulipchat.com/#narrow/stream/144182-development/topic/Automatic.20Bolus.20on.20dev So I assume the @ps2: perhaps you can close these branches/PR's to be clear about the state of these branches/PR's?
I will do some testing and report with Github issues or in Zulip chat. |
|
The automatic-bolus branch this PR is tracking has de-facto become the main branch for anyone wanting to actually run automatic-bolus in Loop despite being what I would call an "experimental branch". It is still an experimental branch, but it's fairly stable, and is very in sync with the current Loop release, 2.2.4. The dev branch is still unstable so this branch will stay until there is an actual new release. The two other dev branches, |
|
Are there plans to sync this branch with 2.2.5 or 2.2.6? |
|
Thanks @jonfawcett. I'll check that out next time if my wife or kid are very adamant about having the latest version + autobolus (although my kid is <3, so I guess he won't have an opinion for a few years). |
|
@juan-restrepo @jonfawcett Not sure if this is the same thing, but Automatic Bolus was added to master in release 2.2.5 - https://github.com/LoopKit/Loop/releases/tag/v2.2.5 |
My mistake. I have been getting so many tags about my dose strategy switcher that I mistakenly thought this was another one. |
|
I believe this PR should be closed as overtaken by events. This dosing strategy was added to master with release Loop v2.2.5. |
|
I ended up having some issues and upon converging to master 2.2.6 I had the great surprise of having autobolus there. Thanks! |
An implementation of using boluses for dosing. Independent of #1205.
This feature is enabled by a new switch in settings that allows the user to select between the existing temp basal strategy and this new bolus strategy.
Boluses are issued for high corrections, when Loop thinks additional insulin is required beyond your basal needs. During each loop, up to 40% of the required insulin will be dosed via bolus. When insulin requirements are below basal, Loop will use temp basals, as before. High temps are no longer used, except to maintain scaled basal when a high override is in effect.
Automatic bolus sizes are limited to not exceed 40% of your max bolus setting.