Negative IOB : shouldn't be used in insulin calculations

[robertrub]

There is a security risk with negative IOB. AAPS always tries to inject the "missing" insulin which results in lows.

There is no "negative" IOB in our bodies. The pancreas releases or not insulin depending on BGs and their variations. It should be the same in AAPS.

Negative IOB is an important information for the user (ie profile too strong) and should be indicated (message and text on the graphic) but should NOT enter in the formulas used to calculate the insulin amount to be injected.

2 examples. This morning, my BGs were lower than usual (insulin working better than other mornings). AAPS does a great job and stops basal to prevent hypos. This generates negative IOB. I'm below target, no carbs. If I use the calculator, the negative IOB will be injected and I'll find myself in hypo. The calculator should not inject the negative IOB. Even without the calculator, AAPS should not try to fill in the "missing" insulin.

Exercice example. I eat carbs (that I don't tell AAPS) before exercise. I walk for 1 hour. I either didn't eat enough or the road was too steep and I ended in a negative IOB. The exercise results in insulin being more efficient. If AAPS tries to reinject the "missing" insulin, I'll end up in a hypo.

I can't find even one reason to use negative IOB in the calculations.

AAPS should alert the user that it is generating negative IOB but should never use IOB <0.

IF IOB <0 THEN IOB=0 and FLAG neg-IOB-alert

[BRamine]

Another experience for me with -IOB :

Started TT for exercise, but ended up working more then intended. Situation is 0 COB, bg flat 100 with -0.45 IOB. TT ended and AAPS immediately started to compensate for the negative IOB and sent me straight to Hypo. I could have avoided that but TT again etc, but also the compensation for -IOB is completely not logic since like @robertrub said, -IOB = 0 IOB, if ∆ is not high, which in my case average ∆ was -1, can't find a reason to have insulin.

[Philoul]

Negative IOB is required in oref algorithm. If you want to disable it in wizard dialog, first disable COB (GA) in your screenshot...

[robertrub]

I don't know how negative IOB is used/useful in in OREF but the result is not good. We are obliged to cheat with high TT to prevent hypos which adds more neg IOB...

I don't know what would change deactivating COB as it was 0 on my screen capture and unchecking it doesn't uncheck IOB. Once more, this is a cheat to counteract an incorrect reaction of AAPS.

[chrisbev]

When autosens lowers to say 80% does anyone know what iob is calculated with respect to? Is it 100% basal or 80% basal? I've asked previously but got no replies as if 100% then changing to 80% could help, or could autosens say bleed iob another way (like cob decay) after a while? For me I swing around plus or minus iob so 'think' settings are not too far off and autosens copes quite well with my variability but I quite often manually disconnect pump to 'help' -ve or 'prime' for +ve to hide from AAPS calculation. Just off the wall thoughts if rubbish as I don't know OREF workings please ignore.

[BRamine]

I don't know how negative IOB is used/useful in in OREF but the result is not good. We are obliged to cheat with high TT to prevent hypos which adds more neg IOB...

I don't know what would change deactivating COB as it was 0 on my screen capture and unchecking it doesn't uncheck IOB. Once more, this is a cheat to counteract an incorrect reaction of AAPS.

By cheating we get even more -iob

[Philoul]

My answer was not to cheat, but to include or not negative IOB in wizard calculation. (after wizard you have a bolus so no more negative iob, it's just a way to limit risks of over dosing the bolus).

Negative IOB is not bad when all your settings are good. If you look in detail all your IOB curves during a perfect night with a flat BG curve glued to your target. you will see that your IOB vary between positive and negative values. Without negative value, the correction would be under estimated and the result worse than your perfect curve (you will get waves).

You always have insulin in your body, even with negative iob (just take a look on absolute iob that is always >0). Negative IOB signify lack of insulin compare to your basal profile.

The negative IOB is always the consequence of something else that is not correct (basal rate too high in your profile, sport, ...) and most of the time an hypo TT is the good way to correct the situation without cheating aaps.

[vanelsberg]

Another theoretical example (which I happen to experience regularly):

AAPS tries to keep my BG at target using the perfect profile. Then my IC is a bit off (due to todays sensitivity) and maybe I was unable to calculate carbs absorbed exactly:

AAPS/0Ref will attempt to compensate for this and keeping me at target (as designed) by some 0-temping, It does so perfectly, no problems until .... negative -IOB gets me in a hypo.

To clarify (its what i see happing when it occurs): Negative -IOB results into an instable system that starts cycling between lows and -IOB about every 2-3 hours:

|---> Going below target -> 0-temp -> going to target with -IOB -> addtional insulin for -IOB -->--|
^------------------<-------------------------------------------------------------------------<-----|

I can only break this cycle by taking carbs to get 2 points above target (target=5.0)

• TT does not work here: it only worsens by generating more -IOB
• Temporary lowering basal rate would help, but that would mean switching profile, resetting autosense as well as ending up with a BG higher then intended.

[vanelsberg]

You always have insulin in your body, even with negative iob (just take a look on absolute iob that is always >0). Negative IOB signify lack of insulin compare to your basal profile.

That is just the point with -IOB. It is just a trick to calculate "virual" insulin that was expected but not administered. It most certainly can be taken in account for oRef calculation. But it should not be compensated for by actually injecting this "virtual" insulin just to get to absolute insulin at "0"

[vanelsberg]

There should not be any need for "tricks", T-Temps or "Basal rate lowering" to prevent something like oRef negative -IOB from causing problems.

Even after 2 years on the subject -IOB I have not seen any (acceptable) explanation on the purpose of compensating for -IOB with real insulin

[swissalpine]

I think you have to separate two things: Showing an insulin level below the actual basal level. This is where negative IOB makes sense and is very helpful information. Negative insulin (understood as a deviation from what the basal rate would have given) must exist and must be possible and must be enabled by the algorithm. This is a binse.

The "enforced" filling of the negative IOB as soon as an opportunity comes up (positive trend, calculator ...) has no logic in my eyes. Because the available insulin quantity (even if it is IOB negative), is exactly correct at this time and was also exactly so initially controlled by the algorithm! So why correct this "correct" amount of insulin on occasion incorrectly? ;-) This is exactly why I have to set up automations, set Hypo-TT etc., in order to moderate this, in my eyes, usually not reasonable amount of insulin.

And more fundamentally: I hope that AAPS will soon say goodbye to OREF and become independent. There is so much developer potential here that we could finally deal with the algorithm itself. Because it is (see the numerous automations, not only in the negative IOB area) anything but always suitable and ideal - even if it is still one of the best on the market.

[vanelsberg]

Seems this issue was already reported 6 years ago? Issue Closed as: use autosense (?)

https://github.com/openaps/oref0/issues/101 Improvements on recovering from a low

Actually this issue is exactly describing the problem I have with negative IOB. Scot Leibrand confirms the issue: "I think the solution to this is to use autosens. Please reopen or open a new issue if you still see this after autosens is in place."

[vanelsberg]

Trying to repro this problem:

Note that in this case the issue will only occur when not taking carbs for a longer period (e.g when sleeping)

1. Before going to sleep take some carbs or insulin and overestimate (by for instance 20%) . You will end op below target forcing AAPS to start 0-temping for some time trying to keep you on target - while doing so building up negative IOB.
2. Go a-sleep and prepare to be woken by a low or hypo alarm in 2-3 hours.
3. When woken, take the exact amount of carbs as suggested by AAPS calculator (or do a manual calculation based on your IC/ISF).
4. Go a-sleep and be prepared to be woken again in 2-3 hours
5. Go to step#3

Only way to break the cycle is tricking 0Ref by taking extra carbs at step#3 to get you above target without registering the extra carbs (and accept above target for the next 2-3 hours). Or just have a sleepless night and wait for breakfast to clear the problem :innocent:

Note on step#1: This can happen, for instance by wrong calculations, unexpected sensitivity or sensor value temporarily going higher for some reason 😐

Note on step#3: You will see AAPS administering insulin for the carbs registered but do additional insulin to compensate negative IOB. As a result you will be taken right back into the low/hypo.

Note: Problem will probably not repro when you have set nightly basal rates (to) low and let SMB fill in. (YMMV: Worse case, as max SMB is limited by max current/daily basal rates, SBM may not be able to get you to target)

[vanelsberg]

Just a small change for 5.5mmol to the target was perfect

I think this is actually a work-around to prevent going too low or even into hypo. It partly "solves" the problem (but also get you a higher HbA1c). I also expect you are seeing "waves" in your BG curves with regular 0-temping where BG cycles around the higher target value? Did you try lowering basal rates at night?

[DigitalDan1]

I think negative IOB is useful in some cases and not in others:

1. Useful when pump is stopped for 30 minutes to take a shower, it's usually good to top up any negative IOB after that.
2. Not useful when it's one of those days/nights where the usual basal (that might have been perfect the day/night before) is just too high. Topping up negative IOB after this will lead to another low, another temp zero, more negative IOB, and repeat...

Automatically detecting the difference between these is the tricky part. Autosens can help but I find IOB can still become very negative.

When autosens lowers to say 80% does anyone know what iob is calculated with respect to? Is it 100% basal or 80% basal?

Autosens is used in the IOB calculations, but I think it's only applied at times where there's a Temporary Basal Rate (TBR) running. At times when there's no TBR (i.e. normal profile basal running) there's no TBR to contribute to the IOB calculation, so effectively the full rate is used as the baseline for IOB. I've previously wondered if this is an oversight in the algorithm (or maybe I've missed something).

e.g. assume a profile basal of 1.0U/h and autosens is 100%

• 1 hour TBR at 0% contributes -1.0U to IOB
• then 1 hour normal profile basal contributes 0.0U to IOB
• IOB over 2 hours = -1.0U

If autosens was 80%, then profile is adjusted to 0.8U/h, so I think the IOB calculation will be:

• 1 hour TBR at 0% contributes -0.8U to IOB
• then 1 hour at normal profile basal (1.0U/h) contributes 0.0U to IOB (but should be +0.2U I think)
• IOB over 2 hours = -0.8U (but should be -0.6U I think)

If this is true, I wonder if it could explain (maybe only partly) some of the problems people are seeing with negative IOB?

[MilosKozak]

i understand your points but you can easy find and example where negative IOB must taken into a count to avoid high BGs after bolus, Simply ignore negative IOB is not a solution for every situation

[vanelsberg]

.. Example where negative IOB must taken into a count to avoid high BGs after bolus, Simply ignore negative IOB is not a solution for every situation..

@MilosKozak Correct. Agree. Do not think just ignoring negative IOB in general is a good idea. Much interested in your opinion on my reasoning below.

The root of the problem is not compensating -IOB, it's before to not enter in the bad loop.

@Philoul Agree, better to prevent! In real life however preventing may not always be possible. And I firmly believe oref should be able to properly handle a "bad loop" situation when it occurs even when caused by user-error. I do think this is a real problem that eventually will hits almost every AAPS user. Some of them actually confirming the issue, some trying to work around, other just accepting.

(Note: What I found most concerning is the fact that the problem was already reported as an issue op OpenAPS in 2016, closed by Scott Leibrand suggesting to prevent the problem using autotune. For me that is just another way of arguing solutions is to prevent it from happening)

Please note that I do not argue against the concept of -IOB for the algo to do proper calculations in general. However I do think there are cases where it should delay acting on -IOB build-up.

Trying to explain my reasoning on this: Let me start by saying that as long as BG is on or above target oref is performing just fine. Now lets assume BG is below target (what caused this is - other then prevent - not relevant in this context):

IF BG < target AND IOB > 0: Body received to much insulin that caused BG to go below target (lets call that IOB = "required-basal" + "to-much" insulin). Because of this oRef's 0-temp stops adding even more "basal" insulin (while counting this as -IOB).

So all "required-basal" insulin is already on-body as well as "to-much" insulin. At this point body only needs additional carbs to compensate according to the "to-much" insulin part.

For me it makes absolutely no sense to additionally compensate the already existing "required-basal insulin", just because IOB is counting negative. Lets say my brain simply can not accept the logic in this ;-)

IF BG < target AND IOB < 0: (so on-body insulin is less then "required-basal") I think 0ref is also not handling this well.

oRef logic dictates the "required-basal insulin" should be met. So on carbs intake it is calculating additional insulin for compensating -IOB. It does not take in account however that because of being low the body is in an emergency state, burning fats. Even Pancreas might start producing more insulin at its max capability.

So I would argue it is undefined how much basal insulin is actually "needed" or "missing" at this point. On taking carbs, compensating to much on the theoretically "required-basal insulin" risks initiating another low.

Suggested solution: Ignore the -IOB count in oRef calculations when BG is below target and compensate for carbs intake only. As soon as BG rises above target, normal oref calculations can proceed and start compensating for -IOB. This should stop or at least be damping the "bad loop" when user is trying to get back on target.

Alternate solution? Is there? Maybe find some (preferably automated) action to prevent or handle BG-low loops as a result of oref -IOB logic?

[robertrub]

@MilosKozak you can easy find and example where negative IOB must taken into a count to avoid high BGs after bolus

I'm searching but I can't find a situation where +/- half a unit "missing" will have an effect. And limited highs are less dangerous than hypos.

If the user is in neg IOB, it means that AAPS decided (correctly) that that amount of insulin was not needed at the moment. Nothing says that that amount will be needed in the near future. Even in the "shower, pump disconnected" scenario of @DigitalDan1 above, if at the end of the shower he is with neg IOB and a BG rise, AAPS will react to the rise with SMBs or basal raise and will take care of the raise.

I like looking at problems from "the other side". So, what happens if you have a positive IOB with COB=0 for some time ? AAPS will not turn off insulin to arrive at IOB zero (and let the BG rise). It is not logical to reach IOB =O in this situation. So, in the neg IOB situation, why does AAPS is obliged to arrive to IOB zero (even if it means lowering BG below target even more) ?

With COB=0, neg IOB becomes a dangerous situation if AAPS tries to arrive to IOB=O same as a positive IOB becomes a bad situation if AAPS tries to arrive to IOB=0... The only logical solution is to NOT try to arrive to IOB=0.

Alert the user that something is off but "ignore" a neg IOB, at a minimum when COB=0.

[chrisbev]

Another 2 penneth, if autosens is not at 100% with negative IOB is there any merit in the loop leaking some IOB like it sets a TT away from 100%?

[Pamalosebi]

Not sure if it should be changed in AndroidAPS. AndroidAPS is implementing the algorithms of OpenAPS (as far as I understood). So it should be changed there first. But they have a very clear answer in their documentation: https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/optimize-your-settings.html?highlight=Iob#frequent-negative-iob-at-the-same-time-every-day

You have a point in saying "it could be a problem". But also it could cause problems not to implement it as it is right now, since then something might be wrong with your profile (at least as OpenAPS intended it).

Let's say you eat something with very high glycemic index. Your BG goes up fast and you want to calculate your insulin, then it probably would miss a lot to reach the target again.

[robertrub]

@Pamalosebi We are NOT talking about regular neg IOBs. Yes, that situation is a bad profile setting and the user should be alerted.

What we are talking about is the occasional neg IOB which results of a bad meal carb calculation or activity not compensated enough by carbs. The balance "carbs vs insulin" is not right. The insulin "too much" will replace the basal insulin. This will generate neg IOB even if the body had its need of basal.

In your high glycemic index situation : If you eat high glycemic index meal, your BGs will rocket up, having AAPS fill you with more insulin than needed and then the BGs will drop real fast (by high glycemic meal definition) and you'll generate plenty of neg IOB in order to not go into a hypo.... And that neg IOB will force you so go to a hypo or stay "too close for comfort" near the hypo line.

I agree that this is a problem that OREF people should solve but AAPS can't ignore a security risque saying that it is not my domain.

[Philoul]

Suggested solution: Ignore the -IOB count in oRef calculations when BG is below target and compensate for carbs intake only. As soon as BG rises above target, normal oref calculations can proceed and start compensating for -IOB. This should stop or at least be damping the "bad loop" when user is trying to get back on target.

With this proposal all the perfect nights are likely to be worse... See in my example below why I'm convinced negative IOB are necessary to keep you close to target all the time:

• this morning I had a negative IOB during about 3 hours between 5AM and 8AM
• during all this period I was below target
• the "minimum" value of negative IOB was a bit after 6AM with about -0.6 or -0.7U (I couldn't read value and take a screenshot because I was sleeping, but I'm sure the forecast BG was above target because I had not enough insulin in my body)
• As you can see my BG started to rise (at 6AM), and between 6 and 8 my IOB increased again up to 0.
• With you proposal, all values (TBR and SMB would have been lower between 6 and 8), so a later correction of the forecast increase of my BG...
• This is just one example amoung hundred of similar ones (all the perfect nights are perfect thanks to the negative IOB, becasue your IOB never always remains positive close to target without carbs)

[robertrub]

I'm really not convinced that "perfect nights" will be ruined. In your screen capture, you have the exact situation where neg IOB brings you to a hypo limit.

In 1, at around 4:15, you start your neg IOB trip. In 2, the neg IOB is activating the SMB and basal raise to catch-up the "missing" (sic) insulin (even though you're below target and not far from the hypo limit) and in 3, you hit the hypo line. I'm sure that your profile is as good as mine.

Even if your "no neg IOB compensation will bring higher BGs" turn out to be extact, it is less risky to get near the high limit then the hypo limit.

We are several to want to test the "Ignore the -IOB count in oRef calculations when BG is below target". Nothing is better than a field test.

[vanelsberg]

• This is just one example amoung hundred of similar ones (all the perfect nights are perfect thanks to the negative IOB, becasue your IOB never always remains positive close to target without carbs)

Must say I am a bit surprised. Your target is set to 90. And because of -IOB you drop below target (upto as low as 70) for almost 4 hours. I would not call that a good night?

For me most nights (3 out of 4) are good, at target (90-94) with a nice straight BG curve... Unless there is -IOB buildup: As in your graph, my BG may drop well under 80, get a hypo alarm, need to take carbs (just enough for compensating -IOB an raising BG) without telling oRef to get and stay on target. If do register carbs I'll stay in a the target<->low cycle or worse all night with hypo alarms every 2-3 hours :-|

Btw: for me under 80 (4.4 mmol) shows "red" in the graph.

[sprig3]

Interesting discussion.

I guess I've never thought the loop could do better than getting you half-way there without a profile change.

Given the # of people interested, it does seem like it would be a good feature to allow (optionally) if the total IOB is -ve and below target to lie to Oref and tell it 0 instead. Not sure how hard the coding would be, though, just to try it out.

[robertrub]

I'm coming back to this subject ;) Please tell me if my logic is wrong.

Lets forget the raison why we're in neg IOB.

If we have a neg IOB, then :

1/ We are below target 2/ We got "too much" insulin for our needs of the moment 3/ AAPS stopped basals (and started the neg IOB count) to slow/stop the drop. 4/ After some time, we're still below target and with neg IOB.

We started with too much insulin and as a result of the algorithm calculations (neg IOB), AAPS thinks that we are missing insulin... which is the opposite of our situation.

I can't understand how we can ever say that we are "missing" insulin if we are below target. We had more than what our body needs in insulin, not less.

If some OREF people is reading this, I'm totally open to read their explanations and logic of "missing" insulin.

[Philoul]

Everything is relative to your basal rate in your profile. If you get the basals of your profile during DIA (IOB =0), your BG should be constant (without anything else, ie COB, activity...).

So if despite your neg IOB, your BG remains constant below target, your basal should be reduced (mainly the basal rate of the 3 or 4 hours before your neg iob) to lower the "0 IOB reference" with less insulin in your body.

So your step 4 should never occurs with correct values of basal rates: when you have neg iob, your bg increase and you are again on target after a while...

[robertrub]

JP, once again, you're talking about why we arrived there and not what we should do in this situation. This situation will arrive whatever the basal settings (I've already stated the reasons before,too strong activity, error in carb counting etc).

The driver braked too strong and the car is skidding and will hit the wall/car near by. I'm asking what should we do to stop the car hitting the obstacle and you're talking about winter tires or braking techniques... The ABS will kick in whether or not the driver has the correct tires or brakes as he/she should. AAPS should do the same : if neg IOB, stop using it to stop the hypo risk.

N.B. It is snowing outside, thus the car analogy ;)

[Philoul]

This situation will arrive whatever the basal settings

No, I don't agree with you! If "neg IOB with overcorrection leading to hypo" arrives 3 or 4 times per week it is the direct consequence of at least wrong basal settings.

If your ABS is triggered every 2 days when you take your car, the 1st thing to do is to drive more slowly (reduce some of your basal rates). You explain as if the negative IOB is an abnormally risky situation. No! It's normal to have during a day negative IOB (it is "as design" in the algo to best manage all situations). And it is thanks to these negative IOBs, that our BG can remain very stable close to target especially during nights. Curently I can have several periods of negative IOB every day (even when I'm below my target and during nights), but the "overcorrection leading to a hypo" very rarely. I had it in the past (so I perfectly understand what you explained), but it was the correction of my profile that made it possible to fix it.

[vanelsberg]

@Philoul

So your step 4 should never occurs with correct values of basal rates

And exactly there is the problem with -IOB logic when on low BG: Now you are assuming human body is a machine always performing as programmed. But this a wrong assumption in the first place. There is no such thing as a "correct basalrate". If it were we did not need oref (and autotune) in the first place and could do with some basic "static" rules.

In real life "correct basal rate" is varying constantly. And AAPS/oref is continuously adjusting to what is "current" status. Trying to stay within range and preventing hypo's. The lather means: lower (or evn stop) insulin if BG is about to get below target.

So if despite your neg IOB, your BG remains constant below target, your basal should be reduced

So actually that is what is AAPS is doing: temporally 0-temping, effectively lowering basal in current context. But then again it is not as it forces past basal based on -IOB logic. And logic dictates this must result in the original low BG value unless taking additional carbs.

[robertrub]

So if despite your neg IOB, your BG remains constant below target, your basal should be reduced (mainly the basal rate of the 3 or 4 hours before your neg iob) to lower the "0 IOB reference" with less insulin in your body.

An example : You exercise from time to time and your insulin efficiency will raise which will make your "normally" correct basal too strong for several hours and then ISF will drop to "normal" again. During this time, as your insulin sensitivity is higher (stronger), you'll get lower BGs with the basal insulin. You'll force the neg IOB situation that started with the exercise.

AAPS's job is mainly predicting the future and adapting to this calculated future to keep BGs in range, away from the hypo line. So, even if there is a wrong basal (which is not my case, Theo's case or your case) AAPS should know how to react to it and get the user away from the hypo line. There is no perfect profile, AAPS should deal with the situation at hand.

Even with your excellent basal profile, you had neg IOB and touched the hypo line at night... You can't "punish" the user with a hypo if s/he makes an error in her/his basal.

It is not an "acceptable risk" to inject insulin at 80 with a delta of +1 and find yourself with a neg delta and going towards 70 just because you have neg IOB. Even if you don't hit hypo, the risk is there. In my car example, you can't say "If you had winter tires, you wouldn't be in this dangerous situation..."

I'm still waiting a logical explanation to the "missing" insulin that, for me, is a total nonsense. ;) You can never have missing insulin that needs catching-up.

[robertrub]

No, I don't agree with you! If "neg IOB with overcorrection leading to hypo" arrives 3 or 4 times per week it is the direct consequence of at least wrong basal settings.

So what ? The user has "bad" settings, we all do. Once more, you're stuck at the why and not what can be a solution. I agree for a big red message telling that the user should check basal settings because s/he is getting regular neg IOBs but stop pulling her/him down trying to catch-up the neg IOB.

[vanelsberg]

@Philoul

If "neg IOB with overcorrection leading to hypo" arrives 3 or 4 times per week it is the direct consequence of at least wrong basal settings.

In theory yes, in praktice no:

1. Due to sensitivity changes.
2. Due to much insulin (slightly over estimating carbs or IC changes due to sensitivity

If your ABS is triggered every 2 days when you take your car, the 1st thing to do is to drive more slowly (reduce some of your basal rates).

During wintertime on slippery roads my car's ABS & ESP are doing overtime even when driving slowly.... ;-)

No! It's normal to have during a day negative IOB ...

Is that so? Please explain why this is normal? I do not get this. Less insulin required, that normal. But forcing insulin anyway because theory says so?

And during the day same applies: I will be taking carbs as soon as I realize I'm getting to low. That happens. And when on -IOB I take additional carbs just for sake of compensating for -IOB (calculator does that for me). But if I do act - or not able to get enough carbs in - I will have the same problem.

[vanelsberg]

Actually I do not understand why we are discussing this.

oref0 is a model that happens to use -IOB to accomplish some of its requirements. But in real life it does not work or at least imho does more wrong then good.

And the claim that -IOB in practice does not work is so easy to prove: Just stop taking carbs, and when on target give some additional insulin that without 0-TBR would result into a hypo (simulating overestimation or to high basal rate). When below target, take carbs to get back onto target. See what happens! QED

yes: one can argue "basal rate" was wrong (yes that happens as basal rate is not a constant) or to much insulin given (yes that can happen as IC and ISF are not a constant + humans make errors).

That is just why AAPS is wonderfully compensating to real life. But under circumstances it can't because of -IOB.

[vanelsberg]

Suggestion: maybe we should move this discussion to the oref0 dev community? I guess whatever we discuss here will not benefit or change oref ;-)

@Philoul: please do not take this personally?! Always interesting get other views/opinions

[sprig3]

When below target, take carbs to get back onto target.

I think this is more because algorithm is expecting the increase to continue.

-IOB affects the next 5 hours (just like +IOB affects next 5 hours). Algorithm will run you high by about half of IOB or low by about half of -IOB. Dunno that there's much to improve that without autosense or automation or profile improvement. (otherwise, I'd expect more reactive highs)

But... would be curious to see how the no -IOB when below target "hack" could work in practice.

[Philoul]

Just stop taking carbs, and when on target give some additional insulin that without 0-TBR would result into a hypo (simulating overestimation or to high basal rate). When below target, take carbs to get back onto target. See what happens!

I just do not understand what you want to demonstrate with this kind of test... AAPS is designed to always let you in a safe situation if for any reason your loop is broken (no battery in your phone, phone stolen, broken...) My proposal is another test: check if you are safe during your nights with your profile: Stop your loop 2 or 3 hours before going to bed while stable on target, and let your basal manage your night. If everything is ok, you should should be stable all the night and be approximatively at the same BG value when you wake up. This kind of verification should be done by any looper regularly to check if basal is ok during night (no activity, no carbs...) If you wake up during your night due to an hypo or hyper alert, or if you have important variations of your BG, you should adjust your basal rates. => This is what autotune tries to do (but autotune works fine only if you don't cheat your data with for ex. missing carbs...)

[robertrub]

OK, here is a real life situation once more. Yesterday noon, I mess up my calculations (or I enter the wrong numbers in AAPS or the scale is not working well or the potatoes don't contain starch...). BGs are not going up as they should and AAPS stops the basals (very grateful for that :) ). At around 14h, I still have neg delta and near 70, I eat a biscuit (without entering the carbs in AAPS). I hear regularly my "Going to hypo" automatism (AAPS sets a high temp to stop any insulin injection to catch up (!) the effects of neg IOB). I eat another biscuit at 16h (BG at 69). At 17h30, I end up with -2.5U IOB !!!

2.5U neg IOB in English means "your body is missing 2.5U insulin"!!!! My body got TOO MUCH insulin and is in no way missing insulin. AAPS trying to catch up the neg IOB all afternoon kept me near (too near) the hypo line.

Question : how to get rid of this totally wrong neg IOB ? I entered 2.5U insulin (register but do not inject) which brought the total IOB to 0 but I still have -2.5U basal IOB... The only way I found was to stop SMBs, eat without entering carbs so that AAPS would be forced to use up to 300% basal rates to clear the neg basal IOB... I don't find the necessity to "cheat" to solve a problem AAPS created (ok, I did the initial mistake but who doesn't make mistakes ?) not acceptable.

As you can see, this had nothing to do with my profile settings and can't be argued away with "if the profile was correct...". It was a plain, simple user error and AAPS kept pushing my head underwater :(

NOBODY CAN BE MISSING INSULIN IF S/HE IS BELOW TARGET. Biologically, it is not possible.

1/ There should be a "Reset IOB to 0" option somewhere. 2/ There shouldn't be any neg IOB (but that is to be tested first).

A simple (yes I'm exaggerating) IF IOB<0 THEN IOB=0 statement before the loop starts the calculations would permit those who want to test the no neg IOB theory to test and see if it works. Milos, you can even make a big text : "Experimental IOB version; DO NOT USE" so that you'll be cleared of any back slash risk.

[sprig3]

Rob, the negative insulin doesn't mean "missing insulin now". It means "missing insulin activity in the future".

WRT "nobody can be missing insulin if below target", IOB doesn't include past activity of insulin, only "future activity of insulin".

So, the -2.5U the loop has seen that 2.5 units worth of future insulin activity is missing. The -IOB will decay with time, so the "error" does not stack up more than DIA (~5 hours) time worth.

Think about it this way (Assuming a 5 hour DIA): If you suspend your basal for 1 hour. In theory, it will have small effect for that hour (the 4 hours before that - your basal was on), but it will have a big effect for the next 3 hours (and then a little tail for hour 5, just like the reverse curve of a bolus injection).

(Not saying the modification you are suggesting shouldn't be done as an option for an essentially less aggressive mode.)

[robertrub]

You have the same logic as Philoul that really does NOT talk to me :( At a given moment, I have a certain amount of insulin in body, some part active, the other par will be active in the future. I think that we can agree on that.

There is no indication of what amount of insulin I'll need (or not) in the future. I might go for a walk and not at all need any insulin or I night stress and might need insulin to bring down hormone related BGs. At time zero, you CAN NOT tell if I'll need insulin or not in the near future.

The fact that the basal insulin was not given (because it was replaced by bolus insulin or activity or les carbs...) doesn't tell that I'll need something in the future. If I don't tell that I'll have carbs or if my BG does not raise, no formula can guess what my future needs will be.

Neg IOB is just doing that "I did not give you your basal, thus I am asserting that you will need it in the future." That is a false assumption. The "non given" basal was not "missed", it was replaced, it was given under another "name".

Without a crystal ball ;), just by looking at the past, nobody can guess what insulin I'll need.

[Pamalosebi]

The last weeks I fokused more on my IOB. I have to say, I almost never experience negative IOB in AAPS. Is now something wrong at my profile? Should that be a thing?

[sprig3]

Yeah, loop can't predict the future, Rob, you're right. It can only guess and get close.

If you are 180 mg/dL and have +2.5 IOB, you would not say "I should have 0 IOB, because the amount of insulin given has gotten me here". The 2.5 IOB is representative of what will happen in the future. If you consistently have your basal set too low, you will always have positive IOB and be above target. You will be closer to target than if you didn't have a loop, ofc! But, the loop won't bring you in for a landing at target (without Autosense I guess, eventually, Autosense might help out).

Same is true of the -IOB (future insulin action, not past). The loop can get you ~half-way, but it can't get you all the way or know that you will need less insulin in the future than what you told it (as you point out, those pesky Crystal balls just don't seem to work all the time).

If you know that you'll need less insulin, there are ways to tell the system that - profile switch, record fake insulin, etc.

Obviously, we all want less management, so I definitely applaud your effort to come up with some code that helps manage without intervention. Perhaps it could even lead to a mode similar to how the basalIQ users hack their system (my endo does this): set basal about 20-30% too high and let the basalIQ loop reduce/suspend over and over again to keep you out of hypo. (of course, a problem if dex isn't working)

[Philoul]

@robertrub, I'll try to explain you another way. Forget the "relative IOB" (that can be positive or negative), and just focus on your absolute IOB (the absolute quantity of Insuline active in your body you need to keep your BG value within range). This absolute IOB is ALWAYS positive (it equals to 0 if you unplug your pump for DIA duration or more...)

Now forget also the loop algorythm and consider a day with this absolute quantity of insulin. This abolute IOB will also be the relative IOB calculated with a "theoretial null profile" (with all basal rates equals to zero). (neg IOB is completely removed...)

With exactly the same absolute amount of insulin in your body, if you now calculate a new relative IOB with another theoretical profile with all basal rates higher than the highest one received. With exactly the same amount of absolute insulin, your new calculated relative IOB will almost always be negative (positive only very few periods after meals with Boluses).

Now consider your loop is trying to give you the absolute amount of insulin you need,, the higher your basal rates are in your profile, the lower (and too often for you), your relative IOB will be negative.

Question : how to get rid of this totally wrong neg IOB ?

The answer is: reducing the basal rates your profile will mathematically increase your IOB, the loop will still try to give you the same absolute quantity of insulin, but with more high TBR, less negative IOB, and these negative IOB will be with "higher value" (closer to zero) and correctly managed by the loop (they will help you reach your targetand stabilize your BG and won't send you into an hypo).

[robertrub]

I give up. Last message.

You're all talking theory, I'm talking real life. I'm telling that in real life, your theory is not working but you don't want to hear it.

Here is another real life situation where neg IOB catch up pushed me to a hypo once more. Zoom the screen capture and you'll see.

At 2AM I'm starting the neg IOB trip. At 2:15 (approximately), I'm on target. Life is great. Basal stopped then reduced and generating neg IOB. At 2:30, I must have had a very little positif delta as AAPS sent an SMB and raised basal (I suppose to catch up neg IOB , as there is no other reason as I'm on target).

At 2:45, I'm below target but still on higher basal (still trying to catch up I suppose)... At 3AM, below target and going down but with still high basal.... my security automation kicks in and raises target to force AAPS to stop the basal and neg IOB catch up. It is not enough as I'm woken up in a hypo.

You can talk all the theory you want, the theory is *uking my life. If there was a no neg IOB security setting, I wouldn't be in a hypo 59 at 4AM

[Philoul]

Look at your graph between 01:00 and 03:00, you have a majority of red deviations bars (you are more sensitive to insulin than expected by the loop). Between 01:00 and 03:00 your BG curve is a straight line with a BG value decreasing from ~140mg/dl to ~80mg/dl (about -20mg/dl per hour) When I analyse your TBR curve, you got approximatively basals of your profile during all this period.

Your BG drops down much quicker than expected by the loop, you are more sensitive to insulin. So reduce your basal between ~23:00 and ~03:00. (it's possible ISF is also a bit too low)

[swissalpine]

@Philoul As already written above by others: Your suggestion fits to cure a recurring situation; but when it comes to a one-time event, the suggestion is useless because I do not adjust my basal in advance for lack of psychic abilities. In my opinion, it is also not about the fundamental concept of a negative IOB (I bring negative IOB for sport on purpose!), but about the function to compensate negative IOB at the first best opportunity, as soon as even a positive delta shows up. To limit the algorithm here and to relativize the compulsive IOB compensation, the striving for 0 IOB, would be quite conceivable - then I would also no longer need an automation rule that prevents all SMB by a slightly increased temporary target (BG < 110 mg/dl => TT = 101). Because without this workaround, I irregularly experience exactly the situations @robertrub talks about.

[robertrub]

I'll try one last example (yes, I'm stubborn...) I hope some OREF people are reading this discussion...

We'll look at the problem from another perspective.

I want to drive from point A to point B, 100km away. My navigation app says "Taking in consideration your car specs and the profile of the road, you'll use 10 lt of fuel". For some reason (back wind, driving slowly...), I arrive at destination with only 9 lt fuel used.

It is not logical to go further away from destination to use the unused fuel. It is unlogical to says that for the next 100km, I'll use 11 lt.

The only conclusions we can have :

1/ The calculations were wrong (for whatever reason) 2/ Once on destination, no need to keep the old erroneous calculation results. 3/ For the next 100km, I might use 9 lt again but I might as well use 10 lt. It is very unlikely (but not a 0 probability) that I might use any other number if the conditions change.

Replace 100 km by 100g carbs and lt by units. The destination is target and the navigation app is AAPS/Oref.

My situation right now. 0 COB, below target (100), negative delta for some time, but as I have a neg IOB, AAPS is still giving me some basal... I know that the amount is ridiculously low but so is my neg IOB. With a stronger neg IOB, I'd get a higher basal.

The logic of it is wrong. There is no indication that the BG will raise but AAPS still wants me to go further from destination as I didn't use all the fuel it had calculated...

[sprig3]

Yeah, Rob, I get why you're pursuing this. This is our lives. Day in, day out, this stuff is big for us. I also get your point that you're trying to get the algorithm to handle deviations from expected even more. But, the loop isn't keeping track of historic missing insulin, only future missing insulin. So, your car example isn't quite right.

I think what you are wanting is a more robust learning algorithm or a faster Autosens concept. (One that takes into account observed increased sensitivity in the recent past maybe 2-4 hours rather than the past 8-24 hrs current autosens uses.)

That logic you are describing is negating the idea of insulin on board either positive or negative. If I am high and I just gave 5 units of insulin, and check 1 hour later and am still high, should I give 5 more units? (obviously, some might take the extra insulin and just choose to eat some glucose on the other end, hehe!) No, the loop will see that the 5 units given an hour before have ~4 IOB left (or something, based on curve and DIA) and will only give how much it thinks you need beyond that 4 IOB. (theoretically just 1 more unit or something)

The same goes for negative insulin on board. See how the prediction line shows that in about 3-4 hours, it expects you to be at target?

At t=0hrs, If you have a 1 u/hr basal rate and a 1:40 ratio and you suspend insulin for 1 hour, then you'd expect over the next ~5 hours to rise 40 mg/dL. Past sensitivity doesn't enter into the equation. (well, autosens might take into account the last 24 hours) So, at t=1hr, you'd still be expecting a ~32 mg/dL rise. (iob = -0.8 approx) (math not precise, insulin decay is messy in basal, since it's dribbled in bit by bit) at t=2hr, the negative IOB would be "decayed" further, so iob would be about -0.5 and you'd expect bg to rise another 20 mg/dL over the next ~3 hours.

If we didn't do the neg IOB concept, then how would we avoid overcorrecting? Do you just keep suspending basal entirely until you are back at target? If that took 2 or 3 hours for the suspended basal to have an effect, you would expect to go high for the next 4-5 hours after that. It is easy to imagine that insulin takes an effect instantly (and perhaps sometimes it does - muscle/vein injection sites spring to mind), but theoretically (and in the loop calcs), it does not.

The negative IOB isn't being "added back in" exactly. The loop algorithm is suspecting that you are going to go high based on your target and your negative IOB amount and it's trying to correct that future high. (just like it would do if you were above target, it wouldn't put on "too much" insulin, sometimes frustratingly so!) As such, with both highs and lows, I find the loop can only take me about half-way towards target.

The "hackaround" of not telling the algorithm about any negative IOB I see more as very aggressive low prevention method. Personally, I think the automation of profile switch to 50% sensitivity or something is better. (and maybe turning off SMB without the presence of carbs or something.) But... it would be interesting to try it out and see how something like that would work. Maybe for those nights where I have worked out alot that day and I think I'll be more sensitive that night, but not sure by how much and don't want to just run high all night.

[robertrub]

Yes, I want a more aggressive hypo risk management. A hypo is a health risk, a momemtary hyper is not (and AAPS has largely the time to stop BGs going too high).

I totally agree on positive IOB. AAPS is totally capable of calculating it's action over time.

Where I don't agree is deducting that I'll end up in hyper if the not given insulin is "discarded". There is a reason the user ends up below target with neg IOB: either s/he got too much insulin or the insulin is acting more efficiently and the basal was stopped. You cannot deduct that the user will be high if there is still a neg delta or a little positive delta and is under target.

My car analogy holds, if the back winds continue, the car will still need less fuel for the next trip and will choke if forced to use more ;)

All I can do actually is cheat with a reduced profile (limited to 70%...) in order to stop getting more neg IOB...

[robertrub]

@sprig3 Compare 2 situations. For both, target = 100, BG = 80, COB = 0

A: There is a -1U IOB B: You did a db reset and COB and IOB are at 0

Which situation will bring you faster to target ? Definitely B. Will it end in a High after reaching target ? I say no, you say yes ;)

@MilosKozak is it possible to put a button or menu option to set basal IOB to 0 ? This way, no need to touch the algo, no automatic IOB change. Just a neg basal IOB reset by user ? This way, a select few who want to test the no neg IOB theory can test it without needing big algorithm and code changes.

[sprig3]

You can bolus and "record only".

In your A and B situation, you're making a judgement call. Do you think you will need the future insulin or not?

I sometimes do that to force the loop to be more aggressive at treating a high (I will bolus 0.X units and then go to treatments page and remove the bolus). It's risky, though, and definitely not something I'd want to trigger automatically.