Add a setting to limit maximum Insulin on Board

[erikdi]

This is useful to prevent multiple bolus' to create accidentally very high insulin on board values. It is primarily a safety feature, e.g. if someone enters too many carbs by using multiple apps.

For Bolus the intention is to limit the Bolus amount: "iob + bolus <= max"

For Basal the amount will also be limited by the same logic and is intentionally kept simple. It does not take iob decay over the basal interval into account. It will also not low temp if the IOB higher than the limit. If that's useful it would be pretty easy to do as well, but the goal of this patch is to prevent such a situation from happening in the first place.

Code wise, the limiting of the units could also be done in the insulinCorrection function. It's a bit less obvious in my opinion what happens in that case, but we wouldn't duplicate functionality in two places.

[erikdi]

Added validation to Bolus dialog as well (similar to the MaxBolus feature). Also updated to latest dev.

[erikdi]

@ps2 what do you think about this? In my opinion it is a rather fundamental safety feature protecting against all kinds of algorithm and user errors. What is missing to get this merged? Thanks.

[ps2]

The algorithm does not give any more insulin than the forecast components call for. We do not want to artificially hamper treatment, nor do we want to put the burden of managing yet another setting on the user.

If there are specific situations that you’re concerned about, I’m happy to discus. Perhaps there are ways to mitigate those situations without the negatives listed above.

[erikdi]

There is a few cases where I think the current maxBolus setting is inadequate. If you are worried with too many settings, we could also replace that setting as this is a superset of that functionality.

• it does not limit the amount of manual insulin you can give in consecutive bolus' , ie. repetitively giving Bolus because e.g. the people using Loop are not sure if a Bolus has been given before (yes, been there).

• it does not prevent algorithmic runaway. There are people setting maxBasalRate relatively high to get a quasi-bolus behavior. Especially together with a high manual bolus, there is currently no protection to pretty high iob values

• physiologically the total amount of insulin is more relevant than the amount of insulin in one treatment.

• it provides "defense in depth" against errors in the algorithm, e.g. see the recent problems with backfill creating very large glucose values.

• it provides defense against entering too many carbs. That case is currently generating a maxBolus suggestion, and then - immediately afterwards - another one. Let's say for example you (or your kid) fat-fingered 100 g instead of 10 g into the carb dialog.

[ps2]

All of those items are already addressed in various ways.

• Subsequent bolus issue is addressed by tracking pending bolus, and reducing subsequent bolus rec
• I want to go further and make the algorithm safer like we did with dynamic carbs so that we can even eliminate maxBasalRate.
• backfill issue was on dev, and is fixed. This is why we have a staged release pipeline.
• whatever you end up setting max iob to, to ensure effective correction (when high and a large valid number of fast carbs on board, for example), will certainly not prevent over treatment due to fat fingering carbs in other situations. There are other design techniques we can use (and are using) to help prevent these kinds of errors.

[erikdi]

• It is only reducing the recommendation, not preventing a user from manually inputting a higher potentially dangerous one (as long as it is below maxBolus). Also if recommendBolus has an error, this could still catch it.

• With maxIOB it would make a lot of sense to also eliminate maxBasalRate.

• Sooner or later one of these corner cases is going to be in master given the rising complexity of Loop (Omnipod!) and that the amount of manual testing is not going to cover all cases of weird hardware interaction. I think you are doing a phenomenal job, but it's not that a lot of visible code review is going on in this project. The coverage with unit and integration tests of the code base is also rather low. Most testing in practice seems to be done by real people either on a shadow pump or on themselves actually. Furthermore a lot of people seem to be comfortable using dev for the latest features anyways.

• It will not catch all kinds of over treatment, obviously, no, but it is certainly easier to let's say treat a few units too much, than let's say 10 units too much. I'm not sure what design techniques you are referring to, but right now I think you can still easily input 1000 carbs in the latest dev. Instead of adding a "maxCarbs" switch, maxIOB seems a more generic solution.

In summary I still think it isan easy win to prevent against a whole class of possible corner and failure cases.

[ps2]

I won't argue those points; they're representing valid concerns. But I feel that this kind of solution a) does not work much the time, even as a fail-safe (a much lower level of IOB is dangerous if you have no carbs on board and bg is low, for instance), and b) presents a confusing burden on users in determining how high to set it. The issues above are best addressed by focusing on the individual problem directly. And in particular, wrt to code review, you are certainly welcome to help with that. :)