oref0
oref0 copied to clipboard
openaps
Add Initial Delay to insulin model timing
[stealing Dana's proposal format] Proposal: [stolen from FB comment by Katie] Insulin doesn’t start to work immediately from a bolus command. It has to be fully delivered, actually absorbed into the tissue and then finally start to work. There’s a bit of delay in that process. If your exponential curve expects insulin starts working at t=0, but it really isn’t, that may yield some deviation calculations/comparisons that are less than optimal.
Related code: @Kdisimone has done this in a Loop branch. https://github.com/Kdisimone/Loop/commit/8a383de812d15b5ac5bd2e2622aa5903b7151e96
Proposed default delays: 10 min for ultra-rapid, 20 min for rapid-acting & bilinear.
This needs to be an optional feature to start (with preferences).
InsulinDelay: (default no; if yes, use delay) InsulinDelayMinutes: (default as above, based on curve; if number of minutes specified, use number)
This is already baked into the insulin activity curves in the form of the peak time. If we do this we’d need to make sure we don’t shift the peak time, which would mean it would just make the initial ramp steeper, from t=10 to t=50 or so...
I’m not really sure this is necessary. You start absorbing insulin immediately on injection, but as Scott says, the peak action occurs at peak absorption. All the curves from which we’ve built the algorithms are based on the manufacturer curves that come from measuring glucose infusion after injection so adding any form of delay is always going to be arbitrary.
I know this functionality in Loop has helped @Kdisimone . I'm trying to figure out ways to reduce zero temping. The bottom line is that while OpenAPS works great for my kid at night when only basals are involved, when carbs enter the picture, her numbers are worse than pre-looping. When her rig isn't looping for whatever reason during the day, her numbers are better. I am leaning towards disabling the loop during the day (by changing temp basal type on the pump).
I’m unclear why you’d think it would reduce zero temping? Having a delay just postpones the point at which the slope increases. You wouldn’t add more insulin as a result.
What investigation have you done into your daytime issues?
I thought the idea was if the system doesn't register the insulin on board during the initial delay, it won't zero-temp as soon. I've tried autotune suggestions but those almost always recommend lower basals, which doesn't make sense to me. So I generally increase basal rates looking at graphs as I would have done in the past. I've increasd the smb/basal increases allowed and extended the peak time.
I think it's incredibly dangerous to have insulin delivered that isn't recognized as such. Is it possible that basal rates are being used to compensate for an insufficient carb ratio? Do BGs stay relatively flat in the absence of food? Does a correction dose bring BGs down properly? An incorrect ISF can also cause strange behavior with respect to temp basals.
FWIW, I’ve had much better post-meal looping with the insulin delay added in. Change the shape of the insulin curve, and you change the calculations of deviation. So it does make a difference. And insulin does not start working at t=0. That inflection point being shifted out from t=0 is more realistic...and closer to real, I’ve found, the less my brain fights looping recommendations and smoother my results have been.
Yes BGs are great w/o food. Carb ratio has gone up (down?) to 5:1 since using system - more insulin and she tends to go low. But less and she shoots up.
I want to be able to try the delay but we don't use Loop. And I lack the skillz to make my own branch.
If you change the shape of the insulin activity curve to stay flat at zero activity for a longer period before ramping up to peak activity, IOB will stay at the initially bolused level during that time and won't start dropping. It sounds like @davidwagaps is trying to solve a different problem, which is that your response to carbs is faster and/or larger than OpenAPS initially predicts (before it sees evidence of carb absorption). If you flatten the first few minutes of the curve, that will have some effect, but I don't think you can make a direct inference that the effects that has in Loop would be what it would do in OpenAPS. In Loop, you can handle the underlying carb-timing issue by adjusting the entered carb absorption time of the food, whereas in OpenAPS the "remainingCI" effects are mostly hard-coded, and then it shifts over to assuming actual observed deviations will continue once carb absorption picks up.
https://github.com/openaps/oref0/blob/dev/lib/determine-basal/determine-basal.js#L461 is where determine-basal conservatively sets the initial carb absorption peak to be 3 hours before it sees carb absorption data to indicate it's absorbing faster than that.
IIRC @scottleibrand, the carb absorption model in OpenAPS is also pretty close to the experimental models that have been created based on measurement of carb absorption in people?
I would say Loop's model is closer to the carb absorption curves from the literature, and OpenAPS uses a more adaptive model that starts with some simpler assumptions but more aggressively adjusts for observed conditions. Even with dynamic carb absorption, Loop tends to defer more to the initial assumptions (from the literature curves, adjusted for the user-entered carb absorption time), whereas OpenAPS adjusts more to observed deviations.
The iob being there is different than the insulin activity while iob is present. If there’s no insulin activity (even with iob at t=0 plus a slice) then you will get less of the suspended-basals-during prebolus-before-insulin-actually-starts-working.
It does make a difference.
I cringe a little about statements comparing the algorithms without thorough write ups on each.
Yeah, further generalizations probably aren't very helpful here. One thing that would be helpful is to take a look at the contents of the pump-loop.log to see what exactly determine-basal was reporting during the exact minutes when oref0 was unnecessarily zero-temping after a bolus. Most of the variables that affect that are printed in the pump-loop.log output, so we can determine what was going on. There are a number of settings that can be incorrect and cause post-bolus low temping, but if those are all correct, the two hypotheses in this thread are 1) that carb absorption was slow to pick up, which could be addressed by shortening the remainingCATimeMin if you want oref0 SMB to be more aggressive about bolusing for carbs it hasn't seen active yet; or 2) that carb absorption was occurring, but was masked by a too-early rise in insulin activity (and too-negative BGI), which could be addressed by changing the insulin activity curve in some way. One thing that would be easy to do there would be to lengthen the insulinPeakTime with useCustomPeakTime: http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html#usecustompeaktime . The other option would of course be the original suggestion, but that requires more coding. @Kdisimone do you have a link to the commit/code that actually uses your initialDelay inside ExponentialInsulinModel?
In Loop: https://github.com/Kdisimone/Loop/commit/08935ba8378e0f7149ba0d40f734e832f440516a
In loopkit: https://github.com/Kdisimone/LoopKit/commit/864707a0311381351dc110c442cf7f63732df7ca
Thanks. Just eyeballing the diff, it looks like you're replacing all instances of time with (time - initialDelay), which effectively shifts the entire insulin activity curve to the right by 10m for Fiasp, or 20m otherwise. Is that correct?
If so, then my guess is that most of the effect of that change is from shifting the insulin peak time to be 10-20m later. @davidwagaps since in OpenAPS the insulinPeakTime is a variable exposed in preferences.json, you might try changing that first, as that should do much/most of what @Kdisimone's change does in Loop, before deciding whether any code changes are needed.
If the insulin timing is presumed to match the timing curve straight out of the literature, then there's another source of time delay not being accounted for: the CGM. Based on comparison of G4 raw data to G4 calibrated data, I'd say there's about 10min of latency just in the de-noising process it uses, plus probably about 5min of latency in the chemistry. Other CGMs may vary.
If the real reason the timing is off is because of CGM latency, then the correction should be the same for all types of insulin.
