Full Closed Loop

The main attraction of Full Closed Looping FCL is that it has the potential to mimic an artificial pancreas and make daily management easier without having the need to bolus for meals.

Whilst hybrid closed loop (“HCL”) is algorithm based, it still requires the user to manually deliver boluses prior to meals. As a result, the loop may go into a temporary shut-off (temporary zero basal) to prevent over delivery of insulin.

In FCL mealsize-related bolus are no longer required: leave it to the algorithm! AAPS may allow without the user giving any bolus, and without making carb inputs, in a mode called ‘un-announced meals’ (‘UAM’). UAM allows AAPS to better tolerate incorrect carb inputs by being more aggressive.

What to expect?

There are many published studies on the favourable results FCL can achieve. For further reading refer to the following:

  1. NationalLibraryOfMedicine PubMed National Library of Medicine, PubMed First Use of Open-Source Automated Insulin Delivery AndroidAPS in Full Closed-Loop Scenario: Pancreas4ALL Randomized Pilot Study;

  2. NationalLibraryOfMedicine ClinicalTrials.gov National Library of Medicine, Clinical Trial Feasibility and Safety Study of the Automated Insulin Delivery Closed Loop System Pancreas4ALL (ASAP)

Success for FCL requires the user to:

  • check whether they met the FCL requisites;

  • set up Automations that are tailored for their daily management’s needs; and

  • fine tune and adjust the AAPS settings (notably Automations).

General considerations why (not to) move from HCL to FCL

FCL is not for everyone:

  • Some FCL users achieve TIR (70-180) around 90% and HbA1c under 6%, however other users prefer tighter control. Notably, minimising values over 140 mg/dl at diets with rapid carbs probably requires pre-bolusing.

  • AAPS tuning can be challenging. It is not for those users who feel overwhelmed AAPS. You will need to dedicate a few weeks in order to adjust and fine tune your FCL. Investing such time can yield better results and BG control.

  • Meal management may become easier, however exercise can still be challenging in FCL. Most of us like to limit sports snacks in an attempt to control body weight.

  • Difficulties still remain to establish a FCL for kids (discussed below).

Well-tuned hybrid closed loop

It is advisable to first establish a well-tuned HCL before considering the transition to FCL. Success with FCL requires a highly personalised individualised tuning of the user’s setting so that AAPS can give insulin to closely mimic YOUR successful hybrid closed loop mode.

FCL requires the user to set up and tune their Automations. However the user must have a confident understanding of their insulin management needs before embarking on FCL. Errors can be masked with counter-errors. This can create an unstable FCL system, and make it hard to later correct. You should expect to reach a comparable %TIR with your FCL as you see today in your HCL.

FCL is a DIY set up of Automations determined by the user by analysing their data from both their successful HCL and initial FCL experience when tuning your settings.

Fast insulin (Lyumjev, Fiasp)

FCL requires fast insulin. This is so that at the start of meal-related BG rise, FCL is able to keep BG in range (by common definition, under 180 mg/dl (10 mmol/l)).

A modelling study (details see LINK FullLoop V2/March2023; there section 2.2) can show in quantitative terms that faster insulins

Source:

IEEEControlSystemsMagazine ResearchGate

IEEE Control Systems Magazine, ResearchGate The Artificial Pancreas and Meal Control: An Overview of Postprandial Glucose Regulation in Type 1 Diabetes;

  • will result in significantly lower BG* peaks than slower insulins;

  • tolerate a couple of minutes delayed first meal bolus while not incurring unacceptable height of peaks; and

  • minimise the effect on BG peak from different carb loads (meal sizes).

FCL is unlikely to be effective with insulin other than Lyumjev or Fiasp, unless the user is on a very moderate to low carb diet.

However, Fiasp or Lyumjev can result in frequent pump occlusions, even after optimising things like needle length. It is important to have an eye on the cannula or pod time. Many users find 48 hours to be the efficacy insulin limit before resulting in cannula/pod failure.

Prerequisites

BG values and stable bluetooth connectivity are required to ensure AAPS can optimally perform without losing valuable time. FCL requires a 24/7 technically stable system:

  • your **CGM’s performance. Your CGM should not produce jumpy BG values that could be misinterpreted by FCL as a sign of a starting meal. Similarly, CGM calibrations can produce jumpy results.

  • how and where any CGM smoothing is done, and what this might imply for your tuning. Notably how delta is defined, and AAPS recognising this as being sign of a starting meal.

  • bluetooth stability for the pump and CGM pump;

  • avoiding (or at least early recognition of) pump occlusion;

  • data flow and your phone’s apps used and difference between days of sensor usage;

  • keeping all AAPS components well charged and in spare parts close proximity; and

  • actioning cannula (or pod) changes always early enough to lower the risk of occlusion;

The above will vary depending on your AAPS component system and your lifestyle.

Enabling boosted SMBs: safety

In HCL safety restrictions are implemented regarding bolus sizes that can be automatically given by the loop.

FCL loopers no longer need to give a sizable bolus around meal start. The impact of this means that restrictions in size limits for SMBs must be widened to make the loop capable of delivering large enough SMBs.

If you are operating with AAPS in the Master release, it is suggested AAPS” Preferences are set up with the maximum allowed SMB size so that FCL can give (maxUAMSMBBasalMinutes=120, i.e. 2 hours worth of basal at that daytime).

If your basal rate is very low, the resulting SMB limits might be too low to allow sufficient control to tackle postprandial BG rises. One possible solution is to avoid diets that cause strong BG spikes and later switches to a AAPS dev variant that offers a new parameter in SMB delivery settings: smb_max_range_extension. This will expand the standard maximum of 2 hours worth of basal by a factor of >1. (Additionally, the default 50% SMB delivery ratio might be elevated in dev. variants).

Follow the instructions to enable AAPS to mimic your bolussing via a couple of SMBs.

Check the SMB tab periodicallu to see whether your SMBs are allowed to be sufficient enough to deliver the required insulin needed for the loop around meal starts.

If not, your tuning efforts will sometimes come to nothing!

Boosting ISF can become dangerous

Carefully observe/analyse the SMB sizes shortly after your meal commences. Tune in steps, and do not vary more than 1 or 2 parameters at a time.

Your AAPS” setting must be sufficiently set up to cope with your (!) variety of meals.

Meal detection/your Automations for boosting

For successful FCL, ISF is the key tuning parameter. When utilising AAPS Master + Automations, a > 100% profile change must automatically be triggered upon meal recognition (via glucose deltas), and provide the sharpened ISF.

AAPS Master allows up to 130% temporary Profile in HCL p mode. Boosting the ISF is done in 3 steps:

  • Step 1 - review the ISF applicable for this meal time hour within the Profile, and see whether e.g. Autosens suggest a modification that takes care of the current (last few hours’) insulin sensitivity status of the body..

  • Step 2 - apply a factor (1/Profile%, as set in Automation) to boost ISF.

  • Step 3 - check that the suggested ISF falls within set safety limits.

FCL’s Automation templates

Boxes to tick at the top. You have the option:

  • In your Automation list, you can tick the check-mark (to the left of each field) OFF => This de-activates that Automation. For instance you can do this for all breakfast related FCL Automations to go to HCL for breakfast(s).

  • For each Automation rule you can tick the box for User action => then the defined Actions will not automatically be executed when Conditions apply. Rather, the AAPS main screen will alert you whenever your FCL would automatically give a SMB. You have the opportunity then to say ‘yes’ or ‘no’. This is extremely useful in your tuning phase.

This feature can be useful for certain situations like “foot to floor” syndrome whher there is a sudden rise in BG when getting up in the morning, but the user wants to prevent a fully automatic “breakfast started” response.

The section below provides guidance how to bundle Automation’s Conditions and how to tackle situations in which the AAPS should increase (or decrease) insulin delivery. As ISF cannot directly be tuned, raising Profile Percentage over 100% will do the same for our purposes.

Automated big SMBs at bg rise

The key to successful FCL at the beginning of BG increases from meals, very large automatic SMBS must be given by the loop as quickly as possible “to catch up” with the required IOB needed (compare with your typical administered bolus for similar meal in hHCL!)

To achieve this, data from your HCL should be analysed to determine which deltas might be not meal –related and those delta which might be.

  • As you can define the Automation within a pre-defined time-window, you need only to analyse there.

  • If you do very different kinds of meals (e.g. a rather high carb breakfast, but low carb lunch) you can choose to do two different (sets of) Automations for each of the time slots.

  • Exclude the nights if you see occasional jumps from a compression lows

  • Usually, just using the delta of the past 5 minutes suffices.

  • But you can also make use one of the average deltas. By comparing the deltas in the conditions of your Automations you could even define actions of different aggressiveness depending on whether the BG rises in an accelerated way or not.

( delta – short avg delta )>n is a term that could be used for acceleration detection , to trigger first SMB at earliest sign of rising BG. -
Caution: not possible to use with poor or highly smoothened **CGM-values!

A CGM with patchy data puts the user in a bad spot because, to be on the safe side, you need to „sandbag“ your definition which delta is surely a sign of a started meal. This means:

  • FCL loses additional time, resulting in higher BG peaks and lower %TIR;

  • you cannot use an earlier or smaller delta which could trigger, also without a meal, the SMBs that are supposed to make up for a user bolus in FCL.

Furthermore, first rises after a meal are characterized by low iob present. With that in mind, an Automation(#1) for a dinner might look like this:

8mg jump 130% ioby4

Automation #1

If Conditions apply, AAPS would give 1 or 2 SMBs in the next 12 minutes, using a boosted ISF according to the set elevated Profile Percentage (in the example, a 30% boost of insulinReq). As long as these Conditions apply, the Automation rule extends by another 12 minutes. A low carb meal might have slower BG rise characteristics. It would benefit from another Automation (#2) that kicks in at lower delta, and gives a weaker insulin boost.

>=5mg jump 115%, iob<5.5

The same Automation probably will kick in also in higher carb meals, once the steep rise as defined in Automation#1 is over.

You need to “stage” these two (+ maybe a third) Automations to fit with what you see in your meal (variety) => Setting appropriate jump sizes, iob criteria, and amplifications will be an iterative tuning process. Also, if you include appropriate time slots in the Conditions, you can easy do different Automations for your different daily meals times (breakfast, lunch, dinner).

Note that, still in the rise phase (!), the «overflow» of iob must be blocked so that the late effects of the insulin (the «tail» after 3-5 hours) will not exceed the braking capacity of the loop through zero-temping (“taking away” basal, to reduce hypo risk).

With large meals there is sometimes a second increase. By then, usually also the iob has dropped a bit, and the more aggressive Automations take effect again. (Check that your iob condition in Automation #2 is not set too low to for this to happen).

Soon after a few initial SMBs are given comes a balanced phase where moderate delivery of insulin should cover the additional carbs absorbed. (Except in low carb meals, where the loop might see too weak of aBG rise, and go into zero-temping right away already now).

The AAPS main screen (where you see cob=0 in UAM full loop) might in this phase ask for more carbs required. In UAM mode that simply means, you could make a very rough plausibility check: Is that amount of carbs likely in your body, un-absorbed from your meal just about an hour ago (about which you gave your loop no info)?

iob threshold

Often, Automations #1 and/or #2 make iob rise to heights that typically are enough for your meals. For personalised tuning, look in your HCL data at the max iob values that occur with well-managed meals (often: your meal bolus), and above which magnitude a hypo (or requirement for extra carbs) occurred at the end.

Sensible iob thresholds at which you should reduce aggressiveness of your loop, might not be the same for every meal. But especially in the first hour after the start of a meal, which is very crucial in the UAM mode. It will defer to for each user. For some users just about 30g/hour get absorbed, and to define a meaningful iob independent of the exact meal can be possible.

For exceptional meals, or to lower it if sports follow, the iob threshold can rapidly be set differently in your Automation.

Automation(#3),”iobTH reached => SMBs off”, is defined to end (or pause, until another wave of carb-related rise hits) the aggressive SMB boosting.

iob >5.5...111 TT = SMBs off 16m

Automation #3

It tells the loop that above your set iob threshold it’s better not to use any more SMBs

  • The given example does that by setting TT=111 (which is kind of arbitrary; pick a number>100 that you easy recognise as your automated SMB shut-off)

  • In AAPS” Preferences/ SMB Settings generally do not allow SMB at elevated target).
    The insulin required will then have to be delivered with much more caution through the bottleneck of TBRs

Caution: Automation #3 only works when there is no active TT. So, in case you worked with EatingSoonTT, it must be ended by that time, which usually should be 30-40 minutes after meal start.

One way to do this is to set up an Automation Condition that ends an eventually running EatingSoonTT under the Condition iob>65% * iobTH.

Ways to work with EatingSoonTT Some loopers set (by pressing the TT button, or automated via a lowered Profile BG target if eating time slots are fairly fixed) an EatingSoonTT roughly an hour or more before meal start, just to guarantee a low starting BG and slightly increased iob. But, assuming the FCL is always en route towards target, this might not yield much and you may prefere to define an Automation that sets an EatingSoonTT at recognition of meal start (glucose delta, or acceleration = delta > avg delta). A low TT is important in this stage because any SMB is calculated by your loop using (predicted glucose minus TT)/sens, so a small TT makes the resulting insulinReq bigger.

After the first boosted SMBs were given, your set iobTH and Automation* #3 should strike a good balance of limiting the glucose peak, but also not leading to a hypo after the meal.

If your breakfast substantially deviates in carb content from your average dinner, you may benefit from defining Automations that apply in the respective times of day, and have different iobTH (possibly also different deltas, and different Percentage Profile set). Both, you with defining your meal spectrum and settings (notably, iobTH), and the loop managing the unfolding BG curve, must accept certain peak heights for reducing hypo danger towards the end of the DIAs from SMBs.

Stagnation at high bg values

In case, after a “rich” meal, a long-lasting stagnation with high BG value is seen, Automation #6 (below, left),»post-meal High”, helps deal with fatty acid resistance: After multi-course meals, large greasy pizza, raclette evening, the glucose curve can form two humps or, very often, an elongated high plateau.

iob >5.5...111 TT = SMBs off 16m

Automation #4

iob >5.5...111 TT = SMBs off 16m

Automation #5

Automation #4, “post-meal High”, is also suitable in hybrid closed loop.

In addition, a termination-Automation #5, “Stop pmH”, is needed, so that the aggressiveness of the insulin administration is reduced, as soon as the glucose value is falling. (However, often the loop will limit more insulin anyways for hypo prevention because predicted glucose runs low already).

Hypo prevention

The core problem is that the UAM FCL (without carb inputs) can have no idea how many g of carbs are still available for absorption, and might use up that “tail” insulin, without you going into a hypo from it.

Using boosted SMBs, the FCL “caught up” with what we formerly did with a meal bolus. But, at the “tail” end of insulin activity, hypo prevention can become a serious topic.

In preparation for FCL, the user must take a closer look at the time course of iob for typical meals, and judge when it becomes too much, and how you can catch that by tuning your Automations. That is possible because we have several adjusting screws. It can be a challenge to get this right

Generally, it makes no sense to keep optimising settings for one kind of meal. Once you have a good-enough setting e.g. for one kind of lunch you frequently have, test how this works with other kinds, and how you would “compromise”.

In order to prevent hypo in post-meal hours 3 – 5, reduce the aggressiveness before too much iob comes together. Specific approaches:

  • Become milder and milder with the ISF already during the glucose rise, as in Automation examples #1 and #2 given.

  • Define the iob threshold, from which AAPS is made significantly more cautious (Automation #3, above). Note this iob can be exceeded, by the last SMB before it went into effect; and then further by TBRs if the loop sees insulinReq Carbs getting absorbed will provide a counter-movement towards lower iob.

  • The iob threshold could be differentiated according to meals: By cloning the automations, you could easily differentiate for breakfast, lunch, and dinner time slots (or even for geo-locations, like company cafeteria, or at mother-in-law etc)

You could differentiate within these time slots even further by setting different TTs for low carb vs. fast carb, etc., and thus be able to “code for” different meal classes that may occur at this time of day, and call them up with Automations specially tuned for them. This is probably not necessary, unless your diet habits do vary a lot.

Before a special meal challenge, you can raise your iob threshold, or make another change in any of your Automations within under 5 seconds, right from your AAPS main screen (burger top left; or Automations tab, depending how you configured your AAPS).

The hypo danger some hours after the meal is essentially a question of whether your meal composition was such, that the insulin tails from fighting the bulk of carbs will be consumed by “extended carbs” (excessive/delayed carb absorption/protein/fat/fibre).

Over time you will learn patterns, tune your Automations – maybe even adjust your eating habits a bit, e.g. just enjoy the occasional late little(!) snack that may help maintain a good balance of insulin activity and carb absorption for the entire meal (digestion, absorption) time, and thus make life for your loop (and for yourself) easier.

Order of programmed Automations

Problems can arise with overlapping definitions in Automations. Example: The problem is that delta >8 is also delta >5, i.e. there may be two competing Automations What does the loop do then? It always decides according to the sequence in which your Automations appear when looking into the burger menu / AdAPS main screen. Example: The delta > +8 rule must come first (and launch the strongest boost if all conditions apply); then comes the check for delta >5 (and a milder response). If done the other way round, the delta>8 rule would never come into effect because the delta>5 already applies, case closed.

Tip for Automations: Order changes are very easy to make. Press on a list entry in AAPS/Automations and the user rearrange the Automations in question to another position.

Also it is very easy and quick to adjust any conditions or actions at any time, within seconds, just on your AAPS smartphone; for instance if you head into a very special eating event. (But don’t forget to set it back to normal on/for the next day).

Troubleshooting

How to get back into Hybrid Closed Loop

You can un-click the top boxes in the Automations related to your FCL, and go back to bolusing for meals and make carb inputs again. You may have to go to AAPS Preferences/Overview/Buttons and get your Buttons “Insulin, Calculator…” back for your AAPS main screen. Be aware that now it is again up to you to bolus for meals.

It may be wise to do FCL only for meals (time slots) where Automations are fully defined and clicked on, and un-click only those for the other meal times when you like to do HCL (or have none defined yet, in your transition period).

For instance, it is perfectly possible, without any extra steps after Automations for dinner time slots are defined, to do FCL only for dinners, while breakfast and lunch are done in a HCL as you are used to.

Are the pre-conditions for FCL still given?

  • Is the basic Profile still correct?

  • Has the CGM quality deteriorated

  • Refer to pre-requisites (above).

Glucose goes too high

  • Meals are not recognized asap

    • Check regarding Bluetooth (in)stability

    • Check whether you could set smaller deltas to trigger first SMB

    • Experiment with an aperetif, soup acouple of minutes before meal start

  • SMBs are too weak

    • Check order of Automations (e.g.: big delta before small delta)

    • Check (real-time) in SMB tab whether hourly profile basal and set minutes (max 120) limit allowed SMB size

    • Check (real-time) inSMB tab whether %profile must be set bigger

  • If all your settings are at the limit, you may have to live with the temporary high, or adjust your diet.

If you are ready to use AAPS dev variants, you could also employ one that allows further expanded SMB sizes. Some users also resort to using a small pre-bolus in their “FCL”. However, this interferes with how glucose curve and hence detection of rises and triggered SMBs behave, and is therefore not easy to implement with convincing overall benefit.

  • An important observation by pilot users was, that how your glucose and iob curves approach meal start matters a lot regarding how you peak from carbs: Going down (e.g. towards a set EatingSoonTT), building some iob, and curving already towards strong positive acceleration seems very helpful to keep peaks low.

Glucose goes too low

  • Meals are falsely recognized

    • Check whether you could set bigger deltas to trigger first SMB

    • Click “User action” in the related Automation, so in the futurte you can ad hoc decide to block execution of the Automatiojn if not meal-related

    • To prevent snacks from triggering SMBs as for a meal, set a TT>100 when snacking (as you would do in sports and for anti-hypo snacks, anyways)

  • SMBs deliver overall too much insulin

    • Check (real-time) in SMB tab whether SMB range extension must be set smaller

    • Check (real-time) in SMBtab whether Percentage Profile must be set smaller

    • SMB delivery ratio probably can be set smaller. Note in this case, it works across the board for all SMBs (all time slots),

  • Problems with insulin “tail” after meals

    • You may need to take a snack (seeing hypo prediction) or glucose tablets (if already in hypo zone). But note that the carbs required the loop might tell you at some point are very likely exaggerated as the loop has absolutely zero info on your carb intake (while you may be able to guess how much more, incl. from fats and proteins) is still waiting to be absorbed.

    • A valuable information would be whether the problem originates mostly in the bg rise phase already. Then setting a lower iobTH might be an easy remedy.

    • If the need for additional carbs happens frequently, note down how many grams were needed (not counting what you eventually took too much and required extra insulin again). Then use your profile IC value to estimate how much insulin less the SMB should have delivered, and go with this info into your tuning (regarding the Percentage Profile in Automations, or maybe also your set iobTH). This may relate to theSMBs given when glucose was high, or also extending regarding also the SMBs during the BG rise.

    • It could well be that you simply have to accept higher BG peaks for not going low. Or change diet to something with lower amounts of carbs, and higher amount of proteien and fats.

More info

Make sure you stay in touch with other FCL users.

Discussion Full Closed Loop using Automations: