Wrong IOB Calculation for MDI users

[mdomox]

ΙΟΒ does not calculate correct value when changing treatment profiles with different insulin age value. This occurs in every browser and platform.

1. Create a treatment profile with insulage age 6 hours (profile Humulin)
2. Create a treatment profile with insulin age 2 hours (profile Novorapid)
3. Use profile Humulin. Insert bolus value
4. After 2 hours change profile to Profile Novorapid.
5. Nightscout will calculate IOB, as if the insulin age was 2 hours from the beginning....

[PieterGit]

@mdomox Some questions to get the issue clear:

• Am I right that you're not using an APS system (openaps/oref0/loop/AndroidAPS) and only use Nightscout for viewing your viewing your CGM.
• What pump do you use, and do you sync your pump with Nightscout, or only add manual treatments in Nightscout

Most people use IOB calculation from the APS. Nightscout IOB and BWP use simpler algorithms than those APS'es.

Setting this issue for the 0.11.0 release, because I think it won't be solved in the 0.10.3 scope.

[mdomox]

@PieterGit Thank you much for your response. I use Nightscout for viewing CMG data (Freestlye Libre), manually inserting carbs and insulin doses. Not using a pump, but I find the bolus calculator very helpful.I also use it to view IOB, COB ,share data to the doctor and remotely monitor my kid's glucose levels (fyi, till recently I was also using the GoogleHome - API.AI integration which was broken after the last release)

Is there a way to use an APS system you mentioned since I do not use a pump?

[MilosKozak]

AndroidAPS and virtual pump

[mdomox]

@MilosKozak , AndroidAPS has to be installed on the same smartphone as xDrip/Glimp?

[PieterGit]

@mdomox Can you give an update if this issue is still relevant? Since AndroidAPS runs on Android I would install it on the same phone as Xdrip Plus. Please tell me if you have additional questions. Removing 0.11 milestone, since I'm thinking this is not a bug, but a question of how to use Nightscout.

[mdomox]

@mdomox Can you give an update if this issue is still relevant? Since AndroidAPS runs on Android I would install it on the same phone as Xdrip Plus. Please tell me if you have additional questions. Removing 0.11 milestone, since I'm thinking this is not a bug, but a question of how to use Nightscout.

@PieterGit Of course this is still relevant. Using AndroipAPS does not solve it. It has to do with the fact that IOB is calculated using insulin age as a globall system/profile attribute not per treatment (in cases where different insulin types are used). Each treatment should have the insulin age curve as an attribute, calculate the decay of the insulin of the treatment and determine the treatment IOB . The overall IOB to be calculated by adding all treatment IOBs that are >0 .

For example, right now if I use Novorapid (that has a specific decay curve) and after 2 hours I use Humulin (that has a totally different decay curve) , the IOB shown is wrong because it will use the Novorapid decay curve and DIA for Humulin. If I change the settings after I use Humulin to use the Humulin decay curve and DIA, it will still be wrong, because the system will use the Humulin decay curve and DIA for the Novorapid that was done 2 hours before.

So, each insulin treatment should have its own decay curve (DIA, etc) and the total IOB should be IOBt = IOB1 + IOB2 + ... + IOBn

I presume that something similar should be considered for carbs also. Carbs with low glycemic index have different absorption rate than carbs with high glycemic index.

[PieterGit]

@mdomox The IOB calculation within Nightscout hasn't been touched for 3-4 years, see https://github.com/nightscout/cgm-remote-monitor/blame/7c272ec67a7795e0f4edf7ff9abdfac1bd1308a0/lib/plugins/iob.js#L189-L207

All APS'es use much better algorithms for calculating IOB now (including FIASP), see https://github.com/openaps/oref0/issues/544

So I think there are 3 options for Nightscout IOB:

1. We remove the IOB calculation from Nightscout, and see it as an APS responsibility. Perhaps AndroidAPS with Virtual Pump has some kind of method that you can use the IOB calculation even without a pump. This will also solve wrong IOB results for OpenAPS users, see https://openaps.readthedocs.io/en/latest/docs/Troubleshooting/Rig-NS-communications-troubleshooting.html?highlight=iob%20pill#nightscout-info-incorrect

2. We upgrade and fix the IOB calculation withing Nightscout. In 0.11 to fix this issue, and in Nightscout 0.12 to include FIASP and to use the modern algorithms.

3. We remove the IOB pill altogether, and IOB is only showed with the OpenAPS / APS pill. Non pump users should use a VirtualPump with an APS to see IOB within Nightscout.

I think I would prefer option 1 or 2. In both cases the change should be created in the next 2 weeks (including documentation), so that we can test it for all cases and still release Nightscout 0.11 in December.

@jasoncalabrese @scottleibrand @sulkaharo @mddub @MilosKozak @warstar2187 @danamlewis Thoughts?

[scottleibrand]

Options 1 or 2 work for me. I’d strongly vote against 3: the IOB pill is far easier to read than having to mouse-over or tap the OpenAPS pill to see IOB.

Scott

On Nov 3, 2018, at 1:30 PM, PieterGit notifications@github.com wrote:

@mdomox The IOB calculation within Nightscout hasn't been touched for 3-4 years, see https://github.com/nightscout/cgm-remote-monitor/blame/7c272ec67a7795e0f4edf7ff9abdfac1bd1308a0/lib/plugins/iob.js#L189-L207

All APS'es use much better algorithms for calculating IOB now (including FIASP), see openaps/oref0#544

So I think there are 3 options for Nightscout IOB:

We remove the IOB calculation from Nightscout, and see it as an APS responsibility. Perhaps AndroidAPS with Virtual Pump has some kind of method that you can use the IOB calculation even without a pump. This will also solve wrong IOB results for OpenAPS users, see https://openaps.readthedocs.io/en/latest/docs/Troubleshooting/Rig-NS-communications-troubleshooting.html?highlight=iob%20pill#nightscout-info-incorrect

We upgrade and fix the IOB calculation withing Nightscout. In 0.11 to fix this issue, and in Nightscout 0.12 to include FIASP and to use the modern algorithms.

We remove the IOB pill altogether, and IOB is only showed with the OpenAPS / APS pill. Non pump users should use a VirtualPump with an APS to see IOB within Nightscout.

I think I would prefer option 1 or 2. In both cases the change should be created in the next 2 weeks (including documentation), so that we can test it for all cases and still release Nightscout 0.11 in December.

@jasoncalabrese @scottleibrand @sulkaharo @mddub @MilosKozak @warstar2187 Thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mdomox]

@PieterGit OpensAPS does IOB calculations in Virtual Pump mode, but also handles decay curves and DIA in a global manner (global attribute), not per treatment. So, the same issue is founbd in OpenAPS. The issue is that, when not using a pump, different insulin types with different insulin decay curves and DIA can be used from treatment to treatment (ultra fast, fast, medium, long) and this is not supported neither in OpenAPS. When using a pump, one type of insulin is administered though, so the current situation is acceptable.

Support of no pump users is minimum in AndroidAPS.

I raised this issue in OpenAPS community, and the impression I got is that OpenAPS is focused on pump users who they use one type of insulin. Not great interest on supporting non pump users. Maybe I am wrong.

[mdomox]

I would go with option 2. This would drive necessary enhancements in FOOD usage and an improved calculator that could seamlessly be integrated into Google Assistant and Siri/Alexa.

Option 1 seems to be the best case scenario only in case this issue is fixed within AndroidAPS and Nightscout and AndroidAPS come in bundle. Whoever uses NS must also use AnroidAPS.

[PieterGit]

@mdomox A bit off topic: On not supporting MDI (non pump) users: I think the #WeAreNotWaiting focuses on using technology for all people with diabetes. On the other hand I think most Nightscout users use a pump instead of MDI. The last releases we found out that we have quite some parts of the code that are not well known and not always maintained. Having code that is used by a lot of users and is not maintained is not good, examples: Azure hosting, svgdata and share2nightscoutbridge. So it's not that we are not interested in no pump / MDI users, but I think we currently have less MDI users that are contributing to Nightscout and time we can invest in improving Nightscout is limited. If you can change that by doing a lot of contributions and bringing more MDI users, please do 😄 .

On Topic: So I think we can agree on option 2 route. The removal options in 1 and 3 are mainly based on "better to remove stuff that has errors and is not well maintained in order to prevent wrong information". IOB and COB calculations should always be implemented correct and be maintained, from a safety perspective.

For 0.11 we need some small fixes. For 0.12 then we should implement the new/same alogrithms (and FIASP) as used in the APS'es (reuse). They should be implemented in either Nightscout iob/cob modules or some implementation of a Virtual APS for MDI users. It's up to the contributors to choose whether they will implement that as a plugin/module for Nightscout or integrate it with AndroidAPS.

[LongboatAline]

I think this may be one of the cases where the data model would profit from adding the type of insulin curve to use for the decay of the insulin in question. Not only would it allow to calculate a reasonable approximation of IOB (and Acting Insulin) for users of MDI, it would also allow to cover uses of different Insulins for pump users as well.

Incomplete list of use cases where more than one insulin is used:

• MDI (well, obviously)
• Pump users (and loopers) might want to use an additional basal insulin when going untethered, (sauna, swimming, other situations where they'd prefer a long acting insulin to a manual dose every 2-3 hours).
• Pump users using a slower insulin in their pump, such as Insuman Infusat, might use an additional fast-acting insulin to speed up corrections, or to cover meals with a high glycemic index.
• MDI users might use more than 2 insulins, for example an NPH insulin to cover Fat/Protein based meals.
• Either might occasionally use Insulin i.v to bring down a too high BG quickly.

In an ideal world, no matter what kind of mix we're dosing, we could just tell the loop, and it would figure out how to carry on. For starters, I'd be happy if the data model wouldn't prevent it from calculating a realistic and consistent amount of IOB and Acting Insulin.

I'm just worried that there's quite a few projects to coordinate when it comes to somthing as deeply rooted as the underlying data model.

[sulkaharo]

Some notes:

If we do port the IOB algorithm from OpenAPS over, we can simultaneously add the capability to define the DIA per treatment, so someone marking down long-acting treatments could mark down a 18 hour DIA. I'm not sure where we'd get the insulin curve data from though - someone would need to read through the data published on the longer insulins and figure out what DIA really is appropriate. This would probably also lead to discussions around what DIA is actually correct to implement, where OpenAPS is now enforcing a minimum of 5 hour DIA for fast-acting insulins given we know the actual action time is at least this long.

Second - the implementation will need to also be able to take temporary insulin profile changes into account, same as all the looping systems, which also means the IOB value correctedness will be dependent not only on all boluses having been marked down at the right moment, but also that the profile data is correct.

[PieterGit]

Postponing to a TBD release. It seems nobody is interested or has time to implement this feature. If this issue does not get attention before the 0.13.0 release, I will close it next time and label it: closed-due-inactivity