Saturday, April 28, 2018

Protein and Fat in a DIY-APS setting


No matter if on a high- or low-carb diet, fat and protein is tasty as well in a steak with green beans as in a pizza with extra thin crust and extra cheese on top. And as a type 1 diabetic I need insulin to cover it if I want my bg levels to stay in range. [1]

Traditionally I would give an extended bolus. Something that does not fit very well into the world of a closed loop as now the algorithm should take care of how much insulin comes out of the tip of my infusion set.
As the loop now increases the insulin when the bg rises and the rise from fat/protein is rather slow, the loop helps quite a bit. Still not 100% satisfactory as for larger amounts my CGM hovers above target for hours - and any unplanned BG increase won't be compensated by the loop if it is already at it's limits

Fake Carbs?

Hinting the loop that it can give insulin more agressively after a meal works quite well by entering "fake carbs". This is an equivalent of "carbs" you expect a meal to have impact on your blood glucose. I simply enter those as carbs into my system. Maybe "carbs equivalent" is a better name?
With the dynamic carb absorption model from OpenAPS that AndroidAPS also adopted this works quite well. The algorithm will detect a rather slow carb absorption and give insulin accordingly.

As a safety feature, the algorithm will assume a minimum carb absorption. This means that after a couple of hours it will believe your meal to be fully absorbed. For smaller and medium meals this is no problem as the rest will be handled by the closed loop system even in "no COB" mode. With larger meals I still do see a small rise a couple of hours after the meal.

Future Carbs?


Setting Event Time in carbs in Nightscout/careportal

A trick to handle the late rise after a protein-rich meal is to enter some carbs in the future. This way the closed loop knows that there is some cabs and it still can work a bit more agressively.

This also has the advantage that some advanced freatures like Autosense and Autotune will not consider this late rise as some form of insulin resistance but attribute it correctly to being meal-related.


Extended Carbs! 

Starting this article with and extended bolus we are now at extended carbs:
The new 2.0 version of AndroidAPS (and NSClient as well if you use another system) has the possibility to not only schedule carbs in the future but also distribute it over an interval. Just like an extended bolus would distribute insulin over an interval.

Time for some food! :)

This is my test meal: 400g of pork strips in tomatoe sauce:



This was the situation before the meal:



With the new carbs dialog I entered what I thought could be the equivalent carbs (25g), scheduled it 60 minutes into the future and set an interval of 2 hours.

I didn't give any bolus. I do have SMB (super micro bolusing) activated. You can see them as the small blue triangles.
This is how it looked like after I confirmed, the carbs are scheduled as multiple events with 15 minutes in between:



This is how it looked like during the extended carb interval!
The COB curve (orange) has a saw tooth like shape. Due to the COB, there were a lot of SMB so the loop did its job perfectly :)

Enjoy your meal!

[1] HOLT, S. H.; MILLER, J. C.; PETOCZ, Peter. An insulin index of foods: the insulin demand generated by 1000-kJ portions of common foods. The American journal of clinical nutrition, 1997, 66. Jg., Nr. 5, S. 1264-1276.

7 comments:

  1. Very interesting stuff! Thanks for sharing!

    ReplyDelete
  2. I followed this advice as well for a while and it worked out good for me. (There is eating soon mode explained by D. Lewis) But recently my loop is not able to bring down fat protein "carbs" so I started to do ProfileSwitches. But this only daytime a good idea. During night, when at sleep, you´re not able to switch back to 100% while sleeping. Last week I widened safety contraints of Oref0 (setting multiplier to 4 to 5 instead 3 to 4). May be I can switch to your recommended handling. Thanks for your blog post!

    ReplyDelete
    Replies
    1. If you prefer profile switches, you can give them a duration now. They will switch back after that time. You still need one with "zero" duration that is valid forever to fall back to.

      The disadvantage of a profile switch with a duration is: It will write the profile to the pump. Switching back relies on a connection to the pump.
      So it should rather be something log or medium term, not a short term treatment.

      Delete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi --really good stuff but I dont seem to have that new extend carb feature in my NS client.. is that specific to androidaps? i'm looping openaps

    ReplyDelete
    Replies
    1. It is in the release candidate (you need to compile it yourslef) so should be there in the next version.

      Delete
  5. Really interesting topic, Adrian.
    Thanks for your nice work and for disclosing your ideas to us...

    ReplyDelete