Comments (9)
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.
Related Issues (20)
- Update install script urls to use https protocol as git is deprecated HOT 3
- Autotune : Important increase of basal rates due to always categorize uam as basal
- Go can't get ecc1/medtronic due to undefined: unsafe.Slice HOT 3
- Excessive limitation checks and logging when Custom Peak time below limit of active insulin curve HOT 8
- rT not completely converted for mmol/L units HOT 2
- problem with undefined: unsafe.Slice in oref0-setup.sh script HOT 7
- Tick format HOT 2
- does sensitivityRatio get checked against profil.autosens_max and ...-min HOT 1
- autosens munges the carb sensitivity HOT 1
- Possibly-incorrect sensitivity used in forecasts HOT 1
- Failing to get BG from railway/nightscout HOT 11
- Bolus snoozes zeroTemp functionality still active? HOT 5
- "Couldn't install openaps w/ nogit" during initial setup HOT 1
- It hangs out at Starting Kernel..... HOT 8
- skip_neutral_temps prevents SMB's before full hour? HOT 13
- COB ratio capped at 1U:3gr HOT 3
- autotune fails if any day in a range has no readings
- Donβt cancel a high temp due to lack of BG data if the temp has been running for less than 10m
- Autotune Insulin and Carb Sensitivity at different times of day. HOT 3
- Problem with autotune HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oref0.