Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advanced Meal Assist using COB estimated from post-meal deviations #68

Closed
scottleibrand opened this issue Feb 11, 2016 · 9 comments

Comments

@scottleibrand
Copy link
Contributor

commented Feb 11, 2016

I'm not yet happy with Meal Assist: I think we need to switch to using an advanced meal assist algorithm that is aware of COB / carb absorption and can tell when to high-temp aggressively for carbs being absorbed, and when insulin activity is already high enough to risk going low, and we need to preemptively low-temp instead.

To accomplish this, we need to determine how many meal carbs have been absorbed, at any given point after a meal, so we know how much more of a rise we can eventually expect from the remaining meal carbs, and whether we can expect any dips as insulin activity picks up. This needs to be determined based on the actual observed effect on BG of carb absorption, not based on any assumptions about how fast carbs "should" absorb for any given meal. By doing so, we should be able to safely high-temp for ~half the remaining unabsorbed carbs, as long as carbs are currently absorbing fast enough to outpace insulin activity. If carb absorption is too slow for insulin activity and a low is projected to occur before all carbs absorb, we can instead low-temp until BG and/or deviation picks up sufficiently to make it safe to high-temp again.

To calculate carbs absorbed to date, we can sum up the 5m deviations, for each 5m period since the meal carbs were entered, to determine how much effect carb absorption has actually had on BG so far, and by using the IC ratio and ISF, determine how many carbs have been absorbed, and conversely how many g of COB are remaining.

We can then extrapolate that the current deviation (the current impact of carb absorption) will continue into the future until most of those carbs have absorbed. To simplify the calculations, I'll probably extrapolate the current rate until those projected deviations have accounted for half the remaining COB. (In reality, deviations tend to gradually return to zero as carb absorption slows down, but the simpler math should be sufficient for estimating the total area under that curve.) We can then use the projected BGI and deviations for the next few hours to determine the projected minimum and eventual BG. If projected minimum BG is below targeted min_bg (and below current BG), we can low-temp as needed to help bring that up. If projected minimum BG is above target (or above current BG), we can high-temp as required to bring eventual BG down to target.

@dm61

This comment has been minimized.

Copy link

commented Feb 11, 2016

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

@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented Feb 11, 2016

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.

@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented Feb 11, 2016

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.

scottleibrand added a commit that referenced this issue Feb 12, 2016
@dm61

This comment has been minimized.

Copy link

commented Feb 12, 2016

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.

@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented Feb 12, 2016

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.

@dm61

This comment has been minimized.

Copy link

commented Feb 12, 2016

Yup, that sounds good!

scottleibrand added a commit that referenced this issue Feb 26, 2016
scottleibrand added a commit that referenced this issue Mar 2, 2016
@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented Mar 2, 2016

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.

@scottleibrand

This comment has been minimized.

Copy link
Contributor Author

commented Mar 23, 2016

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.

@danamlewis

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.