As I’ve discussed in previous topics, I’ve been running with Tim Omer’s HAPP adaptation of OpenAPS, providing open loop APS functionality on a mobile phone.
I’ve also recently moved on to a Medtronic 640G pump, which as far as I can tell, doesn’t provide the capabilities for remote temporary basal instructions. I need to do some bluetooth packet sniffing to see what the comms between the Countour NextLink and pump look like, but given this as a likely restriction, I started to wonder how one might safely use the 640G with Open APS, given this restriction.
The recent work that has been done by Lennart to allow connectivity without the use of CareLink set me thinking that we are probably closer than ever on this one, so I’ve set a few thoughts out below regarding an approach that I consider might work, given the over-riding requirement for the system to be safe.
There is no ability to manage temporary basals remotely
The core aspect of OpenAPS is that it is able to raise and lower basal rates on the pump in line with changing blood glucose levels. This is a key aspect of safety. It would appear that this functionality is not available on the 640G, which only has the ability to deliver a remote bolus, that is either a manually configured amount as a standard bolus, or a preset amount as a choice of Dual or Square wave on the pump.
So how do we create something APS like with this limitation?
The question for me is what we regard as safe, and this is open for debate. It strikes me that there are likely to be two options here.
Run a lower basal setting that ensures the risk of DKA is lower but increases the risk of higher blood glucose levels should the APS component fail – although CGM monitoring should alarm for this.
Use a hybrid system, with the 640G Smartguard responsible for dropping insulin levels when it thinks lows are likely and running a normal basal pattern on the pump.
With either of these, there are benefits and limitations. The risk of higher blood glucose in a failure state is always going to raise eyebrows, however, providing safety management through other systems is potentially another mechanism available, and is something that is used in various other applications.
The question ultimately has to be what the individual will accept as their level of redundant “recovery” options. If your pump fails now, you have little chance of finding out till you feel terrible, unless you are using CGM, which is why I postulate it as the back-up alerting mechanism.
Ok, so no temporary basal. How do we manage the uptick in basal then?
Then there is also the question about how to apply temporary basal upticks. My observations from HAPP are that it tends to apply a model with standardised basal upticks, e.g. 2x, 3x and 4x basal rate plus the splits of these up to a maximum observed of 4.5x. I’ve never seen a 5x, for example. It also only ever applies this over 30 mins. Bearing this in mind, it gives a couple of options regarding how we might deliver a basal uptick:
Deliver multiple small boluses over a time period – this would require the APS pump controller to be able to act like a pump, effectively splitting the calculated basal amount into time period increments and delivering multiple manual boluses – this allows adjustment of the temporary basal before the initial time is up
Prescribe a set of preset Square Wave boluses of 30 min duration and use these to matched increments, i.e. 1.5x up to 4.5x, selecting the appropriate Square wave given the APS calculation – based on reviewing the functionality immediately apparent on the NextLink stick, there doesn’t appear to be a remote “cancel bolus” option, so further digging into the protocol needs to be undertaken to determine whether this is a feasible option.
Given what I can see of the remote operation so far, I’d suggest that the first of these two options is by far the most felxible and also the safest.
Based on this thoughtstream, taking the Lennart work and extending it, the question seems to be “what to implement”?
Given the over-riding drive for safety during operation, it would seem that the way to go about delivering this would be to use the onboard glucose monitoring with Smartguard for Hypo protection, use this feed as the driver for increasing insulin as necessary and only tick up using micro-bolusing.
The back-up basal pattern is something that can be left to the user to implement based on their own appetite for risk.
I’m not sure what other work has been done in respect to using the 640G with Open APS and its clones, but, time permitting, I think this is the approach that I would consider taking to get a form of integration. There’s a lot of work to be done built on top of Lennart’s though, in order to get to that stage, and feedback on these thoughts is very welcome!
Given the way OpenAPS recalculates insulin required every run, it is not necessary in the microbolus scenario to "remember" how much insulin to give in the future. We just need to calculate, each time the algorithm runs, how much to give now. The upper limit on that should be equivalent to the maximum safe basal rate, which would translate to something like 0.2U every 5m if your max_basal is 4U/hr or so and your regular basal is 1U/hr or so.
We also need to figure out how Smartguard works after administering microbolus: there may be undesired behavior there, and therefore we may need to be more conservative in high-temping, since we can't reduce basal if BG starts to drop with too much IOB.
According to the guys at Medtronic, the 640G delivers basal in increments rounded down to 0.025u for 1u/hr or less and 0.05 u for more than 1u/hr, and manual boluses can be given at 0.05u. The pump basically adjusts the frequency of increment based on the basal dosage. For applying a temp basal via micro-bolus, I guess this is the approach that we'd need to take, assessing the current glucose level, then microbolusing at the required increment for the basal rate. THis frequent use of the bluetooth connection may cause battery issues though…
Smartguard appears to look at IOB as part of the calculation in its predictive low calculation, so with this data in the pump, it should, in theory, not cause any issues with Smartguard. Looking at the data output from the PILGRIM study, this appears to be the case. As ever, testing would be the key there though.
Good info, thanks. The IOB-aware algorithm sounds promising: look forward to some confirmatory testing.
I actually wouldn't bother to try to do really frequent tiny microboluses. From everything I've seen about insulin activity, and from years of experience with running an OpenAPS-type system, bursty insulin dosing, where you deliver up to 0.5U over some 5m periods and absolutely nothing over others tends to get the exact same outcomes as if you delivered the insulin more smoothly as tiny microboluses. So while we can rely on the pump to deliver the normal basal insulin in tiny microboluses, we can use larger ones (0.1U-0.3U every 5m or so as needed) for additional correction. This will in any event be far smoother than the way humans usually do it, where a typical correction is >1U for adults. I'm not sure how quickly the Contour NextLink can pull pump history data, but if it's anything like the older OpenAPS-compatible pumps, you won't likely end up running your loop more than once every few minutes anyway, so "mini-boluses" as we might call them will probably be the most practical solution.
Any update on this, as I’ve just got a Medtronic 640G, and am very interested in running an open/closed loop system. I’ve been looking to source one of the older Medtronic pumps (compatible with OpenAPS/Loop), but have been unsuccessful.
It’s highly unlikely that this will happen. The work to crack the Roche Combo and Omnipod has really made steps forward so it’s more likely that these will be used in future iterations, rather than the 640G.