-
Notifications
You must be signed in to change notification settings - Fork 396
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
Basal tuning and ratio estimation #99
Comments
Redirecting/extending this idea: We can do this real-time (i.e. dynamic tuning) and not just as a one-off.
Per @bewest showing recently how to append, we should be able to add small files to make it easier to do this longer time series. We may be able to do something like create a basal file where OpenAPS can write the basal rates by hour to this file, and then pull from this file (and any calculations adjusting these rates will update the file) for then calculating the needed temp basal rates at that time based on BG changes. If it can't read from the file (i.e. offline mode), it'll revert to the pump-programmed basal rates as it does now. (Thing to think about, though, will be what the adjusted calculated rates do in terms of calculating netIOB, if anything?) Per @TC2013 and @Sulka, this should help us improve basal adjustments for people with widely varying sensitivity and basal needs over the course of the day, whether it's an adjustment on a per-day basis (i.e. sick day, bad pump site day), or a weekly basis (i.e. growth/hormone spurt/change). This can also be a tool that can be run before people start looping, as a way to look at suggestions for adjusting their existing basal rates as part of the open loop/before looping process, since it'll just require to read the data and that is already being done at the beginning of the loop build process. |
More detailed algorithm for implementing this:
|
Figured out how to use |
To download historical and glucose data from Nightscout:
|
This mongo map/reduce script from @sulkaharo might be a good way to handle the processing instead of trying to do it all locally on the edison https://gist.github.com/sulkaharo/18d4b06c1288a0b14da48e7a5cd46d87 |
One note I had observed is that to get enough data to build a day can be a challenge. There are actions that can enhance this too, and a system that indicates what has been fulfilled in the last time period could help. However, the following observation helped too. Once one find the rough doses for basal, the changes are often global and not localized to that time period. So that lets one use night times when you are fasting as an indicator of potential changes needed. |
(For anyone following this issue, 99, you may also want to keep an eye on 261 (#261 (comment)) which is where we are working on iterative autotuning using some of the framework described here, but may ultimately achieve both one-off basal tuning and/or more iterative ongoing tuning adjustments. |
Is there anything left to do here? Or does #261 resolve this? |
Per the discussion in #58 and many preceding and subsequent discussions in various fora, it would be very useful to implement an algorithm to provide suggestions for tuning a user's current basal schedule, insulin sensitivity factor (ISF), insulin to carb (IC) ratio, and duration of insulin action (DIA).
To do so, we could use the OpenAPS automatic sensitivity detection algorithm to calculate, for each 5m data point, how much BG deltas deviated from what would’ve been predicted based on net insulin activity (relative to current schedule basals) and the user's current ratios.
For each carb entry, we can determine the sum of subsequent positive deviations (above a threshold used to detect when carbs are absorbing, perhaps 0.5 mg/dL/min). This can then be directly compared to the carb estimate to get a carb sensitivity factor (CSF, units of mg/dL per g), which can be combined with estimated ISF (units of mg/dL per U) to get IC ratio (units of g per U). (Note: while it would appear that this relies on correct carb counting, it actually does not. If the user's carb counts are biased high or low, the resulting ratios will essentially correct for that, resulting in what you might call perceived-carb ratios.)
To calculate ISF/DIA and tune basal schedules, we need to first exclude any data between carb announcement and 15-30 minute after the last carb absorption is detected. We can then bucket the remaining data points according to whether their insulin activity is dominated by boluses / high-temps or by basal insulin. The former can be used to calculate ISF, and the latter to tune basal schedules. We can initially assume that ISF is constant, and then come back and fine-tune based on time of day or day-to-day variation, assuming we have sufficient data, after we’ve tuned basal schedules and DIA.
To calculate ISF, we need to take the subset of data with no carb absorption whose insulin activity is bolus / high-temp dominated as described above, and perform a parameter estimation function to solve for ISF. One simple (but maybe not ideal) method to do so would be to perform a simple goal seek algorithm, recalculating the deviations for each new ISF to find the ISF that converges on a median or mean deviation (for this subset of data) of zero.
To determine the best DIA, we want to select the one that minimizes the sum (or perhaps the RMS?) of all the deviations, in order to choose the insulin curve that best fits the actual observed insulin activity profile over time. This parameter could be estimated from the same subset of data used to estimate ISF, using simple goal seek or more sophisticated parameter estimation methods.
To tune basal schedules, we can use the data points whose insulin activity is dominated by basal insulin (where net IOB is small), bucket the data by time of day, and look at the BG deviations for the timeframe ~90m later. (So for a 12am-2am basal, the deviations of interest would be for 1:30am-3:30am.) To determine how far off the schedule basal is for each time bucket, we can divide the previously-estimated ISF (mg/dL per U) by the median deviation (units of mg/dL per hour) to get a basal offset in U/hr.
The text was updated successfully, but these errors were encountered: