Automated "supermicrobolus" delivery of mealtime insulin

[scottleibrand]

For users with well-tuned ratios (possibly thanks to #261), we may be able to safely use microboluses to minimize post-prandial peaks without creating additional hypo risk, by accelerating delivery of Eating Soon and AMA mealtime insulin (super bolus style) while at the same time running a zero temp long enough to counteract any extra insulin delivered if carb absorption does not materialize.

In order to safely deliver boluses without risk of overdelivery due to accidental repeats, we need to track reservoir volume as well as pumphistory. By checking reservoir volume before querying pumphistory, and then again immediately before a microbolus, we can ensure that no other boluses have been unaccounted for.

We should also verify (from both data sources) that no other boluses have been delivered within the last 5m, and that the total boluses delivered over the last hour do not exceed the max basal rate. Microboluses should not exceed 30 minutes' worth of regularly scheduled basal (i.e. 0.5U for a basal of 1U/hr) every 5 minutes. Each microbolus should not exceed half of the insulin that would ordinarily be delivered via high temp (as adjusted by expectedDelta), such that if 2U of additional insulin is required, it would be delivered as three 0.5U microboluses 5 minutes apart, then 0.2U at 20m, and 0.1U at 25m, unless minDelta drops below expectedDelta at any point.

For any microbolus that would result in eventualBG below target if played out over DIA with no additional carb absorption, a zero temp of sufficient duration to bring eventualBG back up to target should be set before executing the microbolus, so that if the rig loses connectivity to the pump, and BG starts falling, the additional insulin will be withheld before the bolus takes full effect.

In the case of an eating soon mode (low temp target) we would end up microbolusing enough to accelerate any necessary correction insulin and further correct down to the new temp target, while setting a long enough zero temp to eventually correct back up to target. For example, if we had an eventualBG of 120 vs. target of 100 and were recommending a high temp to deliver 0.5U extra insulin, and would need an extra 0.5U to correct down to 80 (for a total of 1U extra insulin needed), we would start with a microbolus of 0.5U, then 0.2U, then 0.1U, as long as minDelta was above expectedDelta.

If no (or insufficient) bolus is delivered when the meal is eaten, then when BG starts to rise ~15m later, we would shortly begin microbolusing up to 0.5U, until eventualBG gets down to target or the BG rise slows. Alternatively, if the low temp target expires or is canceled, we would also want to stop microbolusing and go back to temp basals if the maximum predicted BG gets down below about 160 (target + 60 or so).

This should make AMA much more effective at blunting post-prandial highs by getting insulin active sooner, but may actually result in less risk of severe hypos if the rig loses connectivity just before carb absorption stops and BG stops rising, because a long zero temp will already be set and will eventually cancel out all the extra bolus insulin if no further action is taken.

It is also worth noting that taking this approach would constitute a relaxation of the first safety design constraint of the original OpenAPS reference design, namely that the system cannot issue insulin boluses and only executes temp basals, to avoid the risk of a rig malfunction issuing a command repeatedly and bypassing maximum delivery limits. As already outlined, this microbolus approach would require that the command to be executed by the system be of the form "issue a 0.2U bolus to bring the reservoir volume down to 162.1U", and implemented in a way to guarantee a fresh reservoir volume check, a current pumphistory check, and a fresh bolusing status check before actually executing a bolus. Even with such safety checks, a relaxation of the original design constraint is only appropriate if we judge the system to be safer overall (for example due to improved walk-away hypo safety), limit microbolus operation to mealtimes when the user is fully aware of how the system is operating and prepared to intervene if necessary, and continue to observe the temp-basal-only constraint for overnight and unattended operation.

In addition to hypo safety, we also need to evaluate and test any microbolus algorithm for the possibility of post-prandial low BG due to excessive bolus delivery at mealtime, which could possibly result in a low BG event before all carbs are absorbed, or after carb absorption due to unexpected situations like overestimated carbs, post-meal activity, interrupted meals, etc. As dosing quantities would be determined by the AMA algorithm, which has been demonstrated effective at avoiding post-prandial lows, my main concern would be with a sharp initial meal rise followed by an early end to carb absorption. We would need to test that appropriate max basal settings and the ratios outlined above (30m worth of basal or 1/2 of insulinReq every 5m) are sufficient to prevent that outcome, and adjust them to deliver smaller microboluses over a longer time period if necessary to get outcomes more like we get with temp-basal-based AMA.

[sulkaharo]

Is there a pump event that could be used as a semaphore for bolusing to ensure no duplicate boluses are issued between rigs? Can we set the User Events? If we can read and write those, there could be logic where the loop would set a user event 10 seconds before the bolus and then before bolusing check that another loop hasn't also set the event.

[scottleibrand]

I'm not aware of anything that could be used more reliably than the reservoir and bolusing checks, but there could be. Given how long it takes to execute a bolus, and how quickly we can check reservoir volume and bolusing status, and the fact that you can't execute a bolus when another is already running, I don't think there's any way for multiple rigs to execute the same bolus, but we should definitely test that.

If we did want to set a semaphore, we'd ideally want to be able to somehow allow each rig to set a unique identifier, so they could tell the difference between one they set and one set by another rig.

[scottleibrand]

The "determine-supermicrobolus" command should output a supermicrobolus.json containing:

• The temp basal rate (0) and duration (30+ minutes) to set before delivering the microbolus (long enough to bring eventualBG back up to target if we deliver the bolus and carb absorption stops)
• The expected reservoir volume at which to deliver the microbolus (the reservoir volume from immediately before the last pumphistory run)
• The timestamp before which the microbolus needs to be sent (the timestamp of the next expected glucose reading)

After receiving new BG data (and enacting a temp recommended by determine-basal if necessary), the command / alias that enacts the supermicrobolus would then need to do the following (quitting out if any command fails):

• Delete supermicrobolus.json
• Refresh reservoir.json
• Refresh pumphistory.json
• Run determine-supermicrobolus
• Enact the recommended zero temp, if any (pass supermicrobolus.json to an openaps use pump set_temp_basal report)
• Read the currently running temp and verify it matches the recommended
• Read the pump reservoir volume and verify it is with 0.1U of the expected volume
• Read the pump status and verify it is not bolusing
• Verify that the supermicrobolus.json is less than 5 minutes old, and that the current time is prior to the timestamp by which the microbolus needs to be sent
• Administer the supermicrobolus (pass supermicrobolus.json to an openaps use pump bolus report)
• Delete supermicrobolus.json

[scottleibrand]

Per discussion with @sulkaharo we might want to do a pump model check and only allow SMB mode on pump models we've tested SMB on. We also need to examine the decocare bolus code and the mmeowlink radio code to make sure it doesn't do any automatic retries of bolus commands, as we'll want to do reservoir checks before doing a higher-level retry if a bolus attempt fails.

We'll also need to be very clear around messaging if we develop and release this, as supermicroboluses fundamentally change the safety model, and requires more thoughtful safety engineering to ensure we have sufficient safeguards in place to prevent any overdosing. One thought there would be to define oref0+SMB = oref1. It probably wouldn't make sense to make it an entirely separate code base, but for example we should probably make sure that any instructions for enabling SMB are kept completely separate from the oref0 docs and setup scripts.

[scottleibrand]

@tim2000s comment #261 (comment):

"One thing we can easily do using RileyLink and Loop is check the behaviour when consecutive bolus requests are made. Using the error logging we should be able to see the details of the rejects. Using Loop, I haven't seen re-requests on failed boluses. I like the idea of oref1 as a separator."

[scottleibrand]

This is now being developed under https://github.com/openaps/oref0/tree/smb

We've been running that branch for several weeks now, and it works well for our scenario. If anyone else wants to test it, please start with a pump that's not actually administering insulin, and let us know how it behaves.

[danamlewis]

(Repeating: if/when this becomes something tested more broadly, it will be an advanced feature that is disabled by default; documented clearly; and very clearly part of something like oref1 to help clarify the different guiding principles.)