Medtronic’s 670G and #OpenAPS/#Loop – what can we glean from the user manual

The Medtronic 670G is undertaking a slow-paced roll out in the US as Medtronic tries to ensure a slow and steady, well trained delivery model is in place, ensuring new users understand how it works and what’s going on.

Here in Europe, it’s not yet made the EMA list of approved medical devices, so we are still waiting with anticipation, and probably will be for some time.

But as a pre-cursor, and without access to the device itself, what can we do to satiate our curiosity? Well… Quite a lot as it seems. The guys at Medtronic have released the user manual, as you’d expect, and we can at least go there to see what’s been publicly stated for users in their guidance and compare it to what we know of OpenAPS and Loop.

If anyone was wondering, all the Medtronic guides can be found on the Medtronic web page here: https://www.medtronicdiabetes.com/download-library

And the main user guide is here: https://www.medtronicdiabetes.com/sites/default/files/library/download-library/user-guides/MiniMed%20670G%20System%20User%20Guide.pdf

Then we flick to somewhere around page 230 to start reading about the catchily titled “Auto Mode”.

The first thing we learn is that before we can enable Auto mode, the pump has to have been operating for 48 hours from start up to learn about a user’s dosing. Reading between the lines here, it suggests that the algorithm in use in the 670G is using some level of machine learning to understand dosing, however it also mentions that this doesn’t need to be with a sensor, so I can only assume it is looking at basal rates, meal carbs and wizard calculated bolus delivery. As I don’t have one to hand to play with, I speculate that it uses some of this information to establish patterns, but it’s hard to tell why this is operating like this without seeing output.

It also comes with this warning:

Which serves as a good reminder that certain implementations of machine learning have some shortfalls.

This differs from the vanilla OpenAPS flavour in that OpenAPS simply pulls basal rate profile and settings data from the pump, while you enter the data yourself in Loop. If you use Autotune with OpenAPS and muck around with insulin or carbs, then technically you might see something similar.

For me it’s slightly concerning that inadvertent button presses could interfere with the safe functioning of a hybrid closed loop system.

Once we’re past this hurdle, there is a checklist that pops up telling us what is needed before Auto mode will engage.

Most of these are sensible precursors, and bearing mind that this system is designed to be used by anyone, the checks make sense. Comparing this to OpenAPS or Loop, obviously some of the checks don’t compare, e.g. A blood glucose test is not required in the 12 mins before turning it on, but the loop won’t function on OpenAPS or Loop if some of these things are operating. The biggest difference here is that you can start using OpenAPS and Loop with a temp basal rate set.

In the context of a system that the FDA says can be used by anyone, these all make sense.

So that’s pre “Auto Mode”. What happens when we engage it?

Auto Mode

There appear to be a number of concepts linked to Auto Mode. These are:

• Auto Basal
• Safe Basal
• Block mode
• Temp Target
• Auto Mode Bolus

We’ll look at each of these in turn. But first, let’s summarise Auto Mode. As Medtronic say:

Auto Mode is an insulin delivery feature designed to help people on intensive insulin therapy to achieve better control 24 hours a day. This is achieved by automatically controlling basal insulin delivery to regulate glucose levels to a target sensor glucose (SG) amount.

The target level is stated as being 120 mg/dl, or roughly 6.6mmol/l in old money. This equates to an Hba1C of 6.5mmol/mol and I assume is a level that is considered “safe” by Medtronic’s scientists. Given what we’ve seen with OpenAPS I suggest it also means that very few people using the 670G will achieve the 6.5% Hba1C target we have in the UK from NICE. Make of that what you will…

Another point with Auto mode is the concept of “Auto Mode Active Insulin”.

It takes 5 hours for the Auto Mode Active Insulin to be updated. This update time happens under the following conditions:

• when your pump is turned on the first time
• following a complete pump reset caused by a loss of power or a software error
• following a Suspend lasting 4 hours or longer

Once the Active Insulin is updated, it will be valid unless one of the conditions above happens, which will restart the update period. Auto Mode will then be locked out for another 5 hours.

So… whenever you change the battery, you are locked out of Auto for five hours. It would have been nice for the system to have some memory of what happened immediately beforehand, but never mind…

We also know that the low suspend functions are disabled in Auto Mode, which makes sense as this should be happening anyway.

Auto Basal

This is simply the automated delivery of Basal based on the sensor glucose values. How the system arrives at its Basal determinations is not published in the user guide, unlike Loop and OpenAPS where it is freely available and I assume this is because this is something that Medtronic considers important competitive IP. Personally I’d quite like to understand what decisions the black box is making. But that’s just a spot of feedback from me!

Safe Basal

In 670-land, this is what the pump reverts to when there is some form of issue that needs intervention, such as sensor glucose value errors, blood glucose levels being too far away from the sensor values, flow rates being too high or too low for too long and also when it thinks the sensor is not reading at the right level. The latter is an interesting one and I assume that all the testing that has been done has tuned this to keep interference to a minimum. There is a helpful table on page 238 of the manual that goes into detail on all of these.

After 90 minutes in “Safe Basal”, if the issue is not resolved, the pump drops back to manual.

Safe Basal is essentially a half-way house between dropping back to a manual mode using pre-programmed basal rates and a full closed loop. Within OpenAPS you could liken it to programming the pump with the most recent “Autotune” values automatically as a different basal profile which would be used when something in the loop breaks, which isn’t a current function.

It’s not clear to me what the benefit of “safe basal” is over using the pre-programmed pump profiles, other than an anticipation that users are extremely unlikely to change their basal programs once they are used to using Auto mode. That could be an interesting one for both users and HCPs to monitor.

Block Mode

This is very simple and allows the pump to not allow settings changes or boluses from the pump when in auto mode. I can see how this might be useful when the system is used with those with diminished responsibility or children.

Temp Target

Unlike OpenAPS, which allows temp targets at pretty much any level, there is only one for the 670G. You can set a temp target of 150mg/dl for exercise, or other times when you want a higher target. This defaults for two hours, but can be set to anything between 30 mins and 12 hours. Whilst it will be helpful, it is a little inflexible. Similarly, Loop has a similar facility that you can set to whichever you want.

 Auto Mode Bolus

Medtronic have very clearly described this as a separate feature to standard bolusing. As they say in the documentation:

Delivering a bolus in Auto Mode is similar to delivering a bolus using the Bolus Wizard feature in Manual Mode. The Bolus feature in Auto Mode requires you to enter either carbs or a BG value. You may also choose to enter both. Auto Mode then calculates the bolus amount needed to cover the meal or correction. Once you confirm this amount, Auto Mode will deliver the bolus.

The document clearly states that only Normal boluses will be calculated by Auto Bolus mode.

OpenAPS doesn’t have bolus functionality, so this is where we need to look at Loop for a comparison.

In OpenAPS, you have the Advanced Meal Assist paradigm whereby you tell it your carbs, give a bolus and let the algorithm smooth out your post prandial glucose levels. There may be functionality similar to this contained within the 670G algorithms, however if there is, it is not clearly discussed or on display.

In Loop, and it would appear in the 670G, you tell it carbs, and it tells you the bolus based on Active insulin and SGV. In Loop you have the ability to modify this number if you choose, however this doesn’t appear to be the case in the 670G.

Another thing to bear in mind is that there is no way to handle a manual injected bolus within Auto mode, indeed it is warned against:

I guess you could do the same trick as we use in Loop and OpenAPS, which would be to drop into manual mode and do a bolus of the same amount as you had injected, then go back to Auto, but this is not advised in the documents, and may result in the 5 hour wait.

If a blood glucose (note – NOT a sensor glucose value) is received that is higher than 150 mg/dl, the 670G will recommend a correction bolus. This is different from the Loop behaviour, where if you tap on the Bolus button, if sensor glucose values show high, it will recommend a bolus.

In OpenAPS, a feature is currently in development that will set a lower temp target when the current sensor glucose value is higher than a threshold level.

Basically, if you have a “High glucose” warning set on the 670G, you will always need to confirm it with a blood test in order to have the system do anything other than High TBR.

Alerts

As with the current 640G in Europe, you can disable alerts, and similarly with both Loop and OpenAPS, you have similar capabilities, but there are some alerts that can never be silenced:

Note: The following alerts are never silenced:

• Low SG XX mg/dL (XX represents 50 mg/dL or below)
• Auto Mode Exit High SG
• Auto Mode Exit
• Auto Mode Off

It appears that if Auto Mode is left, regardless of whether you want it, you will get a warning, and equally with a low glucose level. I wouldn’t expect these to happen too frequently, so they don’t seem too unreasonable. Only time and use will tell if they are.

What’s also an interesting footnote in what amounts to the appendices in the document is the table showing the number of alerts that didn’t sound below a preset glucose level:

The table shows how frequently the alarms did not sound within 30 and 15 mins of the glucose level falling below (or expecting to fall below in the case of predictive) the preset threshold. They are not terribly reassuring.

Overall Impressions from the user guide?

Reading through this document, it’s clear that this is aimed at a wide audience. But then that’s what we’d expect from a commercial hybrid closed loop, and that’s very much what this offers. It still requires a fairly significant amount of user interaction, but then the same can be said for the Open Source alternatives.

It has the major benefit of being an all in one device. There isn’t any need to carry anything other than the pump. For many this will be a huge benefit. Obviously, it doesn’t allow tinkering by design, and more frustratingly for some of us, there’s no indication anywhere in the documentation of what the algorithm is doing. That’s something that I’d certainly like to see. Both OpenAPS and to a lesser extent, Loop have openly accessible details. Granted that most people probably won’t care, but still…

Looking at it purely from a user manual basis with the advantage of more than six month’s experience of hybrid closed loop use, this doesn’t look like a bad device and similarities with the early iterations of OpenAPS can be identified. I have little doubt that for those who want access to a hybrid closed loop system without having to build it themselves and for whom the upkeep of a DIY approach is too much overhead, this is the start of a great road.

For me, the static, unchangeable target would be an issue. I run my loop at a target of 4.8mmol/l, and achieve an average of around 6.0mmol/l. At 6.6mmol/l I wouldn’t be hitting the NICE target Hba1C. Although a smart user can probably identify a fairly simple and reasonably safe way around this minor issue, I’m not going to go into too much detail, other than to suggest it should be possible.

My one reservation, and it’s really a challenge for all the companies producing these devices, along with the FDA, is are they going to innovate and update? As long as the future projects coming from iLet, Bigfoot and OmniPod, plus the European projects from Cellnovo with Diabeloop and Typezero, come to fruition, I believe that Medtronic will need to innovate for fear of losing a market, however, given the share price issues facing the likes of T-Slim, if this takes too much time, will we see anything new?

For me, for now, whilst I’d like to trial a 670G when it becomes available and see how well it did what it said on the tin (and I can see one or two occasions where a waterproof all in one would be handy), it’s unlikely that I’d change from OpenAPS to this commercial offering in the near future and given likely availability in the UK, potentially, ever….!