Allow more general pump dependent settings for maximum bolus and basal rates

[LiroyvH]

It would appear that the Max Bolus directive on Medtronic pumps (Tested on 754 and 722) does not accept values higher than 25 over the remote controller OR a bug in Trio prevents it from being sent. (Anything over 25 seemingly demands you manually change it on the pump, where a difference is that you must acknowledge a warning that the value you're attempting to set is "unusual".) -edit- It is currently unclear whether or not the problem is caused by the pump or the app, recent discussion suggest the issue lies within the app; not the pump. -/edit-

Trio, however, pretends the value gets set when you choose "Save on pump" in the Pump Settings menu. It does show it didn't actually get set when you go out and back in to Pump Settings.

Depending on the cause of the issue, if its the pump: I think it may be beneficial to add a warning whenever someone attempts to save a Max Bolus value higher than 25 on Medtronic pumps. (Eg: prompt user warning them that a value higher than 25U cannot be set through the app, but the user can manually change it on their pump. (And then ask them to confirm they've set it to \<whatever they wanted to set> or cancel (doesn't save new value in app).). If it's a bug with the app refusing to send something higher than 25: this should be fixed.

-edit- This leads to another problem: even after having set the value to 35 on the pump manually, Trio still thinks its 25. Attempting to save 35 in Trio simply doesn't stick. So the pump is now on 35, but Trio on 25 - which limits the maximum bolus that can be administered.

-edit2- Edited the json file for pump settings to fix the issue in the edit above this edit. This edit to the config does seem to stick. (So manually edit on pump, then edit in config json)

-edit3- Clarified what I meant by refusing to send a value higher than 25U to the pump before the wrong idea is gathered. There should NOT be a hard cap of 25U to set as MaxBolus. Rather, I meant that a value higher than 25U should not be sent to the pump to try and set it IF that's not possible remotely. (Currently unclear.) But in any case we should allow the user to set a higher value if they manually set it higher on their pump. PR #266 might offer a way out if there is an extra check for Medtronic that the input in the app matches to what the pump has set on it. However, judging by the comments and answers to question: such a check isn't performed. As such, I don't think it'll truly solve the problem.

Ideally, also taking #266 in mind, we warn the user on a Medtronic pump that a value higher than 25U cannot be set remotely (IF that is true and it's not a bug in Trio); but they can set it on the pump. Then ask them to confirm it is set or to cancel. If they say it's set: query pumpManager (if the changes in #266 can do that) to verify that its true. If it is: Done, save it in app. If it is not: error out that there's a mismatch. (Don't change values.).

[MikePlante1]

Interesting. Do you know if AAPS or Loop or iAPS handles this better?

Looks like Max Bolus on x54 can be manually set as high as 75U, but I think all other Medtronics tap out at 25U?

[LiroyvH]

@MikePlante1 Not sure. I never tried to set it higher then 25 before as I thought it was a viable safety limiter. (Turns out it isn't enough anymore -_-) Doubt iAPS has a fix, never heard anyone complain about this before.

I'm not sure about the 5xx versions. As those contain smaller vials, it wouldn't surprise me if they can't go as high. Will look around :)

[MikePlante1]

AAPS docs just says

The maximum value permitted by the pump is 25.

[LiroyvH]

@MikePlante1 For the 7xx varieties? Both 754's I have here allow up to 75U to be set. It just gives a warning that it's "unusual". :P

[MikePlante1]

@LiroyvH Could you give Loop a try to see if it handles things differently? I only have a 722 myself for testing.

[LiroyvH]

@MikePlante1 The 722 only does 25? I can test it once my other 754's keypad has dried up. :( It went swimming yesterday. In a watertight bag. Which turned out wasn't watertight. Can probably test this somewhere in the weekend. (Because if it still shorts the keyboard then, I'll have to open it up and fix it :P)

[dsut4392]

I can test this tonight with both 715 and 754 and Loop/iAPS/Trio.

[dsut4392]

Tested on Loop 3.3.0 - the picker doesn’t allow selection of values greater than 25U.

iAPS (2.3.x dev Dan’s branch) and Trio both allow choosing a value higher than 25U, but that value is not set on the pump, presumably because the pump requires confirmation of the value as Liroy has identified. The value isn’t retained after you exit the pump settings screen.

if you set a value over 25 on the pump, and edit the setting in Trio to a different value still over 25, no change is made to the value set on the pump. Once you exit the pump settings screen, no value over 25 for max bolus seems to be stored, the UI retains the last saved value below 25. This is true even if you set the max bolus in Trio to the same value you have manually programmed in the pump.

If you manually program a value over 25 in the pump, then save a value under 25 in Trio, the correct value is also saved on the pump.

When you set a maxbolus of 25 or below, log.txt includes both “setmaxbolus” and “readsettings”, which returns the values saved on the pump. However when you try to set a maxbolus over 25, nothing seems to be added to log.txt.

I don’t know how many people use a max of greater than 25, it seems likely a bit of an edge case given that neither Loop nor iAPS 2.3.3 appear to allow you the set a value this high? Is setting an upper limit on max bolus of 25U a good enough solution?

[bjornoleh]

Sounds like we need to enforce a max 25 U bolus for the relevant pump models?

[MikePlante1]

Interestingly, the Omnipod DASH and Eros manuals say max bolus can be as high as 30U.

[bjornoleh]

Exactly, so we probably don’t want to limit pods as well.

[marionbarker]

Loop uses the per-pump settings to determine supportedBolusVolumes. See links below.

For pods, it is 30 U (600 pulses). For Medtronic, it could be adjusted by pump model (as basal rates are), but all pump models are limited to 25 U. Looks like DanaKit is also 30 U.

• https://github.com/LoopKit/OmniBLE/blob/dev/OmniBLE/PumpManager/OmniBLEPumpManager.swift#L1572-L1576
• https://github.com/LoopKit/OmniKit/blob/main/OmniKit/PumpManager/OmnipodPumpManager.swift#L1529-L1533
• https://github.com/LoopKit/MinimedKit/blob/main/MinimedKit/Models/PumpModel.swift#L106-L108

[dsut4392]

Worth keeping in mind that the bolus rate of these pumps is only 1.5U/min. For 25U bolus, that's 16 min 40s or more than three full loop cycles. How often is someone going to want to ignore three or more updated CGM readings and just keep bolusing away? I don't recall ever seeing a complaint on @Looped or @LoopandLearn fb groups from someone wanting to set a higher maxbolus, so limiting it to 25 is probably fine. Updating the docs to say "If you wish to deliver a bolus greater than 25U, you can trigger this on the pump" might be nice and low-effort.

[LiroyvH]

Why would you hard limit this when there are clear usecases where people need more...? That there aren't many complaints (or maybe some people simply haven't noticed because the app pretends it actually get's saved.) is imho not a very strong reason to make the app unusable or unnecessarily hard/annoying to use for the users whom do need far bigger boluses than 25U. Not sure why you should care about missing loop cycles either. You know the pump will be busy for a while. :)

I find it very odd that we'd "low-effort" put a cap on this to make it easier to manage rather than doing it properly for the pump models that do support higher boluses. I honestly don't find it a good solution to put a hard cap on 25U, sorry. With the same reasoning we could re-introduce the COB calculation caps and denying users with an I:C lower than 1:3 access to a working app; it was way simpler not to support it at the time. Surely that's not a desired direction to go in. Keep in mind there's also T2D's getting more interested in loop solutions with access to CGM's and pumps.

I'd strongly prefer an outcome where if its possible to support higher boluses because the pump supports it: it's supported. Limit it to the maximum of the pump model, don't put a 25U cap on it "just because that's easier". ;) And that's not only because I so happen to be one of those users who really doesn't want to have to bolus from his pump every time I need more than 25U in one-go; which can occur multiple times a day. I find it a matter of principle as well. Patients (T1/T2/LADA/MODY and all sorts in between) come with all kinds of requirements of their own, one patient isn't the other. Whilst you reasonably cannot always cater to all wishes/needs: something relatively simple such as this is the kind of low-hanging fruit that ought to be addressed rather than be dismissed imho. There's multiple users with I:C < 2 that'll very easily run in to the 25U cap and would prefer not having to grab their pump instead of conveniently bolusing from their phone which, in addition, gives the proper recommendation.

[LiroyvH]

Just to update/clarify what I find the ideal solution:

• Most importantly: do not impose a master limit of 25U, impose the limit based on the pump model.
• On supported Medtronic models, when the user attempts to set a value higher than 25U: warn them this cannot be set through the app, but that it can be set directly on the pump and that they should do so if they wish to change the Max Bolus. Ask them to confirm they've set it or to cancel. (If they confirm: update MaxBolus to the desired amount. (If the user lied and didn't set it: pump will error out when attempting to bolus and Trio will throw error that Bolus failed - so that's not a problem.). If they cancel: do nothing, do not save input.) And of course if the user has a Medtronic model that allows only up to 25U: then that's the upper limit, simple as that.
• If, just as suggested in #266, there's a method to ask the pump what the value is currently set to: this can be used as an extra verification. If the user in the suggested flow above taps "confirm" that they've set the new MaxBolus in their pump, pumpManager will query the pump to verify if it's true. If it isn't (eg: Max Bolus is higher/lower than what the user gave as input): error out. If it is: splendid, save the value as new MaxBolus-limit. (- Bonus: I wonder if it's ideal to query the pump for such settings from time to time and warn if there are mismatches.).

And for Omnipod: simply allow the user to set up to 30U if that is its limit. Higher than 30U shall not be allowed as Omnipod doesn't support it. And for Dana: I suppose a warning should be added that the MaxBolus value cannot be changed through the app. (But tbh, #266 is still unclear to me so I still don't understand what the check on the pump is for if it always throws other values than what is set.)

[marionbarker]

tbh, https://github.com/nightscout/Trio/pull/266 is still unclear to me so I still don't understand what the check on the pump is for if it always throws other values than what is set.)

PR 266 restores the Pump Setting page to the original value if the save to pump fails, otherwise it reports what was saved to the pump. It is better than not having it, but more work is needed in the future.

Without PR 266 - if you try to save an invalid value to the pump, it pretends to save and page is left with the requested value; but if you exit the page and go back into Pump Settings you see that no change was made.

With PR 266 - after it comes back from the save tap, you can see on the page itself that the original value was restored.

Different pumps:

• Omnipod - no concept of maxBolus, but 30 U is the max bolus the pod can support
• Medtronic - I'm guessing the 25 U was set as the one and only maxBolus early on. Now that there are additional pumps supported with higher allowed maxBolus, this could be modified to handle a maxBolus per pump model. This would require work added to LoopKit/MinimedKit and a volunteer to do the work.
• DanaKit - this is a read-only function for this pump. Moving forward, adding a pump without remote option to set maxBolus or maxBasal may trigger some higher level redesign to handle it.

I can understand why DanaKit provides selectable rate options for how fast to deliver a bolus with a maxBolus of 80 U.

[dsut4392]

Why would you hard limit this when there are clear usecases where people need more...? That there aren't many complaints (or maybe some people simply haven't noticed because the app pretends it actually get's saved.) is imho not a very strong reason to make the app unusable or unnecessarily hard/annoying to use for the users whom do need far bigger boluses than 25U. Not sure why you should care about missing loop cycles either. You know the pump will be busy for a while. :)

I find it very odd that we'd "low-effort" put a cap on this to make it easier to manage rather than doing it properly for the pump models that do support higher boluses. I honestly don't find it a good solution to put a hard cap on 25U, sorry. With the same reasoning we could re-introduce the COB calculation caps and denying users with an I:C lower than 1:3 access to a working app; it was way simpler not to support it at the time. Surely that's not a desired direction to go in. Keep in mind there's also T2D's getting more interested in loop solutions with access to CGM's and pumps.

I'd strongly prefer an outcome where if its possible to support higher boluses because the pump supports it: it's supported. Limit it to the maximum of the pump model, don't put a 25U cap on it "just because that's easier". ;) And that's not only because I so happen to be one of those users who really doesn't want to have to bolus from his pump every time I need more than 25U in one-go; which can occur multiple times a day. I find it a matter of principle as well. Patients (T1/T2/LADA/MODY and all sorts in between) come with all kinds of requirements of their own, one patient isn't the other. Whilst you reasonably cannot always cater to all wishes/needs: something relatively simple such as this is the kind of low-hanging fruit that ought to be addressed rather than be dismissed imho. There's multiple users with I:C < 2 that'll very easily run in to the 25U cap and would prefer not having to grab their pump instead of conveniently bolusing from their phone which, in addition, gives the proper recommendation.

I don't disagree with your ideal outcome, I just don't think it's likely to be a high priority because it comes up so infrequently. I've done a search on Looped FB group and I only found one post (https://www.facebook.com/groups/TheLoopedGroup/permalink/2975389479344365) from someone wanting to change this in the last 3 years. There are probably posts I missed, and more people who would like to but don't know it's possible, but the subset of loopers with I:C < 2 who also own one of the pumps that can do this must be small, and getting smaller all the time.

[LiroyvH]

Let's assume that's true, though I don't think it is as the Dana pumps support values (muuuuch) higher than 25U as well (And Omni does 30) - so if the group has been getting smaller due to declination of Medtronic use: it'll likely grow again with the addition of modern pumps (Dana, Medtrum), then there's still a very big difference between adding proper error handling and adding a hard-cap of 25U which causes the people whom do need the larger boluses (and can at least manually work-around it at the moment by changing it manually on the pump and modding the JSON (though the latter ought to be fixed)) to get in to major trouble operating the app in a satisfactory way. The app would become much harder to use, up to too annoying to continue using it, for me if I cannot set a value higher than 25U because of some arbitrary hard cap as mitigation to bad error handling in one section of the app.

In any case: introducing a hard cap of 25U for all pumps (including all the pumps that can offer (much) higher values) is not an actual solution imho and causes more problems than it solves.

[marionbarker]

I think the bottom line is that this Issue

• should be renamed to Allow more general pump dependent settings for maximum bolus and basal rates
• should be completely decoupled from PR #266
• if necessary, write a new Issue to explain why PR #266 is needed

[jbr7rr]

Interesting. Do you know if AAPS or Loop or iAPS handles this better?

AAPS has limits set per pump, and an overall hard limits for certain things.

For Medtrum Development it will even be different per Medtrum Model (Nano, 300U and future 400U have different bolus and TBR allowance) Ultimately my preference is that we would specify limits in the pump plugins

Reference: https://github.com/nightscout/AndroidAPS/blob/3df83535f9f8f3246308121900c2785c50915fa8/core/interfaces/src/main/kotlin/app/aaps/core/interfaces/pump/defs/PumpType.kt#L414 https://github.com/nightscout/AndroidAPS/blob/3df83535f9f8f3246308121900c2785c50915fa8/core/interfaces/src/main/kotlin/app/aaps/core/interfaces/pump/defs/PumpCapability.kt#L30

Reading the code againI realize the max bolus on AAPS could also improve but different topic