Support for extended bolus

[savek-cc]

Hi @dv1, I was actually part of the group who did the initial work on the combo integration - and I actually did extend AAPS to allow extended Bolus with the Combo (as I do have issues with e.g. 16U being delivered all at once - the pump site just starts leaking). So for that I've been using the extended bolus feature to deliver said 16U (or actually anything above 3U currently) as an extended bolus over 15 minutes and also made AAPS to be aware. I was wondering if you were up to discussing adding extended bolus support in this driver (while not necessarily to AAPS for everyone as there are precautions to take when using an extended bolus).

[dv1]

It is currently unknown how to do an extended bolus through the command mode. It is possible, but we don't know how. We'd have to reverse engineer this from the communication between the handset and the pump. And I really would not want to do the extended bolus through the remote terminal mode, since this would add significant amounts of complexity.

The problems with large dosages have been reported by a number of people, especially with the Combo, since it delivers a bolus so quickly. Perhaps as an alternative we could revisit proposals for AAPS to either split a bolus or to only deliver part of the bolus and convert the remaining undelivered bolus into eCarbs?

[savek-cc]

Do you have a working setup for intercepting the handset-pump comms? (i.e. perform a man-in-the-middle as we did with the Insight). I do have handsets and combos available for testing (and Linux as main OS). While I think splitting into multiple small bolus doses might be a possible workaround, it would still result in quite the comms overhead (like .5u every 30sec?) and need to have the mobile in comms reach for the complete time. eCarbs - problem with that is that this might work for e.g. pizza -- but with my default breakfast of two buns and a glass of juice (~8KE), it would just take way to long for AAPS to react on the rising BG and deliver the needed insulin. With a 16U Bolus over 15min it works out as an almost flat line.

[dv1]

The problem with an extended bolus is that it does not fit with a dynamic closed loop system. An extended bolus is another form of fixed static TBR. How would this work when AAPS gets a new BG value and needs to readjust?

I unfortunately do not have such an intercept setup. There is affordable hardware for intercepting Bluetooth LE. But for intercepting Bluetooth Classic you need expensive gear. One alternative would be to set up a PC as sort of a Bluetooth middleman, but that is a substantial amount of coding work.

[savek-cc]

I do know the preaching (extended bolus is evil) - but I'm rather using it to get a slower bolus delivery speed with the combo. Just compare with e.g. the older Medtronic pumps: https://bionicwookiee.com/2019/07/30/bolus-speeds-how-fast-is-your-pump/ - they can take well over 15min to deliver 16u -- and still they're used for looping. Regarding the interception: The man in the middle setup is exactly what was used when reverse engineering the insight driver - it's neither that expensive nor complicated actually. You already have the "handset simulator" (pump driver) and all the crypto stuff - so what's missing is an implementation of the pump side handshake so that we could pass the handshake before then logging and forwarding the application data.

[dv1]

It is still a nontrivial amount of work. Doable yes, but time consuming. Perhaps I can do this later, but right now, there are bigger priorities. But I think some people already did such a setup. I'll ask. Also, we currently don't know if it is possible to cancel an extended bolus programmatically. Normally, you have to stop the pump to cancel such a bolus.

[dburren]

Splitting a bolus into sub-boluses can become a nightmare when reading back the logs from the pump. I use this in the clinical Ypso driver to provide a selectable bolus speed (3, 6, 12, and 33 [full] U/min). But there the BLE comms are fast and reliable, and I can put marks in the log to indicate the grouping of a multi-bolus so that when the logs are read (e.g. after a restart) they're assembled back into the overall bolus. That then aligns with the records in the database without stuffing up IOB by inventing extra boluses. A lot harder to do it with the Combo.

The pumps that run at 1.5 U/min take a long time to deliver 16U (keep in mind the rate also has to include any basal deliveries during that time) but at least they do it while disconnected from the host.

Theoretically extended boluses could work, but it's also worth keeping in mind that they don't do continuous delivery. Every 3 minutes the Combo delivers the next chunk of (basal plus extended bolus). Part of the extended bolus will also have been delivered when the command was issued. This does mean that AAPS's estimates of IOB are an approximation (e.g. it splits a basal up into 5-minute chunks) but it also means that with an extended bolus you want accurate reporting of exactly how much was delivered in total without trying to guess. The Medtronic pumps actually deliver basal on a 5-minute cycle. DANA is 4 minutes I believe.

This is a complex topic already, and adding extended boluses in adds significantly more complexity (although it can simplify a few bits too). Not only does it need detailed log information, and fundamentally the ability to issue the command to the pump, but speed and reliability of comms come into it too.

[savek-cc]

I really like this discussion :). About splitting the bolus - you're absolutely right; keeping track and state (and actually making sure that all parts get delivered) is even worse than just doing a "slow" (as to not call it extended and take the "10U over 3h" out of the discussion) bolus.

With the slow bolus, the Combo also does it while disconnected from the host - so that's a plus.. but on the other hand, you can only tell/be sure what the bolus was after it has been delivered in total (because that's when the log entry is actually written).

Also the user is able to cancel (or start) extended boluses at any time by hand on the pump - so that adds even more complexity (if aaps would completely allow extended bolus) - which is why I also think that extended bolus should not be something a user should be able to use for anything other than "reducing injection speed".

I actually didn't know/test how often/fast an extended bolus is actually delivered - but even splitting 16U in 5 parts over 15 minutes greatly reduces the average injection amount.

About the "hard for AAPS to calculate" - if you only use the 15min, it's actually negligible for the calculations from my point of view and can be handled like "full amount at timestamp" (even if I inject everything within one millisecond, it won't be absorbed and enter the bloodstream all at once anyway - and there is no differentiation for "slow" pumps in the code). Going by the 5min dexcom cycle, we actually "miss" 3 iterations of loop invocation - and in order not to have SMB/TBR during the time of an extended/slow bolus, I actually kept the code to pause the loop for the runtime of an extended bolus.

But: Currently (and on purpose), I started this discussion on the generic pump driver - not on the AAPS integration ;).

I really wish that I had the time to just setup up the mitm-setup and get the required data - maybe I can get to it and I'll definitely try (just used to have a lot more spare time a couple years ago when we did the first integration (even though most of the actual implementation was done by two other persons)).

[dv1]

One small note: It is currently uncertain if a command-mode cancel bolus command would also cancel an extended bolus. If so, it would improve things significantly.