Automating ISF in open source AID systems. Experiments with AndroidAPS

Automating ISF in open source AID systems. Experiments with AndroidAPS
Automating ISF in open source AID systems. Experiments with AndroidAPS

As discussed in this article, I spent the best part of the last six months attempting to use an insulin-only full closed loop system. As part of fully closing the loop, removing the need to constantly adjust settings becomes more important, and to that end I worked with Chris Wilson at Glucose Genius to implement his TDD and weight-based ISF model into oref1, after he started to discuss the idea that ISF was glucose related on Twitter, which is something that I had observed myself.

By doing this, the intention was to remove the need to observe and adjust ISF and allow it to be calculated in the background, automatically.

AAPS was used due to its statistic packages that allow real time calculation of total daily dose, giving a way to look at both historic data and also the real time data of insulin that’s been delivered during the day.

Approach

The equation generated by the Glucose Genius research was the starting point for implementing this process within AAPS.

From there, I needed to determine what was the most sensible approach for using the output of it. To start with, the previous 7 days average TDD was used to create the ISF value, but it became clear that this didn’t detect variations in sensitivity and insulin use, and this led to a modification that used a combination of the real time pump insulin delivered, extrapolated out over the rest of the day, and the historic data over the previous 7 days. This is currently bound within the current day’s 24 hour period.

After running this combination manually, I sought help to modify one of the statistics packages within AAPS to provide the current delivered insulin from the pump.

Combining this with the 7-day average TDD generated a weighted average, the weighting of which is variable dependent on total insulin used today, to allow better detection of varying sensitivity in real time. 

This value is then fed into the calculation to generate an ISF value.

The predictions that are then generated by oref1 for the various curves are based on this variable ISF value.

Use for dosing

Now that we have a set of predictions based on a glucose and TDD based ISF, the next thing required is how dosing decisions will be made. Should the current ISF be used, or can we take the model we used previously and apply the predicted blood glucose level to pre-emptively dose for a future glucose level, with the intention of getting enough insulin on board now to reduce any post prandial rises.

The initial model used the eventual glucose level predicted by oref1. I had concerns that this would potentially generate over-large boluses while glucose levels were rising and this turned out to be the case. As a result, the future glucose based model evolved to use a combination of factors, using wholly the future value when current levels were flat or falling, and the predicted value was lower, and weighting the value between current and future glucose levels when glucose levels are rising.

The result of these approaches has generated what appears to be a stable model that I have now been using for 4 months, and has been integrated into experimental code that a small group have had access to.

Outcomes?

What are the outcomes in this approach? 

Whilst I haven’t tested it on its own with oref1, it has been integral in the fully closed loop model that I posted previously, which produced the below data for me:

 

Additionally, another beta tester published this data using the same algorithm:

The main difference between the two seems to be the target glucose level. Both cases are extremely promising.

I have integrated the code into oref1 and need to run it as standard oref1 wiht this adjustment to see what the outcomes are.

Can we use this with other factors?

In theory, yes. Of the settings that are required in the DIY closed loop systems, Insulin sensitivity factor and carb ratio both appear to users to vary according to glucose levels. If we can modify Carb Ratio to use this type of approach, then it maybe possible to take this out of the set-up.

Realistically, it would be better to use a more constant physiological factor over Carb Ratio, and it may be that “Carbohydrate Sensitivity Factor” is a better way to do this. In theory, this is something that is less likely to vary with glucose levels than those which have a link to insulin sensitivity. I have an idea as to how to modify the algorithms to use this, but it requires some work to test and run, but it would be beneficial to have something that doesn’t require regular tuning in the AID system set-up.

Of course, the background to all of this is the work that Glucose Genius has been doing, and there is far more to come from that, much of which has the capacity to make a big impact on the way we look at diabetes.

 

 

 

 

 

Be the first to comment

Leave a Reply

Your email address will not be published.


*