Looping works by altering the rate at which insulin is delivered in response to raised or lowered blood glucose. Temp basals and extended boluses both do exactly the same thing; they both simply alter the rate at which insulin is delivered. (The two names are just synonyms, a temp basal does exactly the same thing as an extended bolus, at least with the Omnipod.)
So you can’t both loop and deliver extended boluses; you can have one or the other but not both.
The page your referenced is really about something completely different and it may be appropriate to what you want to do with pizza and, indeed, what I do with nuts. In both cases carbs are released over an extended period of time.
I don’t loop (yet) so I have to find some way of doing precisely what loop would do; I have to deal with the effect the gradual breakdown of protein from the nuts has on my BG. I do that with a guesstimated increase to my basal rate over 8 hours (I use a temp basal, but I could use an extended bolus.) When I start looping I expect the loop algorithm to do this automatically, and do it a lot better than I do.
Pizza is more difficult because the pizza effect is much more rapid than protein metabolism. The more rapid the carb adsorption the more difficult it is for looping to handle it; the insulin increase from the loop algorithm takes 15 minutes to even start showing up.
The limiting case of this is ingesting a high carb meal; subcutaneous insulin injected in response to our raised blood glucose is way too late to prevent our blood sugar going far to high, dangerously high in some cases. That’s because a substantial part of those high carb meals gets adsorbed in 15 minutes.
There are two possible fixes for this bolus problem; either introduce the insulin directly into the blood supply close to the gut as soon as that blood shows a raised blood glucose, or predict exactly how much carbs and protein we will ingest at least 15 minutes in the future and introduce insulin subcutaneously in anticipation of the feast to come.
The first fix is what the non-T1 pancreas does and what an artificial pancreas would have to do. The second is the only choice T1’s have (I’m ignoring Afrezza here); we have to predict what we will eat in advance and arrange for a bolus, also in advance.
That’s a simple bolus. The Pizza Effect complicates this because the carbs don’t get adsorbed at what might be called the “normal” rate. That complicated AndroidAPS page is about a sort-of solution to this; you can say that you are about to eat 40g of carbs in a Pizza, but it won’t be adsorbed significantly for an hour. The result is exactly the same as if you delay the bolus for an hour; that’s something I have done from time to time.
In theory a loop algorithm could respond correctly to carbs that take more than 15 minutes to adsorb just so long as the actual adsorption over 20 minutes is not itself enough to mess up our blood sugar levels. However getting that right depends on the CGM giving accurate readings every 5 minutes. CGMs aren’t that accurate; they produce intermittent bad results, so relying on a single result to alter the insulin delivery rate is, at best, dangerous.
As a result something that takes less than a certain time, I guess at least 2 hours, to introduce significant carbs into the blood stream requires a bolus. A lot of the time I suspect that the loop algorithm will allow an extended bolus of a couple of hours to be replaced by an “instant” bolus; the loop algorithm will see a BG drop early on, correct for that, then counter correct for the BG rise later in the 2 hour period. Of course this will only work when the original extended bolus is no more than a couple of units; i.e. close to the actual basal insulin requirement over the same period.
However I doubt this can handle the Pizza Effect simply because there are so many carbs in Pizza; the bolus requirement makes the basal insignificant.
