AndroidAPS
AndroidAPS copied to clipboard
nightscout
Approach for calculating insulin dose by CR and ISF only
In the current AAPS model, the ISF, IC values are determined by the user, and CR is calculated by the program by constantly changing it.
CR (mmol/(l*g)) can be interpolated as the change in mmol/l by which the glucose concentration in blood volume will increase when a fixed amount of glucose in grams in dry form is added in the absence of active (bolus) insulin on even background (basal) insulin. In this case, while blood volume is conserved, CR will also be a constant (with some assumptions, described below).
Then knowing ISF and CR would be sufficient for insulin I dosage calculations, IC would be unnecessary: I = (CR*C + glucose_start - glucose_target)/ISF - IOB_start
The calculation is done in two steps:
- From CR, the mmol/L increase from carbohydrates without insulin is calculated.
- ISF is used to calculate how many units of insulin are required to lower the sugar.
Example. Initial sugar - 6.3 mmol/L Target - 5 mmol/L ISF = 2.8 17 grams of carbohydrate at CR = 0.3 will raise the sugar by 5.1 mmol/L from baseline.
- 6.3 + 5.1 - 5 = 6.4 mmol/L must be compensated for.
- 6.4/2.8 = 2.3 units should be injected when there is no other insulin than basal insulin.
Since the calculation of CR is reduced to the problem of dissolution of a substance in a liquid, CR can be calculated as follows: CR = A/(WeightK/1000), where K is the coefficient for calculating blood volume, depends on BMI, age. Weight is measured in kg. WeightK/1000 = circulating blood volume, liters A is a coefficient for converting grams of carbohydrates that enter the blood in the form of glucose into mmol/L (empirically, it is equal to 0.75 on average for different ages).
For example, height 1.67 meters, weight 58 kg, age 18+
BMI - 20.8 is normal.
K - 65 (according to the table)
Blood volume = 58 * 65 / 1000 = 3.19 liters
CR = 0.75 / 3.19 = 0.24
Direct exact calculations give a slightly different result: The molar mass of glucose = 180 g/mol. So 1 g of glucose is 1000/180 mmol = 5.5555 mmol. CR = 5.555/3.19 = 1.74 mmol/(g*l).
But insulin-independent tissues (Liver, brain, kidneys, heart, red blood cells and nerves) metabolize most of the glucose on their own, and only muscle and adipose tissue require insulin, which is no more than 30% (when the percentage of muscle and fat relative to total body weight is normal). Therefore CR_max = 0.3 * 1.74 = 0.51. But due to various factors, this value is usually 2 times lower.
These are the following factors:
- when there is a deficit in carbohydrate intake, it will mostly go to the liver without insulin,
- in hyperglycemia, some will be excreted by the kidneys without insulin,
- in type 1 diabetes there is residual insulin secretion (c-peptide is not zero), so about 5-15% of glucose can be taken up by the surviving beta cells,
- the brain can use more glucose with increased intellectual exertion,
- when muscle mass is deficient, muscle and fat do not require as much glucose as in athletes and overweight people,
- the less often and less carbohydrates are eaten, the more of them are stored in the liver and less of them will enter the blood. That is, if there is a deficiency of carbohydrates, CR is lower. If excess - higher, because when overeating, all insulin-independent organs are overfilled with glucose, and it begins to accumulate in the fat tissue (with the help of insulin) until the excess glucose in the blood disappears.
I'm probably not skilled enough in this area. Can you point me to the code you want to change?
I'm probably not skilled enough in this area. Can you point me to the code you want to change?
I have not studied the AAPS code, except for the prediction model itself. I assume that you need to adjust the Profile section, where the IC tab is replaced by a CR tab with the ability to calculate and change it. At the same time ISF, basal insulin rate remains. And also I need to correct the module itself to calculate insulin doses, according to the formula I specified in the first topic.
The experimental formula for calculating CR is not mine, so I wrote to the developer of the program InsulinSensitivity. This program uses empirical CR and predicted ISF (by type and duration of activity, meal time, age of cannula, day of female cycle) to calculate insulin doses. The author himself successfully combines the doses selected by InsulinSensitivity and AAPS.
For example...
(also not skilled enough in this area) Interesting. Applying these values for me, calculated CR (=1/IC) matches the (empirically derived) CR from my profile quite close. Difference is about +5%...
I'm a bit confused by acronymes that seems to be not standard... In AAPS doc (see https://androidaps.readthedocs.io/en/latest/Module/module.html#good-individual-dosage-algorithm-for-your-diabetes-therapy), CR (carb ratio) is grams carbohydrate per one unit insulin. So IC = CR = 2 acronymes for the same value and units are g/U.
What you call "CR" in your issue (if I understood correctly) is called CSF (Carb Sensitivity Factor) everywhere in AAPS doc (and code), and is the equivalent of the ISF (Insulin Sensitivity Factor) for carbs: how many 1g of carbs will rise BG value.
These 3 values are linked together: CSF = ISF / IC
If within profile you set ISF and CSF, then IC is calculated as the results of both values... IC = CR = ISF / CSF
But for most user It's much easier to provide ISF values (used to calculate a correction bolus when you are high), and IC values (bolus required for a meal with xx g of carbs) than providing a CSF value. (you never calculate anything when in hypo, you just take 10 or 20g of carbs to go back within range)...
I'm a bit confused by acronymes that seems to be not standard... In AAPS doc (see https://androidaps.readthedocs.io/en/latest/Module/module.html#good-individual-dosage-algorithm-for-your-diabetes-therapy), CR (carb ratio) is grams carbohydrate per one unit insulin. So IC = CR = 2 acronymes for the same value and units are g/U.
What you call "CR" in your issue (if I understood correctly) is called CSF (Carb Sensitivity Factor) everywhere in AAPS doc (and code), and is the equivalent of the ISF (Insulin Sensitivity Factor) for carbs: how many 1g of carbs will rise BG value.
These 3 values are linked together: CSF = ISF / IC
If within profile you set ISF and CSF, then IC is calculated as the results of both values... IC = CR = ISF / CSF
But for most user It's much easier to provide ISF values (used to calculate a correction bolus when you are high), and IC values (bolus required for a meal with xx g of carbs) than providing a CSF value. (you never calculate anything when in hypo, you just take 10 or 20g of carbs to go back within range)...
The thing about CSF is that it is constant and related to the dissolution of sugar in the blood. And it is enough to change only ISF in addition to the more stable CSF (mmol/(dl*g) - how much mmol/l rises at 1 g of carbohydrate intake) to make IC calculation. In the AAPS model, the CSF is variable, although it should not be, given its physical nature. I can't say how much better this model will give better results than the standard AAPS model, because I know only one person (the developer of the InsulinSensivity program for calculating ISF by activity, female cycle, meal time, and day of cannula wear) who uses it successfully, regularly changing the IC in AAPS so that the CSF is always the same.
In the AAPS model, the CSF is variable
I don't agree, CSF is not variable, it's just not defined directly so it's the result of ISF and IC defined within profile. So if profile has a single value for ISF and IC, or if ISF and IC are circadian but changes are in same proportion, then CSF can be constant...
I think a lot of users have circadian varition of IC value (bolus needed is generally highest for breakfast, lowest for lunch and with intermediate value for dinner), because it's quite easy to calculate or adjust IC value.
Concerning ISF. it much more difficult to adjust circadian values (so I think it's probably constant for most user within profile).
So testing if a constant CSF improve the situation is very easy (as a starting point you can for ex devide average ISF by average IC, and then use this ratio to calculate circadian ISF using circadian IC within your profile.
But in parallel you have more and more algo that tune isf value according to several variations (BG value, TDD, ...), using profile ISF value and custom factors (for ex AutoISF), or using external independant calculation (DynISF)... 🤔
Concerning ISF. it much more difficult to adjust circadian values (so I think it's probably constant for most user within profile).
From my experience, I have noticed that ISF can change significantly quickly (up to 50% of the previous value in the same time period) and is very much influenced by the type and duration of activity. Using the InsulinSensivity program (statistical methods), the developer was able to achieve up to 80% accuracy in predicting ISF, but 20% of the time it failed to predict its value (sudden, unpredictable change). I was able to achieve 90% accuracy using machine learning methods, but only for a week in advance, after which the model had to be developed from scratch. So for me the most difficult task is to determine the exact ISF at the current moment. The benefit of AAPS is that it smooths out the errors in the ISF calculation. But IC calculations are inaccurate because they don't take into account the initial sugar before a meal, and with dynamic ISF they don't change IC, forgetting that it depends on the insulin sensitivity of ISF and is not a constant (if CSF is considered a constant).
I largely agree with Philoul and do not see a benefit of changing anything. What I wrote in my paper "IC (carb ratio)..pdf, " (chapter 4.") ( in this repo: https://github.com/bernie4375/HCL-Meal-Mgt.-ISF-and-IC-settings ) is that people should determine and use their CSF to check plausible circadian patterns of both, their ISF and IC. - In the end, the user tuning and the dynamic features (dynISF, autoISF) will change the applied figures again. Inkalinka's description (1st comment above) should be of interest for an extended "profile helper" (or probably also for auto-adjusting loops that just want to work off things like body weight, TDD etc) but once we determined our profile and use dynamic features (and %profile adjustments for sports etc), we are beyond that PS: Changes in the algo would concern me. As you may know, I have been staying away from dynamicISF for a similar reason-
In latest dev, I think CSF (so carbs absortion speed) is directly modified by variable ISF (dynISF algo or AutoISF algo I'm currently testing (updated PR should be done soon for AutoISF)...
We have an increase of ISF on low BG value and a decrease of ISF on high BG value. I think we should either keep profiles values for carb absorption or adjust IC value the same way ISF is adjusted for cob calculation, otherwize this will slow down the absorption of carbs at low BG value (so risk of over estimation of remaining cob at low BG), or it will speed up carbs absorption at high BG, instead of keeping carbs absorption speed constant... my previous tests of autoISF was on a previous dev version (before merge of DynISF and OpenAPS SMB within one single profile), and Carbs absorption was ok. I just migrate today to an AutoISF version based on latest dev (including profile interface for variable ISF value), and today carbs absorption was too slow (seems to me about 2 times slower than before)... so way too agressive at low bg due to over estimation of cob. I'll continue my tests to confirm behaviour at higher bg...
In latest dev, I think CSF (so carbs absortion speed) is directly modified by variable ISF (dynISF algo or AutoISF algo I'm currently testing (updated PR should be done soon for AutoISF)...
We have an increase of ISF on low BG value and a decrease of ISF on high BG value. I think we should either keep profiles values for carb absorption or adjust IC value the same way ISF is adjusted for cob calculation, otherwize this will slow down the absorption of carbs at low BG value (so risk of over estimation of remaining cob at low BG), or it will speed up carbs absorption at high BG, instead of keeping carbs absorption speed constant... my previous tests of autoISF was on a previous dev version (before merge of DynISF and OpenAPS SMB within one single profile), and Carbs absorption was ok. I just migrate today to an AutoISF version based on latest dev (including profile interface for variable ISF value), and today carbs absorption was too slow (seems to me about 2 times slower than before)... so way too agressive at low bg due to over estimation of cob. I'll continue my tests to confirm behaviour at higher bg...
Agree. It is necessary to change the IC and ISF at the same time. In the meantime, the ISF changes dynamically, when there is no IC, which leads to inaccuracies in forecasts.
In FCL with autoISF, the very low ISF at low (but beginning-to-rise) bg is merely a measure to replace the former user bolus in HCL with a couple of very big SMBs. So that has nothing at all to do with any change in insulin sensitivity or carb decay .... If HCL users of autoISF mainly make use of the dura_ISF, there I could see that a lowered ISF at high bg values has to do with temp. insulin resistance. But the tuning of the duraISF_weight takes care of getting this right. Only in the case HCL users do not only bolus, but also try to work with exact carb absorption inputs, the ideas to dynamically adjust also carb decay (e.g. via the CSF route you seem to suggest). As I am in FCL with permanent cob=0, I cannot relate further to that, though. I guess what youz try to do would in my case impact the calculated carb deviations a bit, and would not bother me....