Understanding Autosens

Understanding Autosens
Understanding Autosens

If you’re using either of the implementations of oref algorithms (AndroidAPS or OpenAPS), you’ll have seen autosens in operation, and if you’re using AAPS, you’ll have seen multiple options available to choose from.

But how does autosens work and what does that mean for the different implementations?

The Basics

Firstly, the algorithms look at how much the sensor glucose is varying from expectations based on settings and allocate that a deviation:

To calculate this deviation, OpenAPS first calculates a term we call “BG Impact” or BGI, which is simply the current insulin activity (first derivative of IOB) * insulin sensitivity.

When expressed in units of mg/dL/5m, this represents the degree to which BG “should” be rising or falling, and can be directly compared to the delta between the current and last CGM reading, or an average delta over the last 15m or so.

To calculate the deviation, OpenAPS does exactly this comparison, between the 15m average delta in CGM readings and the predicted BGI. It then applies that deviation as an adjustment to the eventual BG prediction.

This is based on the simple assumption that if BG is rising or falling more than expected over the last 15 minutes, that trend is likely to continue over the next 15-30 minutes, and the magnitude of the projected deviation is approximately equal to what was seen over the last 15 minutes.

https://openaps.org/reference-design/

Here we’re only going to look at how the sensitivity model works. The effects of the different choices on Carb absorption are already described in the AndroidAPS documentation.

There are four models of autosens available in AndroidAPS. These are:

  • oref0
  • oref1
  • AAPS
  • Weighted Average

The oref1 model is what is used by OpenAPS. All do similar things, with a slight variation, so let’s start by looking at the basic method of Autosens.

“Autosens” works by reviewing both the last 8 hours and last 24 hours of data (so it’s a rolling calculation with a moving window of 24 hours) and assessing deviations to determine if you are more sensitive or resistant than expected. If a pattern of such deviations is detected, it will calculate the adjustment that would’ve been required to bring deviations back to normal. It will then use the more conservative between the rolling 8 hour calculation or the 24 hour calculation.

Autosens does NOT take into account meal/carb deviations; it only is able to assess the impact of insulin, and thus will adjust ISF, basals, and targets to help compensate for changes in sensitivity.

https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/autosens.html#notes-about-autosensitivity

Autosens also adds in zero deviations every two hours when there are excluded events so that as the number of excluded events increases, and/or as the valid, non-excluded data ages, there will be more zero deviations, reducing the effects of the older, non-excluded events and regressing the sens ratio to 1.

To determine if there is a pattern, it simply looks at the events it has used and determines if more than half of them are positive or negative. If they are, then it calculates the required deviation, as stated.

In all cases, deviations caused by Carbs, unexpectedly large deviations (or UAM in oref1) should be detected and excluded from use by the autosens algorithm.

In addition, certain activities “reset” autosens. The first of these is a site change, which is configurable in OpenAPS and works on both systems. The second is specific to V2 of AAPS and occurs when you do a zero duration profile switch. Due to the ability to set a different ISF in the Nightscout profile, AAPS starts the autosens cycle from the time of the switch.

Three of the four AAPS options use the standard autosens model:

  • oref0 on AndroidAPS only looks at the 24 hour window;
  • oref1 looks at the 24 hour and 8 hour windows and picks the most conservative;
  • AAPS sensitivity allows you to set the look back time period.

Weighted Average

The weighted average version of Autosens in AAPS uses the same data as the traditional Autosens model above, but adds in an additional factor, weighting deviations seen more recently more heavily than those that are older. This gives more importance to recent deviations than to those further back in the time window.

It’s worth being aware that when there are excluded values more recently, the weighting on older deviations is reduced, so they have less effect and cause the sens ratio to revert towards 1.

What happens in use?

In the eight or twenty four hour window, with all events given equal weighting, as in oref1 autosens, you are more likely to see the sensitivity ratio come out as 1, because it requires a sustained pattern to push the overall proportion over 50%. In addition, as more 0 deviations are used as padding, the sensitivity of the calculation to variance is reduced. It’s also worth bearing in mind that this is a more retrospective value due to it being effectively an average of the last 24 or 8 hours.

If you are using the weighted average version of autosens, you create a pattern by attributing more importance to recent deviations. You frontload the comparison so it effectively takes fewer deviations to push the proportion over 50% and generate a sens ratio, which means that it reacts more quickly to, for example, exercise or stress. 

That’s the key difference between the two and there has been positive and negative feedback for both models.

Autosens and Profile Switching in AAPS

It’s worth thinking about the way Autosens works in combination with the use of Profile Switching in AAPS as this is a feature that isn’t something that OpenAPS users have had available.

Autosens is designed to use the last 24 hours (or eight hours) of data and applies the current profile to the data. In OpenAPS this is likely to be the autotuned profile that ran at 4am, and will have a marginal difference to the previous profile.

In AndroidAPS, if you make a profile switch with no duration, then Autosens is reset and starts from zero, as it does with a cannula change. If you make any other profile switch with a duration, Autosens continues to function.

AAPS retains details of the previous profile switches in order to determine such details as IOB and carb absorption. In terms of how this carries through into autosens, the deviations at the time are calculated based on the active profile at the time.

Essentially, if you considered that you were insulin resistant and chose to run a percentage profile switch of 125% for a period a few hours ago, when using AndroidAPS you would expect that deviations versus BGI (the expected effect of the insulin) would be reduced during that period.

In the same example, if you were using OpenAPS, you’d set a low temp target, autosens would see that you were using more insulin for the same amount of change and would calculate that you were more insulin resistant.

In the AndroidAPS case the autosens algorithm would calculate a deviation value of “=”, for the period of higher profile based on the profile at that time. In the OpenAPS case, it would generate a “+” because it was using the current, never switched, profile which contained less insulin.

As you can see, this results in a noticeable difference as to how the same algorithm works in the two different systems due to core differences in how the systems view retrospective data. What it also means is that if you profile switch a lot to deal with varying sensitivity, autosens will not show much variation in sensitivity.

Final Thoughts

This is not intended to be a view on which is the best choice, rather an explanation of the operation of the models in use placed side by side so that users can understand how they work and make a more informed choice about what they do.

Personally, I find that the oref1 model works well for me on OpenAPS and AndroidAPS, but then I’ve never tried the Weighted Average model and rarely profile switch. As always, your diabetes may vary!

2 Comments

  1. Any idea if the autosens feature will be implemented in the Loop app, as that would be a much welcomed feature?

    • It requires someone to do it, and as Loop is built around very different framework it’s not an easy lift and shift.

Leave a Reply

Your email address will not be published.


*