The insulin only fully closed loop – as good at managing my diabetes as I am…?

It’s now been 12 months since I embarked on the intention of delivering an insulin-only closed loop using AndroidAPS. It’s certainly been an adventure and one that I am not the only person to embark on, with others also attempting to do it, with different approaches and outcomes in results.

What’s been very apparent has been that the differences between people affect the outcomes, whatever approach you take, and those differences encompass both physiology and lifestyle. Amongst all of this, I’ve also worked on the DynamicISF model, which has become core to the work I’ve done with Boost. If you follow this sphere of the world, you’ll have seen various approaches discussed on the AndroidAPS Facebook group, as well as David Burren discussing what he’s managed within AndroidAPS with some minor modifications. I also wrote about the first six months of this experiment here. This is an overview of the last six months or so, with an algorithm that has seen very few tweaks in that period.

Years of experience with oref1 in both OpenAPS and AndroidAPS forms have taught me that there is no way that on its own, I could really have a no-bolus closed loop work, and similarly, 30-odd years with Humalog and Novorapid, and then latterly, Fiasp, also demonstrated that Lyumjev was going to be the only real option on the block when it came to getting anywhere near a closed loop. 

I’ll discuss some of the challenges that it has presented shortly, but firstly, let’s take a look at the results.

Outcomes from using a non-mealtime intervention closed loop

The data using the non-intervention loop runs from October 2021 to the end of March 2022, and is compared to 1st October 2020 to 28th February 2021, as that’s the last time I wasn’t tinkering with the code to try and get some sort of non-intervention closed loop going. Looking back at that data was more revealing than I anticipated. It’s worth noting that my food strategy is to eat anything and everything. There is no low carb going on here. It’s typically a standard diet.

Additionally, I’ve used the traditional “Time in Range” (TIR) measure of 70-180mg/dl (3.9-10mmol/l), as well as something that’s sometimes called “Time in Normal Range” (TINR) which is 65-144mg/dl (3.6-8.0mmol/l), plus the AGP graphs for the time periods to provide a level of comparison.

Standard Time in Range

First up, the consensus “Time in Range” data. Unsurprisingly, given that the “closed loop” model is entirely post prandial insulin delivery, the time above range was higher in this period. What I wasn’t expecting to see was that my time below image in the five months prior to using any form of tinkered code was greater than the past six months with the modified code. 

Unsurprisingly, the time above range is increased, but that’s expected with post-prandial insulin dosing. Perhaps less obvious is that the GVI value was almost the same, even though the PGS score was around 50% higher.

Both these result sets run over the Christmas period, so it’s likely that they have very similar behaviours involved from both an eating and an activity perspective. 

Time in Normal Range

This measure looks at a slightly tighter range than the consensus time in range score, and in theory is roughly the range in which those without diabetic tendencies would see their glucose levels fluctuate. The time period is the same as the previous set.

This is where we start to see the greater differences between the two datasets. There is a significant difference between the time above range in this case (30.6% vs 21.7%) and resultant reduction in time in range. In the post-prandial dosing case, we’re effectively seeing a 12% reduction in time in normal range.  That’s not to say that this is necessarily an enormous issue, but for some people this wouldn’t be acceptable. The traditional longer term measurement (estimated HbA1c) still looks pretty good in both cases though.

Ambulatory Glucose Profile (AGP)

The AGP is perhaps where we see the real differences being revealed in this process. During waking hours, it is far more obvious what the effects of the post-prandial insulin dosing are. Overall, the bands are wider, and the higher range is obviously higher. 

With all that said, the obvious food impact pattern during the day is clear in both the cases shown here.  

What do you make of the results?

This demonstrates that it’s possible to get similar results to use of an open source hybrid closed loop with modified code taking mealtimes out of the equation. It was important to have the comparator period, as it raises questions of my handling of my levels, even with the loop in place. 

One of the big spectors of this type of data is the amount of time spent below range, and as David Burren mentioned in his article referenced at the start of this one, the data we get from CGM does have to come with caveats. Not least of those is what of those low values are real? I can look at data from just last night (not included in this analysis) and see compression lows that account for 4.5% of the readings over 24 hours of data. Once compression low every other night can result in significant additional lTBR percentages that just aren’t real… As a result, I’m always a little sceptical of the Time Below Range data that we have. 

Having said that, I think that in both cases, the time below range is a little too high, and we’ll discuss that in the challenges section.

Otherwise, I’m reasonably happy with the outcomes here. The overall numbers show are okay, and for not having to think about Diabetes particularly, that’s a good set of results. 80.8% conesnus Time in Range is not a bad place to be.

The challenges of the insulin only closed loop

As I’ve mentioned, to make this work, I’ve had to adapt the oref1 code to allow it to deliver more insulin earlier in the glucose level climbing cycle. This has driven some interesting behaviours that perhaps aren’t immediately obvious. All of the same issues that I observed in the write up in October remain as challenges when using a system like this.

Exercise

I’m highlighting exercise again, as this has been the one area that I’ve noted needs the most intervention. When you are bolusing for meals or partially bolusing for meals,  there’s an automatic break in the process of what you’re doing where you can “manage” activity, and reduce your insulin delivery to manage it. When you are not bothering, because you don’t need to, there’s a tendency to forget to ddo anything. In the context of this model, anything would be setting a temp target to reduce insulin delivery (as even the best systems are not yet prescient and can’t automatically determine when you’re going to do exercise in the future).

As a result, while there’s no management required around meals, exercise still needs a little forethought and intervention in most cases. I highlighted this issue in the previous write up of this process, back in October.

Fast carbs and Beer

The other item that I’ve found a little more problematic is fast carbs in small amounts and beer. Both are troublesome because they have a tendency to have a very rapid onset but nothing left when done, so that although there may be a requirement for insulin delivery, it’s often not as much as the system needs. To combat this I’ve found that a short (45 mins or so) high temp target works quite well, which I can deliver from an IFTT button on my phone front page.

Thoughts on deliberate over-delivery and management

As I had mentioned in the October article, the early delivery of insulin is important for me to manage post-prandial highs. With an insulin only system, the challenge is how much insulin to deliver. There is no safety net. This highlights where the benefits of a bi-hormonal system may lie. 

It would be extremely helpful to be able to deliver an oversize insulin dose when glucose levels are detected to be rising, regardless of worrying about a resultant low.  For most of us, earlier insulin delivery is better, and an “optimistic” delivery model with a way to back out would make a lot of sense. With the tools we have right now in the open source world, while insulin delivery is straightforward, pver-delivery very much isn’t, and results in the need to eat more fast acting carbohydrate. Having a glucagon response from an algorithm would, in theory, allow over-delivery as it would then allow a response when levels start to drop. 

At this point in time, the only way that I can see to do this would be to use two small patch pumps (Omnipod or Medtrum) to deliver the two different hormones. As it stands right now, in the UK at least, the only hormonal option for the glucagon delivery is Ogluo. This is currently delivered in 1mg pens at a cost of £75 per pen. As such, it’s not really a useable option for day to day use with a bi-hormonal system, unless they are diluted (and before anyone asks, Ogluo is the same product as Gvoke in the US, and the Zegalogue product runs at 0.6mg per pen, so they aren’t really options either). 

Individual variation

One of the commonly seen things across the open source world is people reporting the outcomes of the n=1 experiments they are doing on themselves, using various techniques. What you’ll see from that is that one size very clearly doesn’t fit all. Some people can use oref1 with DynamicISF and get fully closed loop around meals perfectly effectively. Others can do it with a tuned profile. Some of us can’t. The old truism that your diabetes may vary was never more obvious than in this area. With this in mind, you can see the challenges that commercial system face in delivering “no meal intervention” models. They are not simple. 

Intervention free?

As I’ve previously mentioned when writing about this topic, these systems are still not intervention free. As I’ve mentioned again here, exercise requires work, alongside fast carbs and beer, as does some of the set-up of an open source AID system. But it’s getting much closer to it, inch-by-inch. And the easier it is to get good enough with less involvement, the better. Until we can remove the need for cannulas and refills, and no liver focus on the insulin delivery, this is likely to be the direction of travel for the foreseeable future. For those people who don’t remember mealtime management, this has to be the way forward.

Will you continue with this?

I think the numbers speak for themselves. While I’m not getting 90+% time in range, around 81% with as little effort as possible is really not something that I can complain too much about. And recent tweaks to the Boost code that have recently been pushed should help with those pesky low numbers. As for non-blood glucose measurements of my health and wellbeing? Well the last eye screening came back with background retinopathy that I’ve had now for 15 years. No sign of recurrence of the maculopathy from a few years back.

I think the biggest benefit of this approach to open source insulin delivery is the extension of the feeling that the algorithm’s got your back. Years ago, when I started to use OpenAPS, one of the things that I always found to be the greatest peace of mind was the feeling that even if I forgot things or that the world catches up with you and you end up doing something else, there was always something there in the background, working to keep your diabetes on track. I think this takes it further. 

It’s no longer “It’s got your back”, it’s now a case of “it’s doing most of it for you”. That’s an even more freeing place to be in the world of diabetes management. 

 

---

If you’re interested in trying Boost out, feel free to get in touch to find out more.