Understanding SMB and oref1

Understanding SMB
Understanding SMB

Continuing in this occasional series of explanations of the functions within OpenAPS/AndroidAPS, this one looks at SMB, and what is usually referred to oref1.

So let’s clear something up here. oref1 was the name used to introduce SMB, UAM and some additional tools into the oref0 world. 

The reality is that the functionality presented under all these naming conventions is the “latest version of the algorithm in the oref0 repository”.

Let’s start with the most well known feature….

SMB

What is it?

What is SMB? SMB stands for “Super Micro Bolus” and the name derives from the idea of “Super Bolus”, where basal insulin is borrowed from the future and included in a bolus.

A super micro bolus is simply a Super Bolus that’s very small.

The reason for using SMB in place of a TBR is that it allows the same amount of insulin to be delivered earlier. 

To quote Dana in her blog:

They allow oref1 to safely dose mealtime insulin more rapidly, while at the same time setting a temp basal rate of zero of sufficient duration to ensure that BG levels will return to a safe range with no further action even if carb absorption slows suddenly (for example, due to post-meal activity or GI upset) or stops completely (for example due to an interrupted meal or a carb estimate that turns out to be too high). Where oref0 AMA might decide that 1 U of extra insulin is likely to be required, and will set a 2U/hr higher-than-normal temporary basal rate to deliver that insulin over 30 minutes, oref1 with SMB might deliver that same 1U of insulin as 0.4U, 0.3U, 0.2U, and 0.1U boluses, at 5 minute intervals, along with a 60 minute zero temp (from a normal basal of 1U/hr) in case the extra insulin proves unnecessary.

And that’s it really. All that SMBs are is a way of delivering the same amount of insulin as a TBR, just getting the insulin in sooner.

The Settings

Within OpenAPS, only two preferences are shown in the default install:

  • Enable SMB with COB
  • Enable SMB with Temp Targets

This is intentional, as it allows SMBs to be used where perhaps more aggressive dosing is required, namely after meals or when trying to lower glucose levels. Under normal circumstances, SMB is disabled when a high temp target is set  

Within AndroidAPS, three additional options are also revealed, which are normally hidden in OpenAPS. These are:

  • Enable SMB with High Temp Targets
  • Enable SMB after carbs
  • Enable SMB always

These are hidden within OpenAPS as they are generally considered to require that a user’s settings are reasonably well adjusted, hence why Autotune is also a requirement in OpenAPS.

They allow SMBs to be used when you have a high temp target set (when they would normally be disabled) usually due to exercising, for a period of time after carbs have been calculated as absorbed, but when UAM may still be in operation and of course, always…

Safety Constraints on SMBs

SMBs are limited in size to ensure that a zero TBR can cope with the insulin onboard in case of any unexpected behaviours. From the OpenAPS docs, the defaults are:

Single SMB amounts are limited by several factors. The largest a single SMB bolus can be is the SMALLEST value of:

  • 30 minutes of the current regular basal rate (as adjusted by autotune/autosens), or
  • 1/2 of the Insulin Required amount, or
  • the remaining portion of your maxIOB setting in preferences

It’s important to note that maxIOB will limit SMBs from being issued if your IOB (for instance, from an easy bolus you have inputted before a meal) exceeds your maxIOB. 

It is possible to adjust the number of basal minutes of current basal that SMB can use in the preferences.

And that’s all there is to SMB. It’s a different way of delivering insulin. But what’s that UAM I mentioned?

UAM

UAM or “UnAnnounced Meals” is a way for the algorithm to recognise that either there is carb absorption, or an unaccounted for increase in glucose levels as a result of more carbs being onboard that entered, or as a result of hormonal variation and then deal with it effectively.

The deviation model described below allows for inaccurately or imprecisely entered carbs, or incorrect insulin doses to be detected and more insulin given in order to limit hyperglycaemia. 

It also serves to limit SMB dosing for meals until BG rises enough to safely give more insulin while limiting the likelihood and severity of hypoglycemia if carbs were overestimated or something happened that prevented them from having their full effect on BG.

When the UAM feature is enabled (as is recommended by default), any rise in BG, relative to what would be expected due to insulin alone, causes a UAM predicted glucose dataset to be created. That dataset projects the UAM deviations into the future for full DIA (Duration of insulin action, set in preferences) hours.

If the current deviations are higher than any of the deviations seen for the last ~45 minutes, then future deviations are predicted to slowly decrease from the current level, at a rate proportional to how rapidly they’ve risen.

Once the current deviation starts dropping below the deviation from 15-30 mins (or 30-60 mins) ago, future deviations are predicted to drop at the rate they’ve been dropping since their recent peak, either, until they hit zero, or for up to DIA hours if they aren’t predicted to hit zero by then. If this brings the predicted glucose value in range, the algorithm understands that no further insulin is required. 

If the minimum predicted glucose level over that timeframe is higher than the maximum target glucose, the algorithm understands that insulin is required (and safe) and doses according to the eventual predicted BG.  But if the minimum predicted glucose level drops too low, then a temp basal of zero is set and no further insulin is delivered until the minimum predicted glucose level returns to a safe range.

A flow chart of this decision tree is shown below (and it’s pretty similar to the standard decision tree in OpenAPS). 

ZTpredBG

Okay, so what’s this ZTpredBG thing? Well, with UAM in place, the algorithm generates a series of predicted glucose levels using UAM (alongside the IOB only and COB only predictions that have been in the system since the start). 

ZTpredBG is the “other” prediction that you see in NightScout. It shows how long it will take BG to level off at/above target if deviations suddenly cease and we run a zero temp until then. 

This value is used to moderate UAM and stops the algorithm from delivering too much insulin when running under a mostly UAM driven prediction. 

What does this all mean to me?

What all this means is that the algorithm used by both OpenAPS and AndroidAPS can safely be more aggressive in its predictions and treatments, which will result in reduced hyperglycaemia and should result in reduced postprandial hypoglycaemia. 

All in all it should mean a better user experience, better quality of life and greater Time in Range.

And while in many ways SMB with UAM is a relatively safe and forgiving way to more aggressively dose insulin to avoid highs, it does rely on your basals, ratios, and other settings being reasonably accurate, or you’ll likely see more variation in the outcomes.

This is why OpenAPS enforces Autotune before allowing SMB to work. And why I’d encourage either the use of Autotune, or undertaking an alternative method for ensuring settings are correct, before embarking on turning these features on. 

Written with Dana Lewis and Scott Leibrand

­

2 Comments

  1. Great article. Thank you for further explaining these features. I’ve been attempting to use SMB/UAM settings and have had varying degrees of success as I’ve tried to understand how to get it all turned on correctly. (Explaining that Oref1 is now in the master branch and simply needs to be turned on would have saved me a lot of scouring the internet before figuring that fact out out so I’m sure even that clarification will help others) A few questions.. 1) Being that the Enable SMB with High Temp Targets, Enable SMB after carbs, and Enable SMB always are hidden in OpenAPS do I simply need to type those into my preferences and toggle them to “Enable” or do I not have to worry about them? 2) I believe one needs to still pre-bolus through the pump and SMB’s or UMA’s correct as needed correct? 3) Some people (i.e. Dana and others) have referred to never having to bolus at all… How is this possible? Are there other settings that need to be added? If so, are those more line items to add to prefs? 4) Could you maybe give an example of all of the steps you take when preparing for lunch?

    Again, great article, thank you for you contribution in the forums. I’ve read your name many times as I’ve tried to figure everything out.

    • 1. In terms of what’s available in preferences, I’d look at the source code to check that. You can find the list at https://github.com/openaps/oref0/blob/master/lib/profile/index.js and you’ll need to copy the formatting as described in the OpenAPS docs and as you can see in the preferences.json file.

      2. Requirements for pre-bolusing depend on the individual, the insulin they use and the food they eat. For example, I can eat less than 25g of moderate to slow acting carbs and I don’t need to pre-bolus when using Humalog. With Fiasp that’s up to 75g of moderate to slow acting carbs. However, if I eat fast acting carbs, or more than the amounts stated, then I do need to pre-bolus. This isn’t about adjusting settings particularly (although you may want to look at adjusting maxSMBBasalMinutes) it’s about ensuring that you announce meals and that you’ve worked out whether it works with your physiology.

      You might want to take a look at this post on how to deal with mealtimes when using a DIY Closed Loop system, as I think it will answer most of your questions.

      Hopefully that will help you to understand more.

Leave a Reply

Your email address will not be published.


*