Meal times when closed looping. Some points to consider

Once you’ve enabled your closed loop system, you might expect it to make mealtimes easier. All of the systems that you can currently use have, built in to them, techniques that will try and reduce post meal spikes. There are a number of behaviours that anyone, looping or otherwise, can (and probably should) use to help manage glucose levels around meals.

Remember that these are “Hybrid Closed Loops” and not fully closed loops, and around mealtimes, need user input in order to be successful. 

But before we start, I once wrote, in relation to using a closed loop, “It’s all about the numbers…”. And it is.

If you have come from pumping, you will probably find that what you thought worked leaves you with frustrating post meal highs, and this is usually because you need to change your basal rates, ISF and CR. Most people have, in their normal pump settings, inadvertently factored in meals into basals. Most wont even be aware of it. Many will have used a DIA of 3 or 4 hours. Individually these things might not seem like much but taken together, they can reap havoc.

The first thing that you should be doing before turning on the loop is a proper process of basal testing, and following up with ISF and CR testing. This will help with those mealtime spikes and/or hypos. A lot!

Pre-Bolusing

As most people hopefully realise, insulin peak time and carbohydrate peak time generally do not match, with fast acting insulin action peaking at between 60 & 90 minutes, with Fiasp being slightly earlier. 

Carbohydrate, on the other hand, tends to peak between 15 and 45 minutes after being eaten. Yes, with certain foods there are other, longer effects that can be covered later, but there’s a notable mismatch between these two factors. 

As a result, if you bolus with the meal your insulin has very little chance of reining in the following glucose rise, and whether you are using a pump, loop or MDI, you can expect a significant post prandial rise. 

In order to handle this, taking insulin prior to the meal is often required. Pre-bolusing requirements tend to depend on the person and the food, and usually come from some form of trial and error experimentation, but for me, 15-30 mins prior to eating is usually optimal as it allows insulin peak action to overlap with carb peak absorption. This is also one of the classic “Your Diabetes May vary” items.

Even when looping, you’ll still need insulin to cover off carbs and need to time it effectively.  

If you’re Open Looping with AndroidAPS, and going through the objectives, you’ll also find that you’ve lost the ability to do a dual wave or extended bolus, so until you’re off the “Low Suspend” only objectives, you’ll need to deliver insulin manually, post prandially to have a similar effect to an extended bolus.

That’s where we take it a step further. 

Eating Soon

Eating soon is a way of getting insulin into your body ahead of eating and having it start to take effect. You don’t need to loop to use it, but if you do, it makes scheduling it easier. Dana covers this in detail here, but the basis of this is that you give smaller amounts of insulin for an hour or so ahead of eating in order to have active insulin when it comes to eating.

For many people, pre-bolusing results in the following effect:

However, this type of post meal issue isn’t what people want. In a closed loop, “Eating soon” sets a low temp target, allowing the algorithm to dose insulin, while avoiding a low. It looks a lot like this:

The majority of people that have used this functionality find that it does a good job of reducing post-prandial spikes.

Handling meals with SMB

With the SMB (Super Micro Bolus) functionality within OpenAPS and AndroidAPS, users may consider that they no longer need to bolus for meals. This isn’t really true. While SMB allows insulin to be delivered earlier in the algorithm’s delivery cycle, it doesn’t stop the issues with insulin absorption timing, so if you are using regular rapid acting insulins, such as Humalog, Novorapid or Apidra, you still need insulin ahead of a meal. It’s generally very difficult to avoid post-prandial spikes otherwise.

With Fiasp, people have found that it is possible to use only SMBs (both with and without Eating Soon) to manage meals, as long as carbs are announced. This is another area where you’ll need to test for yourself.

The upshot here is that, in general, you’ll still need some level of insulin before the meal when using the SMB and UAM functionality.

What about longer acting meals/pizzas?

Whilst the traditional way of dosing insulin only looks at carbs, there’s a reasonably large amount of research that deals with the impact of Fat and Protein on post-prandial glucose levels. (Examples here and here). The latter of these two is the Warsaw Method, and allows the calculation of appropriate bolus strategies for high fat and/or protein meals.

Within the looping systems, there are also settings that help with this. Starting at the base level, OpenAPS and AndroidAPS observe “carb absorption” with no ability for the user to input an absorption period. Loop allows you to set an estimated absorption period and adjusts absorption it sees dynamically around that.

For me this is generally good enough, as the below chart of 50g of protein and 15g of carbs shows:

What follows comes with the usual “Your diabetes may vary” warning and will require experimentation from the user.

By entering roughly 50% of the weight of protein in a meal as “fake carbs” and in Loop’s case, giving it a long absorption time, the systems can take into account the longer term glucose raising effects of components other than carbs.

Beyond this, there are additional techniques that can be used to take account of Protein and Fat. These are generally used when the time period that you need to cover is beyond “normal” absorption times, e.g. 5+ hours.

Robert Silvers has written a bolus calculator that uses the Warsaw method to calculate distributed “fake carbs” to encourage whichever closed loop system you are using to see carbs and react. The spreadsheet for manual calculations is available here.

He can be seen showing it off here:

This is included in Loop and can be downloaded from iCloud for OpenAPS and AndroidAPS users, here and here. Both files are needed, and allow a shortcut that posts the “fake carbs” to NightScout, for integration with OpenAPS/AndroidAPS. The results, according to most users, are extremely good.

Robert’s, the last 20 seconds on the video are too:

In addition, if you don’t have the shortcut, or want something quicker to use, AndroidAPS has the option to include “eCarbs”, which are Extended carbs”, and will distribute a carb value over a period of time to allow the equivalent of an extended bolus.

All of these tools allow automation of difficult to deal with meal situations and offer a significant improvement in post-prandial glucose levels. 

Ultimately, as everyone’s diabetes varies, there will be differences in what people need to do to manage meals. If the basics don’t work then it’s worth looking at the more systematic approaches.

First and foremost though, try using the system basics and confirm that you need more before jumping in with the additional options.