Understanding SMB and oref1

Continuing in this occasional series of explanations of the functions within OpenAPS/AndroidAPS/Trio, this one looks at SMB, and what is usually referred to as 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 Advanced Meal Assist (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 and Trio, three additional options are also revealed, which are 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.

Within OpenAPS and Trio, it’s also possible to adjust the amount of the calculated insulin required delivered as an SMB. The default is 50% and the adjustment is done in code in OpenAPS and in the SMB Ratio setting in Trio. 

Adjusting this value needs to considered carefully, as once the insulin is delivered it can’t be removed, and if subsequent glucose readings flatten or drop, allowing a high percentage of insulin as a bolus can result in more hypos. 

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 oref1). 

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 OpenAPS, AndroidAPS and Trio 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. 

­