oref0
oref0 copied to clipboard
openaps
Discussion - Enable toggle for SMBs based on a high BG threshold
Is your feature request related to a problem? Please describe.
With the current SMB toggles, there's not a good way to enable SMBs if you're going high due to stress, delayed carb absorption (with the exception being enableSMB_after_carbs), or various other reasons BGs may rise independent of COB. enableSMB_always is not an ideal solution due to variable sensitivity that some users may have (myself included). This is especially true for nighttime, when having SMBs can cause a lot of rollercoastering while sleeping.
Describe the solution you'd like
I've been running my solution on AndroidAPS for about 4 months now, and I really like it and think it would fit well for some people's use case. Create an enableSMB_high_bg flag that allows the user to either a) Set a profile BG where if the BG goes above this value, SMBs are enabled or b) Enables SMB if the BG is above the upper bound of the user's BG Range (for example: 100-115, SMB would be enabled if BG >= 115). I've implemented B, and that's how I'm running it personally.
Describe alternatives you've considered In AndroidAPS, there are some Automation tweaks one can do to accomplish this functionality, but it's not super intuitive. I'm not sure of alternatives for openAPS.
Additional context None
I can port my solution from AAPS to openAPS, but unfortunately I would need some help with the profile/BG profile work to work with both potential solutions (or some other solution that may arise during discussion)
Here is the commit with the code changes I made: https://github.com/stevebell117/AndroidAPS/commit/f18b7a6243c0ee08e67d95c076d6c54fc9788ad9#diff-6fc63681220522359b2221242277b85fR113
If you’d like, this is something that could be tested in the oref0-simulator with oref0-backtest. You’d just need to add a preference controlling the behavior (for example an enableSMB_above_BG threshold), update the enableSMB processing function to parse that preference, and then run oref0-backtest against your (and others’) NS data to show whether the simulated outcomes would result in fewer hypos with this option than with other enableSMB options.
LMK on Slack/Gitter (or here) if you need any help implementing that or running oref0-backtest.
Do you have a preference on how this is implemented from a user standpoint? Having a specific value in the profile, or using the BG range's high value? Being able to use the BG range's high value adds further customization based on the time of day as well, so I'm definitely a bigger fan of that. I also realize I don't have as big of a picture on the subject matter, so I'd love your insight/feedback!
It’d be slightly easier to test with an integer value in preferences. If it proves useful in simulations, you could (also/instead) make it a Boolean that uses the pump high BG value, and further test what schedule works best.
Given that most people use a single target number rather than a range when looping, it might make more sense to use the single integer value behaviour, as otherwise, it becomes a binary "on above target/off below target". That's not to say that people wouldn't find that useful, especially with some of the low targets that people run, but it does change the dynamics slightly.
@stevebell117 could you also describe in some detail how you view the insulin sensitivity behaves in these situations? Enabling SMB will speed up the dosing of insulin in some situations but won't affect how the ISF is calculated and your description implies you're observing the system over and/or under dosing insulin or timing the dosing in a non-optimal manner in some situations and would like to remedy this with the new configuration option, where a clear description of the current and desired dosing/treatment outcomes would be useful in evaluating the implementation
@tim2000s : This is good info, but I also believe that people only keep the low/high target the same because there's currently no point in keeping them separate to begin with. If there is functionality added to the upper bound, and someone wants to enable this feature, they may start using the upper bound as well. I'm also well aware that this could also pigeonhole this feature for any future features that may require the upper bound, but as of now those don't exist.
@sulkaharo : So as of now, my ISF changes from 1:85 around 80-120 to something like 1:75 from 120-180, and 1:60 from 180-240, and even more resistant the higher the BG. Where this change would benefit is the ISF change from 80-120/120-180. If I only enable SMB at a range above/near 120, then the SMBs wouldn't be as sensitive and once the BG falls to my sensitivity range for 80-120, it'll go back to handling everything via basal tweaks (this is good for sensor errors/noise). Whether this resistance based on BG is valid is a discussion that should probably be kept out of this Issue, but I have noticed validity based on my use case and this solution is beneficial with it. I have some graphs that show the rollercoasting with enableSMB_always and without it, but I'd have to dig through my nightscout from 4+ months ago to find it if you're curious.
general : I have made the change in an oref0 branch on my fork, and am going to be playing around with the simulator/back-test over the next few days.
@stevebell117 I'd be interested in seeing your graphs showing the rollercoaster, and also the output once you've run the simulator.
I'm a little intrigued as to what you were seeing and also how AAPS was handling this. For example, is Autosens enabled for you as part of your setup and if so, which version?
@stevebell117 To verify a bit more - do you thing 1) the ISF changes as a function of the BG level, or 2) the BG level becomes elevated due to ISF having changed? The crucial difference here is, if the BG ends up high due to something having happened, which requires additional correction (which can be modelled as a change in ISF causing the loop to correct more), that's potentially preventable / detectable prior to the BG elevation, vs if the BG level actually causes a hormonal feedback loop that changes the ISF, the loop can only react to that. Related, do these hyper fluctuations happen at any point during the day or does the probability of the excursion alter for each time of the day (where morning and evening resistance are a common phenomena and could potentially use pre-emptive solutions / react faster than before the BG is already significantly elevated)?
In addition to @sulkaharo 's comment, combinations of macronutrients affect "insulin resistance" in ways that we've not properly modelled yet, causing a similar effect to that he describes, pushing up resistance and thus resulting in higher than expected glucose levels as insulin seems less effective.
@sulkaharo I'm more inclined to think it's 1. One thing I know that is easy to test this is to eat the same amount of a high glycemic food, and in one instance pre-bolus to prevent a spike and in the other instance give insulin right at meal time (or adjust it, depending on your uptake). For me, if the sugars spike I ultimately require more insulin to come back down versus the original bolus for the food. This makes me tend to lean more towards higher BG causes higher resistance. (thus requiring a different ISF) This resistance change is relatively universal for me, time of day doesn't have much influence.
@tim2000s I'm curious about your macronutrients comment. Do you mean having a high carb/high fat/high protein item influences resistance in some way? I know inflammation can, which some meats cause, but I'm curious. As for the graphs, it may take me a bit of time to get those to you due to lack of free time and the fact the graphs are over 4+ months old at this point (since I've been running the solution suggested in the OP since early October).
@stevebell117 and @tim2000s macro nutrients - yes high fat, lipolyse and higher insulin resistance. Going keto will increase my insulin resistance in such a way that TDR is higher than normal carb centric diet with same calorie intake.
And I only have a small decreasing effect through endurance activity in keto as compared to the huge resistince decrease doing sports on carb diet.