"Floating carbs" (or unannounced meals)

[danamlewis]

While OpenAPS was originally designed as a hybrid closed loop with the intention for people to still do their usual meal boluses and carb entry, several people have taken it upon themselves to try "unannounced meals" (and no meal boluses) with openaps.

We have outlined a testing approach to unannounced meal testing, starting with a small amount of known carbs and working up from there, but below have also described an idea of incorporating known "floating carbs" (new term made up as of here) into the closed loop as a result of observing all of this testing and the results reported from community members.

1. Unannounced meal testing approach:
Pre-requisites:

• Set up OpenAPS Advanced Meal Assist and Temporary Targets
• Override the maxSafeBasal in preferences.json and your pump bolus wizard settings for the duration of each test to be roughly double what you would normally use.
• Ensure that during each test, the PWD will be closely monitored.

To test how OpenAPS would deal with unannounced meals, we want to start with a very small snack, and work our way up to see how large of a meal it can deal with effectively, without allowing post-meal blood sugar to exceed safe ranges. While we will not be announcing the size or exact timing of the meals, we will be setting an Eating Soon temp target (and in later phases, entering carbs) well in advance of the expected meal time. This will simulate a system that learns/knows when mealtime “should” be and schedules Eating Soon mode to prepare for an unannounced meal at something close to the normal meal time.

Because you will not be bolusing for carbs normally, you can expect a post-meal BG spike that will get proportionally larger as you increase the size of the unannounced meal. We hope that Eating Soon and Advanced Meal Assist will be able to somewhat blunt that spike and eventually catch up to deliver all of the meal insulin and gradually bring BG back into range. We will start with a small and safe snack, observe OpenAPS’ behavior, and then decide whether to continue with progressively larger unannounced meals. Before starting, you should decide on the BG range (lowest and highest BG) you are comfortable with: ideally something like the range you would normally expect to see after a large meal without OpenAPS assistance. You will then progressively increase the size of the unannounced test meals until you see BG excursions outside the acceptable range, at which point you should stop that Phase of the test and decide whether to proceed with the next Phase of the testing.

Phase 0 (announced meals with carb estimates but no meal boluses):
Starting with a small snack:

• Make sure your CGM is calibrated, OpenAPS has been operating normally, and you do not have any COB or significant bolus IOB.
• 90 minutes prior to expected meal/snack time, set an Eating Soon temp target with a duration of 120 minutes.
• At meal/snack time, enter carbs into bolus wizard or Nightscout, and add a note detailing the meal time, type, and carb estimate.
• Do not bolus for the meal.
• Observe BG closely after the meal. If BG goes outside the acceptable range decided prior to the study, then correct as normal and end Phase 0 of the study.
• If BG remains inside the acceptable range, increase the snack/meal size for the next round of Phase 0 testing and repeat the steps above.

Phase 1 (conservative, assuming no COB):
Starting with a small snack:

• Make sure your CGM is calibrated, OpenAPS has been operating normally, and you do not have any COB or significant bolus IOB.
• 90 minutes prior to expected meal/snack time, set an Eating Soon temp target with a duration of 120 minutes.
• At meal/snack time, do not enter carbs into bolus wizard or Nightscout, but add a note detailing the meal time, type, and carb estimate.
• Do not bolus for the meal.
• Observe BG closely after the meal. If BG goes outside the acceptable range decided prior to the study, then correct as normal and end Phase 1 of the study.
• If BG remains inside the acceptable range, increase the snack/meal size for the next round of Phase 1 testing and repeat the steps above.

Phase 2 (more aggressive, assuming “typical meal” carbs)
Starting with a small snack:

• Make sure your CGM is calibrated, OpenAPS has been operating normally, and you do not have any COB or significant bolus IOB.
• 90 minutes prior to expected meal/snack time, set an Eating Soon temp target with a duration of 120 minutes.
• Enter the number of carbs you typically eat for a meal (this quantity should be constant across all rounds of Phase 2 testing, and may be higher than the actual number of carbs you plan to eat).
• Observe BG closely until meal/snack time. If BG goes below the acceptable range decided prior to the study, eat rescue carbs if needed and end Phase 2 of the study.
• At meal/snack time, do not enter carbs into bolus wizard or Nightscout, but add a note detailing the meal time, type, and carb estimate.
• Do not bolus for the meal.
• Observe BG closely after the meal. If BG goes outside the acceptable range decided prior to the study, then correct as normal and end Phase 2 of the study.
• If BG remains inside the acceptable range, increase the snack/meal size for the next round of testing and repeat the steps above.

Phase 3 (most aggressive, assuming “large meal” carbs)

• Repeat Phase 2, but when you set Eating soon, enter the number of carbs you might eat for a large meal. This quantity should be constant across all rounds of Phase 2 testing, and will be higher than the actual number of carbs you plan to eat for most of Phase 3.

2. Creating "Floating carbs" in DIY closed loop

Because many people are effectively doing unannounced meals - or unannounced carbs for corrections - and the loop is safely limiting post-carb spikes despite the lack of meal bolus, we theorize that it may be possible to do the following to further improve the outcomes in the time periods when there is carb ingestion :

• IF configured by the user
• AND there is a set time frame where carb consumption normally happens. (So, say 12-1pm and 5-6pm for most common meal times; but not if lack of data showing consistent carb consumption; this may be something that needs to be recommended based on CSF attribution from Iterative autotuning of basals and ratios #261)
• AND the user sets a pre-configured amount of (somewhat less than usual) carbs (example - if a standard meal is 60 carbs; set 45 to be safe - or maybe the algorithm will auto-adjust the amount it assumes for converting to a standing "floating carb" amount)

Then... set the pre-configured "floating carb" amount. If BG rises and it's during the time period, begin decaying the floating carbs and allow AMA to begin based on that amount. The usual safety caps for AMA apply (read more about AMA here: #68), so if the BGs flatten or start to drop, it will back off high temping and do low temping as needed, even if there are potentially undecayed floating carbs; and after a time period those floating carbs will vanish.

[scottleibrand]

One possible way to implement this might be to avoid guesstimating floating carb amounts (and trying to decay them), and instead just activate floating carb mode. That could be scheduled directly, as @danamlewis described above, but we may want to activate it for DIA hours after any "eating soon" style low temp target or bolus, and then either rely on some form of meal announcement (ES mode or bolus), or schedule recurring eating soon modes (or perhaps a higher and longer temp target) if we want to completely avoid announcements of any sort.

In floating carb mode, we could extrapolate the current deviations to continue into the future as we do with AMA today, but without AMA's ability to use COB=0 as a target for when to decay those deviations down to zero, continuing to extrapolate the current deviation indefinitely would likely result in slightly too much insulin delivery at the tail end of a meal. Instead, once deviations have started coming down from their peak level of meal carb absorption, we could project that the average rate of reduction of meal deviations over a 15-60 minute period would continue until the deviations drop to zero.

So in this scheme:

• If Eating Soon mode is activated before the meal, then that would trigger floating carb mode as well, and oref0 would be standing by ready to high-temp further as soon as positive deviations are observed.
• If a meal bolus (or pre-bolus) is delivered before/with a meal, that would also trigger floating carb mode.
• (If carbs are entered, that would turn off floating carb mode until those carbs have decayed. If another eating soon mode or bolus is entered after carbs have decayed and deviations have dropped to zero, that would trigger a new floating carb mode.)
• When BG starts to rise from the meal, deviations will start to increase. Once those deviations exceed the level of deviation seen over the last hour or so, then in floating carb mode they will be projected to continue for a full DIA hours into the future. If that results in the minimum predicted BG exceeding the maximum BG target, that will trigger AMA to start high-temping accordingly.
• Once deviations peak, and the current deviation drops below the deviation from 15-30 minutes ago (or 30-60 minutes ago), then the future deviations will be projected to decrease at that same rate until they hit zero (or for DIA hours if they don't). If this reduces the minimum projected BG sufficiently, then any high-temp will be reduced or canceled. If it reduces the eventualBG sufficiently, then oref0 will begin low-temping accordingly.
• If deviation increases again, but remains below the 30-60 minute prior level, future deviations will continue to be projected to decrease at the rate they decreased from 30-60 minutes prior. If the deviation exceeds the 30-60 minute prior deviation, then, as during initial ramp-up, future deviations will be projected to continue at the increased rate for DIA hours, until observed deviation begins decreasing again.

Some testing of this scheme will be required to determine whether it would work well using temp basals, as described above, and/or using supermicroboluses (SMBs) as described in #262, but it could likely be implemented to work in both modes. Depending on testing results, some additional limitations on projected deviations may be warranted, or we may find that properly configuring the current limitations on maximum safe basal rate, maximum IOB, etc. are sufficient.

[tim2000s]

Given the time it takes the Medtronic pumps to deliver a bolus, is there a great deal of difference between an appropriate TBR over five mins and a supermicrobolus, other than safety considerations on max safe basal rate?

[scottleibrand]

The biggest difference is that MDT pumps will let you administer a microbolus, but won't let you set a temp basal of less than 30 minutes.

[scottleibrand]

In order to skip carb entry, we'll need autotune to exclude periods with unannounced carb absorption from being used to tune basal or ISF. A simple algorithm that probably would work for that would be to simply exclude BG data from time periods where netIOB is high (maybe greater than 1 hour worth of basal), as well as however long after that it takes for deviations to drop back to zero (as we do when attributing BG data to CSF). Trying that approach out in the autotune-uam branch (commit 42c6141)

[scottleibrand]

Opened #417 to track the autotune-uam stuff.