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 <[email protected]>, 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/

[dm61]

@rsilvers129 thanks for the additional reference. Just to reconfirm I'd be interested in implementing this in LoopKit/Loop and have in fact looked into what it would take to do so. Unfortunately, it's not as easy as one would think, at least not for me. The changes need to be done in LoopKit, which is more challenging for me than any code changes in Loop itself. Furthermore, there are important LoopKit code details that I do not understand well enough at this time. If someone else wants to work on this, I'd be happy to collaborate.

[rsilvers129]

I have been using this for the last two weeks and am loving the results. I have had some really big meals - pizza, cheesecake, fried food, ice creme - sometimes without going over 122 all night.

Also, it works for low and no-carb eating. I had 400 calories of Salmon today and it did a square wave for that and it worked out.

The Shortcut on the YouTube video has been updated. Would love to see it added to Loop (including the way that it can pick fat and protein from Apple Health and sum them) but I also don't know the coding to do it.

[TravellingEd]

Tried implementing this but I'm having trouble setting it up with MyFitnessPal. It would be awesome to have this implemented into Loop as a code customization option.

[rsilvers129]

I have been coding this into a forked version of LoopKit. So far, for testing, LoopKit accepts entry of carb, protein, and fat and will send back the protein and fat equivalent for Loop to record with addCarbEntry. Or if I comment out that NewCarbEntry in LoopKit, the normal NewCarbEntry will return.

I am thinking I need to convert NewCarbEntry to return a tuple so that Loop can do two addCarbEntry, but someone who is more familiar with the code could probably tell me if this is the right way to go.

FPU branch on my fork:

https://github.com/rsilvers129/Loop.git

https://github.com/rsilvers129/LoopKit.git

[dm61]

@rsilvers129 great start! Here is a summary of what I think needs to be done:

1. Allow user to enter protein and fat grams on the Add Carb Entry screen; looks like you've already done that. But, this will need to be modified to ensure that protein and fat entry lines show up only on the new Add Carb Entry screen, and not on the Edit Carb Entry screen.
2. If protein and/or fat were entered, calculate an equivalent FPU carb entry. Looks like your code already does that, although I think this will also need to be modified somewhat, to enable the next step.
3. Three cases need to be considered based on what the user entered on the Add Carb Entry screen:

• (a) user entered just carbs: add a single carb entry, this is what Loop already does
• (b) user entered just protein or fat: add a single FPU carb entry
• (c) user entered carbs and protein or fat: add two carb entries, one standard (a) and one FPU (b)

To implement this step, I'd look into modifying how Loop responds to a new entry, see these lines in CarbEntryTableViewController This code needs to be able to distinguish cases (a), (b) and (c), which is why the code in step 2. needs to be modified.

4. From this point on, a FPU entry will show up and will be treated by Loop just like any other carb entry. You may consider adding a special foodType description so that it is clear which of the carb entries are FPU. Note that the user would not be able to go back and edit protein or fat grams, but would be able to edit or delete FPU entries just like any other carb entry. This may not be an ideal solution, but would be a first step. Keeping track of protein and fat for each meal entry, dealing with corresponding HK issues, FPU recalculations, etc, would be considerably more difficult to implement.

[rsilvers129]

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

[rsilvers129]

I asked Dr Pankowska if the equation was limited in hours and lack of delay due to what was best, or due to pump programming limitations. She said "Due to a pump setting there is not possibility to do it in longer time. I agree with you that for some meals such pizza insulin should be applying for 12 hours." So that is why I coded it to not be so limited as her paper - because we are not limited by the pump square-wave times.

[rsilvers129]

I did a battery of tests, and my Fat-Protein unit version of Loop-1.9.3-dev is ready to try. There is an .xlsx file in the distribution with the testing results. https://tinyurl.com/ybosjp3d

[rsilvers129]

Updated repo. Now there is an FPU+IRC-da61+Spike-dabear. Worked great on my pizza today. Carb ratio has to be tweaked up a little.

[rsilvers129]

I add in two more large meals after the pizza - and got great results overnight:

[rsilvers129]

Managed to stay pretty flat today even though I ate 311 grams of carb, 91 grams of fat and 87 grams of protein. And I ran 6 miles. I did this by using Loop-FPU to handle the carb+fat+protein, and then I manually simulated the exercise mode that is not yet implemented where basal rate goes to 1/5 normal, carb ratio goes to 5x normal, and ISF goes to 5x normal (#593).

[nmgeorgiev]

@rsilvers129 Hi I was trying to install your FPU to my loop app but I'm having troubles. Is there a specific step by step (for dummies)? Thanks

[rsilvers129]

Hi. Just use the main loop docs. It is exactly the same except which file you start with. Except everyone seems to find that a carthage update" is needed - but that is also in the Loop docs as a common problem.

[nmgeorgiev]

@rsilvers129 Thanks for the quick reply Robert. Is there anything I need to download or do I have to edit the code myself in the main loop docs to add the fat and protein? Thanks in advance.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.