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.
That all makes sense, and is consistent with what I've seen from HAPP and from Sugar Surfing!
Enjoyed reading the post – thanks Tim – and the replies. Unfortunately I don't think smartguard is IOB aware. But I don't have data with large IOB and anyway I'd love to be proved wrong! http://littlet1d.blogspot.com/2015/07/smartguard-how-it-probably-works.html?m=1 We can talk about it later in London Tim 🙂
I’m diabetic type1 can i build the openaps with a medtronic pump 640g and a cgm freestyle libre ?
Hi Christophe,
With the right selection of tools, you could use a Libre as a CGM, but you’d have to build the solution yourself. You won’t be able to use a 640G just yet though as this hasn’t yet been made to work.
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.
So the Medtronic pump suspends when it detects the CGM data from a Guardian transmitter. I assume this is Bluetooth and not a custom protocol. But that aside why couldnt you emulate what a Guardian link transmitter would send and if you had the data (nightscout for me) could you send that CGM data to the pump and essentially would force the pump to suspend on low. We have a G5 and nightscout site plus the awesome uploaded from Scott to keep us informed. I know to suspend my daughters pump if I’m awake as the data is there for me.
Sadly it’s not Bluetooth, it’s Zigbee. In addition, no-one has decoded the Medtronic Guardian comms. So while in theory you could do it, there are some implementation challenges and also the philosophical question of whether interfering with a golden source of data is wise to get the action you want. I’d argue that it’s not.
Hi All,
I’ve been on the 640G for almost 4 years and am due a replacement. The 670G is the logical step with it’s advanced “hybrid” loop system, using the Guardian sensors, however, I’ve been open looping using either the Eversense CGM or Dexcom G6 and pushing to my Android Watch when training and running a marathon. I really don’t want to do without the data on my watch for exercise and also really want to try closed looping having seen amazing things!
Has anybody figured this out on the 640G as if not i’d really have to change to a different pump able to Close Loop.
Hoping somebody with way more knowledge than me has worked this out 🙂
Cheers
I was thinking the same way. But also was thinking to add hardware to press the buttons which must be slim and does the job and gets controlled by bluetooth!