The insulin-only full closed loop. An n=1 experiment.

When Lyumjev first appeared in the research ether, I wrote an article about how, in theory at least, it should enable insulin only, full closed loop systems. The question was, with the open source tools available, could that be achieved?

With Diabetes Awareness month here, now seems like a reasonable time to discuss what I’ve seen and how it worked.

 

Other closed loop experiments

A year ago now, I posted an observational study from someone that has made a number of tweaks to AndroidAPS and was running fully closed loop with Lyumjev. Their outcomes were also remarkably good, seeing very high numbers for time in range. Since then, we’ve also seen David Burren report his success with a fully closed loop, again tweaking and tuning oref1 in AndroidAPS, but this time using other insulins. Back in May, I posed the question of myself, with a small set of data.

Clearly then, with an insulin that works with you, and some clever tuning and automation, a fully closed loop is possible.

But what when the insulins you have available don’t work so well for you? You change insulin and try again. After finding that Lyumjev u100 wasn’t ideal for me in a pump, I managed to get hold of the u200 version, which has proven to be far less problematic.

Tweaking the algorithm

With that in hand it was possible to start to make tweaks to the oref1 algorithm in order to try and get a “no intervention” system operating for me. And I called it the “Boost” algorithm.

Essentially, what I was trying to do was identify when glucose rises were taking place and then safely bolus extra insulin to counter rises. Alongside this, there have been others that have been attempting to do similar, if slightly different approaches relating to not announcing meals.

I’m not going into the details of the changes I’ve made here. Instead I’m reporting the outcomes and challenges of attempting an insulin-only full closed loop, from my perspective.

And if that’s a TL;DR for you, then here are the headlines:

• Time in Range (3.9-10mmol/l) of 81.2%;

• Time Below Range (TBR) of 5.6%

That’s not a bad outcome for minimal intervention over a four month period from 1st July to 31st October. I think the TBR is too high though. Based on this, ss an insulin only full closed loop possible? Well you can get extremely close.

Read on to find out more.

The process

The data presented here is 95% generated from use of the Boost algorithm. There are short periods of use of other low-intervention algorithms, but for the most part, this is the outcome from making as little intervention as possible. That’s not to say there was no intervention. There have been times where I’ve needed to override the algorithm. Those were mainly down to physical issues, but that will be discussed in the challenges section.

Getting the algorithm to a place where I felt that it was able to function effectively took a little time, but the model that I’ve been using for the period described here has been pretty static.

At a basic level, it builds off oref1 and attempts to replicate a meal bolus as soon as a meal is detected, increase insulin while levels are climbing and to limit insulin once glucose levels start to flatten off. It’s one of many approaches that can be taken, and the one that made sense to me as I tried to reuse the core of the algorithm.

If anyone wishes to discuss the approach, I’m happy to discuss it offline.

Outcomes

Here are the graphs for the period of data capture…

As it goes that’s not too bad. 81.2% in range with as little intervention as possible is a quite amazing number. What’s perhaps not so amazing is the time below range, which is a little higher than I’d like and that’s something to be highlighted in the challenges.

How does this look on an AGP?

It’s not, perhaps the prettiest. The historically very tight lines that I’ve had with a hybrid closed loop are considerably wider, and this is reflected in both TIR and GVI. It’s very obvious that once you start eating, the effects of post-prandial insulin delivery are clear.

Would large amounts of time tuning this have made much of a difference or are there other factors at play? We’ll discuss that later.

Challenges

There are a few challenges that I found with trying to use a system in a fully closed loop. These are split into how insulin and glucose interact, the insulin involved, what you can safely do in an algorithm and physiological effects. We’ll start with the first of these.

How do insulin and glucose interact?

The main observation that I had from running with this set up was that there was a similar pattern to most meals. I’d eat, there’s be a period of no change on glucose levels and then they’d start to accelerate upwards.

This would trigger the algorithm to bolus, but even though it was set up to recognise a rise earlier than the standard model and do something about it, even with Lyumjev, this was a little late.

The end result was a higher than comfortable glucose level, and often a challenge to bring levels back down. What was perhaps more challenging was that the rate of increase was similar, regardless of the food eaten. It was purely the delay to the rise starting that seemed to vary. This issue is reflected in the AGP presented, and there is very little that can be done to tame it if you’re reliant on glucose level changes to drive dosing behaviour.

The result for me was that post-prandial glucose levels were always higher than is recommended.

The insulin involved

I’ve previously mentioned that I’d had problems with Lyumjev u100 and fewer with the u200 version. With that said, my interaction with it wasn’t and isn’t perfect.

There are two observations that stand out.

Effectiveness and site interaction.

Others have discussed the life of a site when using Lyumjev (and I’ve also discussed it in relation to Fiasp). For me, the excipients in these insulins seem to precipitate a faster loss of cannula site then the older analogues. And for me it’s not a slow degradation. For two days, the site will work just fine, and on the third, this either continues or it stops entirely.

But I only tend to find out about the ones that have given up the ghost after I’ve eaten and once the algorithm has dosed a fairly large amount of insulin, to seemingly no effect.

My guess is that it’s the volume of insulin going through the site that drives the failure rather than time specifically, however, I need to review the data to determine if this is the driver.

This issue obviously generates significant variability during use and so far, hasn’t always seemed predictable.

Effectiveness at higher glucose levels.

Whilst adjustments have been made to AAPS that allow it to deliver more insulin at higher glucose levels, there does appear to be more of an inverse relationship between Lyumjev effectiveness at high levels and dose required to return to target.

Again, this is purely observational and anecdotal and requires a dig into the data to determine what was really happening and whether it was linked to the ongoing effect of food or was simply “how it works”.

Algorithm safety

If you’re trying to write an algorithm that identifies when a glucose rise is attributed to food and dose effectively for it whilst at the same time acting in a safe manner, you often find yourself in an awkward juxtaposition. The challenges come around the edges.

Dosing safe amounts of insulin

While there is a need to apply insulin in response to the rise, you also need to make sure that you’re not applying too much insulin and overdosing, in case the rise isn’t driven by a large amount of carbs. oref1 does this by limiting the amount of insulin that can be delivered in a single shot and by requiring multiple increases in glucose that show a deviation from the expected trajectory, effectively delivering the dose over a period of time until the deviations start to shrink.

If we look at the speed of insulin action, even though Lyumjev is faster, it’s not so fast that it’s having an effect within five or ten minutes. Glucose levels therefore climb for a few data points before the effects are seen. During this period, the algorithm will be correcting for the excess deviations.

All of the above means that you have a fine balance between dosing enough to stop high post-prandial rises while not dosing too much when there are low amounts of carbs on board.

While rate of change of glucose level plays a part in that identification, observations of what happens with me suggest that the difference between 10g of glucose tablets and a sandwich containing 35g of carbs is the time it takes for the rise to start and the length of the rise, rather than the rate at which glucose levels rise, which obviously presents a challenge for any system that relies on glucose data to determine all dosing.

Activities

The second major challenge relates to activity and IOB. Any algorithm that is managing dosing is working based off time, insulin, meal information, glucose levels, user inputs and then derivatives of those data. In the open source algorithms, those are all it has. If you try and remove two of those (meal data and user inputs) it becomes much more tricky.

If you are aware that you’re going to exercise, the normal protocol with a pump or hybrid closed loop is to take actions that reduce insulin on board prior to exercise. With your full closed loop, if you don’t do this, then you’re more than likely to end up with additional IOB, especially as the algorithm is adjusted to give you more insulin to counter rises. This, obviously, can lead to a higher level of hypos, or if you reduce the power of the algorithm to deliver insulin, a higher level of post-prandial hyperglycaemia. It’s a very fine balance.

This can be quite a significant challenge and is something that a user needs to be aware of when using an insulin only system. It can be countered by user programmed automations for when activity is supposed to take place, but this really only provides a rough guide. It’s also an area where commercial systems with a temporal learning capability have the potential to perform better as they may be able to identify regular exercise and act accordingly.

Physiological Effects

I’ve discussed physiological effects on hybrid closed loop performance in the past, and those still hold true here. If anything, they are exaggerated.

My own experience has been that when I am in a glycogen depleted state, everything works very well. My body pulls glucose out and turns it into glycogen and things work relatively quickly. If I’m sedentary and haven’t done much in the way of exercise, this all unravels, and with a faster insulin and automated dosing, not a lot happens. This is the corollary of the earlier point about the amount of insulin required at higher glucose levels. Some of that is undoubtedly down to the lack of exercise.

Ultimately, as I’ve observed before, exercise is good and has significant effects on glucose management, and with a fully closed loop that remains just as true.

What conclusions can be drawn from the experience?

Will there ever be a fully closed loop mechanically-based automated insulin delivery system?

Potentially, yes, but as long as there is a physical interface with the body, there will be times that there is little choice but to take over, as various aspects of the human/system interface will fail or work inefficiently and will need human assistance? Additionally, exercise with an insulin-only system that has no human intervention can be very challenging, for the reasons previously mentioned.

Another factor with a DIY system is that it doesn’t really adjust itself as the user’s physiology changes. Without something like machine learning or Autotune, there’s no way for the factors that affect insulin delivery to be properly tuned. Having said that, there is work going on to try and figure out ways to manage this better.

Is it possible to get close with an insulin-only system?

I think so, yes. The TIR percentage achieved during this observation period is remarkably high, and aligns with the levels seen in commercial hybrid systems. The time below range is higher than most would like, but with some algorithm adjustments, that can be reduced. And there are better minds than mine currently trialling this in the commercial world.

What’s good enough in a fully closed loop system?

That’s almost a loaded question. For most people, 80% time in range is staggering, and is easily good enough. 75% is also easily good enough, and if that was 75% with lower time below range, then it would be almost perfect.

The question is, “What should you care about?”. Based on the DCCT/EDIC data, an overall TIR that equates to an HbA1c between 6% and 6.5% is good enough to limit long term complications and highly beneficial in younger T1s. So an insulin-only fully closed loop delivering 75% TIR with 2-3% TBR would potentially be an ideal solution for those who tend to ignore mealtime bolusing.

Ultimately, this n=1 experiment highlights that an insulin-only fully closed loop is a possibility. Meal announcement allows better management of postprandial spikes, but with Lyumjev we seem to be approaching insulins that are fastest enough on, if not quite yet “off”. With Diabeloop’s recent recruitment for a trial with a similar approach, it’s clear that others also think this is a possibility.

And what about you?

It’s been an interesting experiment. In reality I’ve found that the variability is higher than I’d like, and as a result I’m going back to using a meal announcement model, which is able to deliver enough insulin early in the cycle to reduce those post-prandial spikes.

It’s also probably fair to argue that it’s not a fully closed loop for two reasons:

1. It requires user intervention to manage settings;
2. It isn’t able to manage glucose levels related to activity fully and requires user intervention here as well.

That’s not to say that I won’t, from time to time, take advantage of the hands off approach of the modified algorithm. I’m just not sure that for me personally, hitting the highs after a meal is what I want.