Feature request: Extra insulin for meals with fat...

[rsilvers129]

CalcFatProtein.xlsx
These papers, and others like them, show that we actually need 42% more insulin for high-fat meals - not just a longer absorption time.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3609492/

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2901033/

Right where you enter meal carbs, you can optionally also enter fat grams. In settings, after "carb ratios," there is "fat ratios." I have found that this "42% more insulin" works out to 90% of the grams of fat needs to be treated as grams of carb. So if my "carb ratio" is 7.5 grams of carb per unit of insulin, my "fat ratio" is about 8.5. But, the insulin for the fat needs to be delayed 1-2 hours, and spread over 5-8 hours. So, there would also need to be a setting to set these two parameters. The app could internally handle this as simply logging a second meal 1-2 hours into the future of the carb meal, and with an absorption duration of whatever you set in preferences.

I have tested this technique, and it works. It has allowed me to eat a massive amount of sausage pizza without going over 180. I really think this is a big deal and the next step to being able to eat anything that other people can eat.

Enclosed is an Excel sheet that attempts to implement the formula.

[kellyisworking]

We've been big proponents of fat and protein carb equivalent counting. Daniel has had a lot of success personally splitting meal entries as you describe, although he does not see the need for a delay in entering the carb equivalents as @rsilvers129 describes, entering 5-6 hours for fat/protein works for him at the same time of meal.

I had originally mocked up a meal entry including fat/protein and fat/protein carb equivalent ratio around Dec 2016 based on a modified version of the Pankowska method that Daniel uses (he counts total calories of fat/protein and multiplies by a carb equivalent ratio). I'll attach those mockups here when I can dig it up. I initially thought it would be interesting for retrospective analysis of absorption modeling, and if this is possible, I imagine it is likely necessary to keep entry time as the time of meal. This may also require Nightscout (in addition to Loop) to accurately distinguish difference between the carb/carb equivalent entries.

If this is something that has some support, I'd be glad to offer a design hand. I see some major questions around the dynamic carb absorption, and the associated UI.

• Editing to add link to gitter conversation https://gitter.im/LoopKit/Loop?at=58409bc5444b3778767f8def

[rsilvers129]

I am not adamant about delaying the fat entry. I just found that with pizza and other high-fat meals, it doesn't help, and can only hurt, to have extra insulin at the start. Because in my experimentation I have only started to rise after 1-2 hours, I seemed good to log the fat as a future event. But, it probably is an unneeded compilation that can be addressed with a milder insulin-to-carb ratio and a longer duration on the fat absorption.

[dm61]

First, let me just thank you for opening this issue - I've been thinking about this for some time. I have zero doubts that the amount of insulin I need to take for a certain meal depends pretty strongly on the protein+fat contents of the meal. The "carbs" I've been entering into Loop over the past almost 2 years have really been "carb equivalents," with amounts and absorption times based mainly on past experiences, greatly enhanced by the phenomenally useful feedback provided by Loop's "Carbohydrates" screen.

As far as implementation of any "carb equivalent" enhancement is concerned, here are some basic principles I think we should consider:

1. The key point to think about is not how to dose insulin for a certain carb+protein+fat meal, but how to best enter such meal in terms of amount(s) of carb equivalents and absorption time(s).
2. Related to point 1, I do not think there is a reason to modify or complicate Loop's existing dynamic carb absorption or dosing algorithms. Any algo modifications could come on top of these existing foundations.
3. We should try to simplify Loop meal entries, not make them even more complicated. My sense is that most users do not bother to even change the default absorption time, let alone enter carb grams, and protein grams, and fat grams.
4. I do not think there are any carb-equivalent formulas that will work for everyone (YDMV). This would need to be individualized, but hopefully without introducing even more parameters a user would need to worry about.

Given the above, I think we have a few options we could think about in terms of implementation:

1. (my favorite): forget about formulas, just record the absorption patterns observed by Loop (which is what I've been doing by memorization). The user could simply tap on an expired meal entry (e.g. pizza) and store the absorption pattern observed as a meal type available for future use. Next time, this meal type would be available as a meal library choice, possibly requiring just a quantity adjustment, and Loop would automatically convert that into one or more meal entries with fitted amounts and absorption times. One might think this would require a confusingly large meal type library, but my experience has been the opposite: my guess is that fewer than 10 different meal types would probably suffice for more than 90% of meals for an average person.
2. Make better use of meals entered through Health, where contents would be available through a user preferred app, and user would not be required to enter carbs, protein, fat separately. Then, come up with a formula in Loop on how to convert this into carb equivalents and absorption times. As an extension, parameters in the conversion formula would then be auto-tuned over time to account for individual differences.

[trixing]

For (1) There is a pretty extensive solution here to help a 5/6 year old kid and his teachers to make it as easy as possible. It would be easy to extend with protein and fat information https://github.com/erikdi/Loop/blob/dev/FEATURES.md . I do think this would need to be reimplemented though to fit the Loop style, and probably be hooked up to download the food information from Nightscout (/api/v1/food.json) to make it possible to update and adapt (and get Loop out of having any health related data).

[kellyisworking]

@dm61 thanks so much for your thoughts on this. Agree with your approach here and would love to help mock up various ways we can do this. In response to a few of your points:

1. Regarding recording the absorption profiles of carb equivalent or alternatively full meal entries, can you help me understand how/where this would be stored? @trixing do you know if the carb absorption decay profiles are stored in the FoodManager implementation here https://github.com/erikdi/Loop/blob/dev/FEATURES.md, or is it primarily to help with carb counting?

Editing to add 1a - Can you help me understand, would the observed absorption pattern average the observed users inputs for the same meal over time? If a user has slower absorption due to exercise after meal, etc. would the stored observed absorption pattern discard the outlier?

2. Do you think we may need to look at introducing a different initial absorption curve for CE, or more specifically as you note in your implementation, that the absorption curve may change depending on the total composition of the meal? Would recording the absorption profiles of entries give us the necessary retrospective data to inform this? There is some interesting discussion on Potential enhancements to carb absorption algorithm - brainstorm #629 as well.

3. I agree that splitting an entry into multiple inputs would be an additional ask of the user that is already quite complicated; however, it would be a clear enhancement to those that already use multiple inputs and if it's possible to view CE impact on carbohydrates screen separately that would be awesome. If this information could be pulled from 1. a library, or 2. Apple Health rather than another input on UI, even better. For what it's worth, roughly calculating total calories of fat and protein is fairly simplified for us rather than calculating grams and is how we calculate CE now.

4. I'm not sure how much work has been done on being able to use another app's Apple Health data in your last point, if revising entries or deleting entries which had been a problem in the past is now stable.

Thanks again for opening this issue @rsilvers129 and the awesome thoughts @dm61 @trixing!

[trixing]

Regarding 1. Carb Absorption times are configured here https://github.com/erikdi/Loop/blob/dev/Loop/FoodCatalog/catalog.json , see also https://github.com/erikdi/Loop/blob/dev/Loop/Managers/FoodManager.swift

[joeyovens]

I have thought a lot about the best way to use other apps data. The issue I have is the way most apps timestamp. Myfitnesspal, as an example, stamps the food when you put it in, not when you tell it you ate it. At least thats the way loop reads it when you have myfitnesspal write carbs to healthkit. So I think Loop would still need an additional step of telling the app when you ate a specific meal. That way if you are using it to track food (for other reasons) and log it later after you ate (which sometimes happens), you dont have worry about loop thinking you are eating in the moment causing a low.

I currently dont have myfitnesspal write carbs to health for this reason. If you made loop be the point of entry for all this data, you would have to turn off all macro writing for myfitnesspal. I dont see that as a way around double entry. Unless there is something I am missing.

[trixing]

There is also the problem that you need to open the Loop app to give it access to HK data, no? I thought if you don't bring it to foreground and just enter carbs through other apps / apple watch, Loop won't be able to read it as the HK data gets protected.

…

On Fri, Apr 20, 2018 at 4:12 AM, Joe ***@***.***> wrote: I have thought a lot about the best way to use other apps data. The issue I have is the way most apps timestamp. Myfitnesspal, as an example, stamps the food when you put it in, not when you tell it you ate it. At least thats the way loop reads it when you have myfitnesspal write carbs to healthkit. So I think Loop would still need an additional step of telling the app when you ate a specific meal. That way if you are using it to track food (for other reasons) and log it later after you ate (which sometimes happens), you dont have worry about loop thinking you are eating in the moment causing a low. I currently dont have myfitnesspal write carbs to health for this reason. If you made loop be the point of entry for all this data, you would have to turn off all macro writing for myfitnesspal. I dont see that as a way around double entry. Unless there is something I am missing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE2apntRnVkOqWHsubdAIDMhOiQ8h_Iks5tqUQlgaJpZM4TXJpA> .

-- Jan Dittmer <jdi@l4x.org>, http://l4x.org

[dm61]

@trixing thanks for sharing links to your branches, nice work! @kellyisworking, having customizable meal-type entries as done by @trixing, could indeed be a great starting point. Updating the meal type parameters based on subsequently observed absorption could then be a follow-up feature enhancement.

[Lytrix]

It is also possible to ask for a api token as a developer to use the Myfitnesspal api directly in Loop, that way you can search and add it directly to health with the desired timestamp:
https://www.myfitnesspal.com/api
And I also like these solutions which are becoming more and more available:
https://www.cnbc.com/2017/08/23/see-how-your-iphone-will-recognize-food-and-identify-a-rash-with-ios-11.html

[diggabyte]

As someone how often eats low-carb / high-fat meals, it’s been incredibly challenging to convey those inputs in terms of “carbohydrates” and absorption times. As a result, I end up doing the mental gymnastics in a roundabout way to make algorithm work. And while I recongize this is one of the most challenging calculations in diabetes care, a mediocre algo will probably beat my best napkin math, especially if the inputs (fat/protein) have ratios.

[TravellingEd]

Love this discussion. As someone who's been doing the low carb (keto) lifestyle for the past 5 years and considers all macros in my meals it would be awesome to have the option to protein and fat grams. I don't think this would be for everyone and I agree with dm61's point #3 that loop should be simplified for the general user but it would be awesome to have this as an option. Glad this is being explored.

[rsilvers129]

Implemented here - works with Loop but should be built in:

https://www.youtube.com/watch?v=k8amkz9E66k

[rsilvers129]

Good point. For me, this was about being able to eat big-carb meals that also contained fat. I was not seeing a ton of interest in it - I assume because people serious enough about their diabetes to be in these groups probably gave up on eating such meals. But, it should be popular with low carb people since their calories are from fat and protein. These rules from the paper can be added to help low-carb people:

▪Protein does have an effect on postprandial glycaemia.
▪This effect is delayed by approximately 1.5 hours.
▪A smaller amount of protein will affect blood glucose when consumed with at least 30g of carbohydrate but, without carbohydrate, at least 75g is needed to produce an effect

[rsilvers129]

Another paper: https://www.ncbi.nlm.nih.gov/pubmed/21949219/