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.
PumpEr
PeGy
- 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.
I like the split of responsibilities.
With that framework, we would probably want to make oref0 issue high-temps much shorter than 30m as a further safety enhancement. We could in fact make them all run for 5m, which effectively means oref0 would be deciding the size of each mini-bolus independently, and waiting for a new BG reading to decide whether to send anothe one. That way oref0 could more quickly deliver small amounts of insulin, but larger amounts would still be rate-limited as a safety check in case BG starts dropping.
So by specifying which pump you are using on configuring openAPS, the operating mode is selected for oref0? That seems like a reasonable approach to take.
If oref0 does this then perhaps it removes the need for PumpEr and you simply operate the control framework and protocol translation in PeGy.
I guess it comes down to how much you want to modify the function of oref0!
Yeah, that sounds about right. I don't mind making these kinds of modifications to make oref0 a bit more pump-agnostic, especially if it makes things safer for a larger number of users who will be able to start using OpenAPS as we add compatibility with more pumps.
I guess that implementing this will also open up the possibility of using the newer "old style" Medtronic pumps like the 530G with openAPS.
This would also allow OpenAPS to support the Animas Ping, which can't do temp basal remotely.
This all sounds great. Especially like the sound of the Ping, using xDrip to capture Dexcom data and remote mini-bolus.
Has there been any movement on this? Very eager to get my Medtronic 530G working on OpenAPS
No, not yet. I’m not sure anyone has been working on the 530G to enable remote bolus programmatically, either.