Advanced Meal Assist using COB estimated from post-meal deviations about oref0 HOT 9 CLOSED

I have no doubts that meal assist could be improved by explicitly including awareness of carb absorption rate. What you are describing makes sense, except I am not sure about extrapolation of the impact of carb absorption using the current rate. We do know that carb absorption will start decreasing and will eventually drop to zero. The questions are when and how quickly. How about this: model carb absorption as a triangle - ramping up as a linear function of time, reaching a max at some point t1, and then decreasing as a linear function of time to zero at some point t2. I think you are using the same type of simple piecewise linear model in IOB calculations? Except, for insulin we presumably know what t1 and t2 are, and for carbs we do not - these depend on the type of meal and also vary from person to person, and even time of day. But, following your reasoning above, it may be possible to continuously update estimates for carb t1 and t2. Then, based on the estimates, temps could be calculated to: (1) equalize the projected areas under the insulin triangle and the carb triangle, so that eventually we return to the starting bg (which is what oref0 is essentially already doing), and, in addition, (2) minimize the max of the difference between the two triangles in order to minimize the post-meal bg variation (this requires knowledge of carb t1 and t2). Ideally, if the insulin and carb triangles were perfectly matched, one could have a meal with flat bg (I can sometimes do that, on very good days :)). An initial estimate for carb t1 and t2 could come from the user's bolus wizard input - the fraction of the meal bolus delivered up front. A smaller fraction would imply slower carbs are expected. In the (simplest) case when the entire bolus is delivered up-front, oref0 actions should amount to what is commonly referred to as "super bolus" - borrowing up front from future basal, so high temp up front followed by zero temp. In any case, the meal-assist algorithm should also allow the user to take advantage of pre-bolusing (it is otherwise impossible to match the insulin/carb triangles).

from oref0.

I am explicitly not making any assumptions about carb absorption ramping up over time. Instead, I want to wait until carb absorption ramp up has been observed, and then assume that will ramp down over time. That has a lot of safety benefits in the case where a meal is not fully consumed, where something (walking home, gastroparesis, or whatever) reduces carb absorption rate more than expected, or where the meal is lower-GI or fewer carbs than estimated.

We could, however, do something like the second half of your algorithm, assuming that absorption will decrease linearly as a function of time, and just set t1 to "now". The model I've proposed only projects absorption of half of the remaining carbs, so an equivalent linear decrease model would be to set t2 to be the point at which all remaining COB would be absorbed at the current rate. By projecting linearly-decreasing carb absorption from now until then, you would equivalently project that half the carbs would be absorbed, but the absorption would be a triangle rather than a rectangle of equal area. That would make the algorithm slightly more sensitive to lows projected to occur while carbs are still absorbing, which might be good.

With regard to matching the shapes of the insulin and carb triangles (curves), I am much more inclined to design our advanced meal assist algorithm to optimize for safety, rather than trying to achieve perfectly flat BGs based on assumptions about carb absorption increasing in the future (which would turn out incorrect in many cases). I would rather leave it up to the user to do an early pre-bolus and properly sized meal bolus. If we wanted to, we could build an advanced bolus wizard that helps the user select the optimal timing and sizing of pre-boluses and meal boluses, but I don't think those should be performed automatically without the user's explicit approval. I also would prefer to encourage safe early pre-boluses (setting BG target to ~80 and correcting to that up to an hour before a meal) rather than super boluses, as that preserves the maximum safety margin for low-temping if carb absorption slows or stops for some reason.

from oref0.

It's also worth noting that we have used a model similar to what you described, but with a rectangular instead of triangular carb absorption curve (zero for 20m, then a constant 30g/hr until all carbs are absorbed) in DIYPS. That system does recommend meal boluses for the carbs projected to absorb by the time any insulin bolus reaches peak activity. That has worked quite well for @danamlewis, but it is tuned to her particular carb absorption profile, and I am very reluctant to make the assumption that others' carb absorption will be similar, because anecdotally we have seen dramatic variance between individuals, diets, and even individual meals. So I am much more inclined to assumptions about carb absorption that don't exceed the currently observed absorption rate, as that creates built-in protection against the model being too aggressive about how fast carbs are likely to absorb.

from oref0.

Agreed, yes - safety should remain the top priority, although would be nice to leave some room for users to tweak parameters and adjust aggressiveness. For example, not sure about "~half the remaining unabsorbed carbs." If carb absorption is exceeding insulin action, as evidenced by increasing bg, why not assume that the user was actually correct when entering carbs up front, and high temp based on the entire unabsorbed carbs? Or, this fraction could be a parameter, with a default safe value of 0.5.

from oref0.

Yeah, that would be a good thing to make configurable, with a reasonable safe default that would work for most people. Maybe combine both ideas with wtf-assist so that it only phases in the higher user configured value to the extent that BG is rising quickly.

from oref0.

Yup, that sounds good!

from oref0.

The code in the advanced-meal-assist branch is now successfully implementing a version of the algorithm described above. Still needs more testing before we use it to actually set temps, but while running in parallel during dinner today it seems to be making sensible recommendations.

from oref0.

Have now been testing this in production for a few days, and it works as well or better than the old meal assist algorithm in all situations we've seen so far. Still want to fix some corner cases as outlined in other open issues, but I think this is ready for broader testing.

from oref0.

Making a note about the link for people to walk through setup: https://github.com/scottleibrand/openaps-sh/blob/advanced-meal-assist/setup.sh

from oref0.