Working from the hypothesis that we can’t set remote temporary basal rates with the 640G (which is yet to be confirmed, but I suspect will be the case), and thinking along the lines that we will be required to have the app manage the mini-boluses required to mimic the TBR model of a pump, how might we implement this, and what are the safety concerns co-incident with it?
After speaking to Colin, and Matt of LittleT1D last night, and of course, Scott’s comments on the original post, I propose a structure that builds on the existing openAPS model, but includes a variation to implement a level of safety checking.
Essentially the Open APS model is the APS brain component with a separate pump adapter. In the context of a pump where the TBR safety net isn’t available, this architecture becomes very helpful.
The oref0 algorithm is still the brain of the system and still issues a TBR instruction, but in this case the 640G adapter needs to be implemented slightly differently.
As we are unable to issue a single instruction to initiate or cancel a TBR, and instead have to calculate and issue a remote manual bolus, we need to add in an extra layer of security. With openAPS issuing a TBR instruction, the gateway now needs to emulate the pump TBR algorithm and calculate the boluses required and the increments of time over which they are delivered.
This is relatively straightforward and at calculation point, the TBR instruction from oref0 would be taken in by the adapter, the units per hour divided by thirteen to give the units per five minutes, and then bolus of this number of units would be delivered every five minutes, starting at t=0 and finishing with a final bolus to be completed at t=30.
Whether these additional boluses are sent depends on the following next instruction from oref0. If it cancels or changes the TBR, then the next bolus will change.
But this raises a level of concern that comes with using boluses rather than a TBR instruction. What if the algo goes wrong and tries to issue multiple consecutive boluses in a short period of time? That way, disaster lies.
I think the answer to this is to separate the pump adpater into two distinct components with different responsibilities. The “pump emulator” component, that we’ll call “PumpEr” and the “Pump Gateway” component that we#’ll call “PeGy”. This way we can separate the responsibilities and hopefully mitigate the risk of the infinite loop bolus.
- Bolus Throttle: hard coded into this component is the check that bolus requests are being received no more frequently than every four minutes and fifty nine seconds. If PumpEr gets into an infinite loop and starts trying to issue multiple boluses in quick succession, PeGy shuts access to the pump off and alarms.
- Max Bolus size: typically, the TBR is expressed as a percentage of the pre-programmed basal rate, although with Medtronic devices this is often done as a rate. The maximum size of a TBR mini-bolus will be a setting that the user can configure. This will be purveyed to PumpEr and PeGy, but in the event of the calculation algorithm going awry and over-riding that maximum, PeGy will not accept the bolus increment, disables the pump access and alarms.
- Maximum IOB: PeGy will use the Maximum IOB value that is set for oref0 to limit the total amount of insulin that can be delivered through to the pump. As before, if this becomes exceeded, access is shut off and there is an alarm.