Repository navigation
Integral retrospective correction #695
Description
Integral Retrospective Correction (IRC) (updated July 16, 2023):
- Integral-retrospective-correction (IRC) is an experimental modification of the Loop's Retrospective Correction.
- IRC has been included in Loop v 3.3 dev branch as an experimental algorithm option.
- IRC should be considered highly experimental and is not recommended for new Loop users or users who are having issues with Loop settings.
- The IRC algorithm was originally developed and implemented by @dm61 in 2018 and has since been used by the author.
- If you had a chance to try IRC, you may provide your feedback on Loop Zulip.
Some important points and an algorithm description are as follows:
-
Known risk factors compared to standard Loop: With IRC turned on, in response to persistent discrepancies between observed and predicted glucose motion, Loop will likely increase insulin corrections, which may increase the risks of hypoglycemia. IRC may also lead to increased oscillations ("roller-coaster") in glucose responses. Both of these risk factors are higher if the user's setting value for Insulin Sensitivity (ISF) is too low. Increasing ISF setting value tends to mitigate these risks but it is impossible to offer any guarantees for anything around T1D.
-
Compared to standard RC, IRC is more likely to improve glucose control in the following scenarios:
- Glucose remaining high or decreasing slower than expected due to temporarily reduced insulin sensitivity or due to poor site absorption
- Glucose trending low faster than expected due to temporarily higher insulin sensitivity
- Glucose spikes due to unannounced meals
- Glucose remaining high (or trending low) on tail ends of meals where carbs entered were underestimated (or overestimated)
- Glucose remaining elevated due to unannounced protein+fat effects
- Glucose staying above (or below) the correction range due to too low (or too high) basal rate settings
- In some scenarios IRC does not differ from standard Loop RC
- Regardless of the current glucose level, neither RC nor IRC is adding to the glucose forecast during the times when the absorption rate of announced carbs is greater than the minimum absorption rate.
- Neither RC nor IRC effects depend on glucose level; both depend on discrepancies between predicted and actual glucose responses.
- Please do not expect immediate or very substantial improvements in blood glucose control. A one-time success after turning IRC on does not really mean that IRC "works" - this could just as well be a temporal coincidence. Some ways to decide if IRC could be safe and effective for you include:
- Responses to unannounced meals - spikes should in general be somewhat lower than with standard Loop, but there should also be no follow-up lows
- Nighttime responses over a few weeks - highs or lows should be less frequent compared to standard Loop; at the wake-up time blood glucose should in general be closer to the correction range.
******************** IRC Algorithm Description ********************************************
Integral retrospective correction (integral RC) is an experimental modification of the Loop's retrospective correction (RC) algorithm. Just like the standard RC, the motivation behind IRC is to make Loop less dependent on how well carb entries, ISF, CR, or programmed basal rates represent reality, and to improve responses in the presence of any unmodeled factors.
Operation of the standard Loop retrospective correction is illustrated below, where time = 0 represents the present time.
A modeling error called discrepancy is calculated as the difference between the actual BG and the BG predicted based on insulin and carbs models over the past 30 minutes. In the example shown, discrepancy = 15 mg/dL. The discrepancy is then used to modify the BG forecast over a correction interval of 60 min. The net effect of standard RC is that the eventual predicted BG is adjusted up (or down) by a retrospective correction equal to the current discrepancy (subject to momentum effects, but that’s a different topic).
In the integral RC, the correction magnitude and the correction time interval depend not only on the current discrepancy but also on past discrepancy values, so that the correction becomes more aggressive if the discrepancy persists over consecutive Loop cycles. This results in more aggressive dosing in response to any persistent modeling errors due to over/under-estimated carbs, parameters (ISF, CR, or basal rates) being away from reality, exercise, … whatever.
Simulation examples
In the first example, the actual basal needs increase by 40% (to 0.7 U/h) over a period of about 10 hours. Standard Loop high temps, which keeps BG from ramping up, but BG hovers away from the target. Integral RC kicks in more aggressive high temp corrections, which brings BG closer to the target.
In the second simulation example, the actual basal needs fall by 40% (to 0.3 U/h) over a period of around 10 hours. Standard Loop responds by low temping, but BG still drops below suspend threshold, which triggers some on/off oscillations around the suspend threshold. Integral RC results in a smaller BG drop and keeps BG closer to the target throughout.
The third example is a case of unannounced 25 g carbs with an absorption time of about 3 hours. Compared to the standard Loop, integral RC reduces the magnitude and the duration of the spike.
Integral RC math
Integral RC math is relatively simple. Overall retrospective correction is computed as a sum of two components, proportional and integral:
overallDiscrepancy = proportionalGain * discrepancy + integralDiscrepancy
where integralDiscrepancy is computed as:
integralDiscrepancy = integralForget * integralDiscrepancy + integralGain * discrepancy
proportionalGain, integralForget and integralGain are constant parameters of the integral RC filter. In the standard RC, proportionalGain = 1, and integralGain = 0. In simple control theory terms, standard RC can be viewed as a proportional (P) controller trying to reduce modeling error (discrepancy). Integral RC adds an integral (I) action to this control loop. In addition to the above basic math, safety provisions (integration resets and limits) are included to minimize the chances of over-correction. A differential term has been added to mitigate the sluggishness of the response when discrepancies change polarity.
The IRC code can be viewed here
Activity
Kdisimone commentedon Mar 31, 2018
I like this concept. Thank you for sharing. I believe I’ll test this one out. 👍🏻 And report back
Up and running as of about 30 min before...
elnjensen commentedon Apr 1, 2018
This looks great, @dm61. I’ll try this and let you know how it goes.
dm61 commentedon Apr 1, 2018
@Kdisimone one important point I did not mention in the original post is that integral RC will default to standard RC if retrospective carb effect is positive and greater than a threshold (which is in the code set to 30 mg/dL over past 30 minutes). This is a safety issue. Without this provision, there is a scenario when integral RC could lead to over-correction (and subsequent low), specifically when a carbs in an entry are overestimated yet carbs are initially having faster than expected absorption. In the Console screen you've posted you may see that overall correction equals discrepancy. This is because discrepancy is positive and retrospective carb action is above 30, so at the moment you are having just standard RC. Once carb action subsides, or once discrepancy becomes negative, a difference between overall correction and current discrepancy will show up.
Kdisimone commentedon Apr 1, 2018
(writing in my own account now instead of the person I was troubleshooting for lol)
@dm61 funny you should mention that because I think that situation is exactly what we just had...and I'm glad the safety is there. She overestimated a fruit drink and entered it at 3 hours because it was part of a larger meal...so a bit of a faster absorption. She's going a wee bit low, but easy enough to stop and doesn't have a lot behind it. I was reading the code, so I appreciate the situational awareness explanation to why the safety setting is there. I'm reading up on the duration determination (x+10 vs 180) and assimilating that part too.
Kdisimone commentedon Apr 1, 2018
@dm61 that saftey setting (30 over past 30) is there whether or not there are COB? Looks like it to me, but just checking.
dm61 commentedon Apr 1, 2018
@Kdisimone that limit is entirely based on modeled carb action over past 30 minutes. If there is no COB, there is no modeled carb action, and that limit goes away. Integral action will always be active for unannounced carbs or such.
The duration extension logic follows standard RC approach where velocity of discrepancy over past 30 minutes decays linearly over next 60 minutes. Whenever integral action is updated, that means we are effectively looking another 5 min in the past, so velocity is set to linearly decay by 10 min longer time. In other words, we are predicting that the correction will extend further in time. The 180min is somewhat arbitrary, but is related to the filter time constant, which is set to 90min, so 2*90 = 180m is how far correction may ever extend in the future.
Kdisimone commentedon Apr 1, 2018
thanks you. I think that helps me. So if I have that roughly right, the longer the discrepancy has persisted (and continues, assuming no inflection point), the longer the corresponding future correction?
dm61 commentedon Apr 1, 2018
Correct. Note, however, that as far as dosing is concerned amplitude of the correction is more important than duration, since eventual predicted bg is simply moved up or down by the correction amplitude (as is also the case in standard RC). The duration affects the shape of the prediction curve, which may affect dosing in some cases, such as when forecast crosses through correction range limits or suspend threshold.
francesc0-cgm commentedon Apr 1, 2018
Up and running here too. Thanks @dm61
francesc0-cgm commentedon Apr 1, 2018
@dm61 a bad sensor or old One used with Spike so with some jumps could affect safety using this RC release?
dm61 commentedon Apr 1, 2018
@francesc0-cgm in case of noisy BG readings, integral RC should operate no worse than standard RC, but probably no better either. But, if you see anything that looks suspicious in bg forecast, please report.
amazaheri commentedon Apr 1, 2018
Nicely done! I just started using it today and observing will report back.
francesc0-cgm commentedon Apr 1, 2018
@dm61 integral RC makes change in bolus reccomandation or acts only on basals?
jeremybarnum commentedon Apr 1, 2018
This is exciting @dm61 - thanks for doing it. You said this is the only modification you have put into this branch - does that mean you reversed out #577?
@francesc0-cgm I believe it acts on the prediction and therefore all recommendations will be affected by it (bolus and basal).
francesc0-cgm commentedon Apr 2, 2018
Last question @dm61. We have to enable or disable retrospective correction? Will It work the same with It enabled or could have some strange interaction?
59 remaining items
diggabyte commentedon Aug 1, 2018
@dm61 just some initial feedback: I'm only 24hrs into running IRC and I've noticed that there is a significant increase in sinusoidal oscillation to my bg levels in comparison to either RC or no-RC. I'm wondering if perhaps IRC could be amplifying inaccuracies in my ISF and/or IC ratios?
Although I'm 6-wks into looping, I felt as though I am pretty accurate with my ratios and basals by now, but perhaps I need to take a closer look with some autotuning / fine-tuning to see if the outcome improves.
I'll collect more data in NS over the next few days and report back.
dm61 commentedon Aug 1, 2018
@diggabyte what you are observing is not unexpected with ISF value on a low end. IRC does tend to amplify the effect of lower ISF. If you increase your ISF value some more, those oscillations should subside and either go away completely or become smaller in amplitude. Another mechanism that may result in some oscillations typically around the correction range is when basal is a on a high side, and bg forecast then tends to cross through suspend threshold. In such cases, IRC also tends to amplify the resulting oscillations compared to RC or no RC cases. I might be able to provide some more feedback if you post your NS and/or Loop screenshots (bg cart and carb absorption chart).
diggabyte commentedon Aug 2, 2018
@dm61 thanks, that largely confirms my suspicions. I bumped ISF earlier today with that in mind and it has indeed reduced the amplitude of the oscillations. I’ll analyze basals and suspend more closely and see if I can flatten this out even more. Thanks for the feedback and of course for creating this!
francesc0-cgm commentedon Aug 5, 2018
Today i had this strange prediction using last dev woth irc. My son was going high with negative iob and a bit of carbs on.
ps2 commentedon Aug 5, 2018
@francesc0-cgm Please use a separate ticket, unless you have some reason to think it is IRC related. Also, an issue report and Loop screenshots will be more useful than a NS shot; the IOB and COB pills are not particularly reliable in NS with Loop, and so we recommend people turn those off. This screenshot doesn't give us enough to go on, unfortunately. Hovering over the Loop pill might give more info.
francesc0-cgm commentedon Aug 5, 2018
So don’t mind about it...
deddynh commentedon Aug 8, 2018
IRC=Fantastic. I have been a long OpenAPS user and like UAM and SMB as my carb counts are close but never exact. I have not had as much success keeping the rise lower than 160 mg/dl post prandial until IRC using Loop. So fantastic. THANK YOU @dm61 for putting this out. Would love to see this in dev if people are having the same experience using it. I can't wait for this to all come to Open Omni!
dm61 commentedon Aug 9, 2018
@davidkeddydb great, thanks for the feedback! I should say IRC is just a small piece on top of Loop foundations, glad to hear it's altogether working well for you.
christerjensen commentedon Aug 15, 2018
IRC is working great most of the time, but I find it is to conservative when the BG is low and falling slightly. This example is from lunch (girl 8 yrs), only 0.09 IOB, the prediction in EvBG is 0,9. Carbratio is 1:12, so 40 g should give roughly 3.0 units (slightly less with BGTarget around 6.0 mmol/L). The suggested insulin is only 1.5 U. Loop has been working fine with these ratios for nearly 2 years. Do people experience the same? Any suggestions. I could change carbEffectLimit, but then it would also be less aggressive when BG is high. I think the Loop version is 1.5.5dev (from 30.06.2018)
dm61 commentedon Aug 16, 2018
@christerjensen Thanks for posting this question, which points to a broader issue of how Loop doses insulin when bg is below Correction Range and close to or below Suspend Threshold. What happens in your example is as follows: Loop has been zero temping for some time to counteract BG trending down faster than expected. The zero temping was reinforced by IRC integral action, which resulted in even lower predicted BG (this is in most cases desirable, as it better helps prevent lows. However, because of this amplified prediction in the negative direction, bolus recommendation can then be more significantly curtailed when BG is close to Suspend Threshold (you may take a look at #533 to see why that is the case). Once BG starts ramping up, BG prediction quickly swings in the positive direction, which is fine. However, a part of the current Loop temp-basal algorithm is to not high temp if any predicted BG is below Correction Range. That's another reason you see a longer delay in high temping, and a higher spike. To summarize, what you are observing is a combination of (1) bolus recommendation curtailing, amplified by IRC's prediction in the negative direction, and (2) a lag in Loop high temping due to no-high-temping below Correction Range provision. We could try to address one or both of these in various ways, and I'll be looking into that. In the meanwhile, you may consider manually overriding bolus recommendation in situations such as the one you posted.
apabari commentedon Sep 5, 2018
@dm61 - This functionality seems to be working well. Thank you!
What will it take for this to be "ready" to be merged into the dev branch officially, or perhaps into the next production version of Loop?
dm61 commentedon Sep 5, 2018
@apabari thanks for the comment, glad to hear IRC is working well for you. We want to make some changes in how the IRC code is implemented, to make it fully consistent with the rest of Loop. This will also open some other interesting opportunities for further improvements. In the meanwhile, the existing version of IRC is fine for testing purposes.
Trpl7ca commentedon Jul 17, 2023
By increasing ISF you mean a smaller number, correct? I have had the roller coaster going
dm61 commentedon Jul 17, 2023
By increasing ISF setting value I mean having a larger number entered.