oref1 has been in the wild in master since the release of 0.5.0 of OpenAPS, introducing the ability to Super-Micro Bolus (SMB) which delivers small boluses in place of Temporary Basal Rates (TBRs) within a framework to ensure that safety is upheld, allowing insulin to be delivered more rapidly than TBRs allow for. There were also other extremely helpful updates at the time.
The latest release candidate for 0.6.0 is now in the dev branch to encourage more broad testing of the new functionality that has been introduced. There are some wide ranging changes, and here I’m highlighting what those are and how they need to be configured. Much of what is written here mirrors the PR in GitHub.
Exponential Curves
First up, Exponential Insulin Curves are in there to be trialled more broadly, alongside the previous bi-linear curve that OpenAPS had always relied on. This introduces curves that are based on the published data for insulin action and correspondingly, Insulin on Board. It became clear with the introduction of Fiasp that the existing model didn’t really provide the coverage needed to cope with the earlier peak and still long tail, so this addresses the issue. The graphs below show how varying the time to peak adjusts the amount of insulin absorbing and the amount available later in the decay cycle.,
This also removes the concept of DIA in the way that OpenAPS uses the curves. If you enable either of the exponential curves, for rapid-acting (such as Novorapid, Humalog) or ultrarapid (Fiasp), the calculations use the time to peak as their key driver and will always decay the curve over a minimum of five hours, because regardless of age, insulin simply doesn’t decay in less time than that. You can extend the decay period out to longer than five hours by adjusting DIA on your pump, but if you use less than 5 hours, the algorithm will use 5. The plan is to deprecate the older bi-linear model when 0.6.0 is released as master, however, ahead of that release, wider testing of the curves should be done, so if you want to use it in the dev version, you’ll need to enable it in preferences.json by adding a line to the file that contains the following:
“curve”:”rapid-acting” for Novorapid, Humalog, etc
“curve”:”ultra-rapid” for Fiasp
The other two accepted values for “curve” are “bilinear” and blank, which will revert to the historic model.
Remember that, in the preferences file, every line except the last one needs to end with a comma.
Using either of the new options will result in the following behaviour:
ultra-rapid
The model for Fiasp analyzed from Novo Nordisk data is used, with a peak activity time defaulted to 55 mins.
rapid-acting
The model for Novorapid/Novolog analyzed from Novo Nordisk data is used, with a peak activity time defaulted to 75 mins.
It is possible to adjust the peak times for both by the use of additional preferences options. These are:
“InsulinPeakTime” – set to a value between 35 and 120 minutes, which determines the time from bolus to peak activity
“useCustomPeakTime”:”true” if you need to want to use the above variation.
I have been using the default settings for both Fiasp and Novorapid and found the addition of the new curves really benefits the tail, and there is less tendency to load extra insulin towards the end of a bolus absorption period that might result in a low.
Carbohydrate Absorption changes
The carbohydrate absorption model has changed in 0.6.0, moving from a uniform flat line absorption model ( ——- ) to a bilinear model ( /\ ) for predicting the the future absorption of newly entered carbs. This means you’ll now see an S shaped curve in the prediction lines immediately after entering carbs, which starts flat, and then rises sharply for an hour or so, before flattening out again.
In addition, the absorption period can now be modified by the use of temp targets.
Under normal circumstances, the default absorption period for unabsorbed carbs is set to four hours, however the following temp targets will adjust that, changing the absorption time for any unabsorbed carbohydrate:
As in the existing release, any observed carb absorption will be predicted to continue into the future. These settings only work for any carbs that fall outside the the current carb absorption time if the absorption rate continues to decrease linearly over that time.
This isn’t a set in stone mechanism for controlling carb absorption. In the future, more automatic heuristics may be used to handle this. For now it’s a way to get it tested with a wider audience, but it’s worth being aware if you choose to test the dev branch that applying a temp target will also change your remaining CI time.
Enhanced Super Micro Bolus (eSMB)
Under 0.5.3, the behaviour of SMB was to constrain the bolus to no more than 30 mins of basal as one of its maximum limits.
Under eSMB in the 0.6.0 dev branch, this can be adjusted. What this means is that when a trigger is initiated, i.e. either a carb entry, bolus or lower temp target, SMB has the ability to deliver more insulin than 30 minutes worth of basal, which effectively means that you are able to get more insulin up front.
The idea behind this functionality is to reduce the need to bolus. It is especially effective when using Fiasp as the fast onset allows the eSMB model to deliver insulin that is effective very early on.
This is done by the addition of a new option in preferences, as below:
“maxSMBBasalMinutes”:xx where xx is a number.
The default setting for this is 30 mins, however when you add it to preferences, you have the ability to increase this. In testing, we determined that you shouldn’t increase it in increments of more than 15 minutes, and observe the effects of doing this. For most people who are still bolusing, 60 minutes should suffice, and when using standard rapid-acting insulin, bolusing is still required.
You should also have Pushover configured when testing this so that you can see predictions of both lows and highs, however, given the experience of eSMB, it’s usually not necessary to react to the high predictions as eSMB handles that with aplomb, which is a mistake I made, and will explain below.
What’s been interesting is testing this with Fiasp. Dana has managed three weeks of announcing her meals (i.e. entering a meal carb amount) and then letting the eSMB functionality get on with it. She reports three weeks with minimal bolusing and still achieving a time in range of 70-180 of 93+%.
When I tested this with Fiasp, I saw the following results, however, my testing took place as I was transitioning into the issues I have recently seen. I ended up setting the max bolus period to 75 mins, however my resistance to Fiasp appeared to be increasing, so these results probably also reflect that. The algorithm still managed to achieve 83% in range, and the standard deviation was 35%.
In the below AGP, we can see why we saw some of these variations. Most of it is not driven directly by the algorithm. The lows shown are driven by two things:
- On vacation, I forgot to disable the “Eating Soon” IFTTT schedule that starts to prepare for food at 7.30am, so I was seeing the effects of Fiasp acting early mornings. Whilst the algo was suspending insulin, by the time it realised I wasn’t going to eat, it had enough to cause a minor low. This caused the lows around 8.30am.
- The later evening ones were driven by reacting incorrectly to pushover alerts, and manually delivering insulin that wasn’t necessary. Had I left the eSMB function to do its own thing, these are unlikely to have happened (indeed, Dana’s experience back this up). This may also be linked to me being unaware of the slowly increasing issues I saw later in September.
There are also a couple of what appear to be rogue highs overnight and in the morning. These were both driven by site issues. One was a late change to the set (highlighting the need to change every two days with Fiasp) and the second was an accidental pull out caused by a dog pawing at me. Neither of which are things that an algorithm is going to be able to do much about.
What I learned is that if I meal announced, as long as I was happy to see a wider range of results, then with Fiasp, eSMB worked effectively. What I was also able to do was to do a meal announcement and then eat over a longer period of time, and it even managed to handle fish and chips, which is well renowned for being a difficult meal to handle. This begs the question. If you don’t need to bolus, is this really an artificial pancreas? It is certainly starting to approach what I wrote about here.
I have since been running this same branch with Novorapid, and while there’s not real possibility of allowing eSMB to take over, it’s delivered better results than SMB alone managed.
So there you go. A brief overview of some of the new functionality in the 0.6.0 release candidate that’s now sitting in dev. Some very interesting new features that, in my opinion, make life considerably easier.
Amongst some of the other, not already mentioned items are:
- Removal of the dependency on Git, which reduces the risk of the disk filling up
- Default use of SMB/UAM for 6 hours after trigger, ensuring that later rises are better handled
- Automated update to the latest version of deocare to improve the pump communications and fix the issue with larger basal rates
- Checking for percent mode on the pump to make it more obvious there are issues
- The ability to increase the carbs required threshold on pushovers so that they are not occurring too regularly
Plus a number of bug fixes and other items.
This is a fairly big release when it moves to master, so if you’ve historically looked at and used the dev branch, I’d encourage you to give this a try, and as always, take care and observe carefully, and please provide feedback on the latest candidate!
Leave a Reply