Thanks, @Tia_G. Yeah, I’ve learned to enter “fake carbs” when I want to offset an expected BG rise with high-temp basals. I use that for my expected rise in BGs in the morning just because I get up and out of bed. Ten grams of fake carbs is the perfect antidote.
As far as ice cream goes, I just need to be moderate in my portion size. It’s an amazing system and I feel like it’ll take me some time to learn some new tactics.
Does Loop allow you to use temporary basal rates and have the system adjust from there? Or must you keep the basal rate set? Similarly, you can still bolus isnulin as normal (either with food, a correction, or manual), right?
Loop uses temporary basal rates constantly (every five minutes). The reason I add carbs to the Loop system without an accompanying bolus is to force the system into using a high temporary basal rate to counteract an expected rise in my BG. If I just told Loop to add insulin as in a correction bolus, then it would respond with low or zero temp basal. By letting Loop decide how high to set the temp basal rate and when to turn it off, it makes it a smart tactic. In other words, it uses subsequent BG movement to update its insulin dosing via temp basal rates. It’s a different way of thinking from the straight forward pump tactics.
So, why don’t I just let Loop handle the expected “when feet hit the floor” morning BG rise? It’s because Loop has its limits in how fast and how much it can adjust insulin delivery. My usual morning rise in blood sugar is a little too fast and too far for Loop to keep up. I do this workaround tactic to keep Loop in its most effective zone.
This is interesting. Does it do this for every bolus? This doesn’t make much sense to me. Assuming the correct carb or correction ratio is used and one isn’t intending to do a super-bolus and one isn’t trending lower, why would the basal automatically be sent to low or zero?
@Terry4, which pump again are you using, and what is the maximum temp basal it allows?
I just checked this on the Omnipod in thinking about how well a system like Loop could manage the whole shebang WITHOUT having to explicitly ever bolus. There’s a setting for capping the maximum basal rate, which affects what can be constructed in a basal program, and what can be set for temp basals.
This tops out at 30 U/hr (WOW!), which it turns out is the largest bolus the system will let you deliver in a single bolus. I rarely (can’t even remember a time) deliver a bolus that large for a meal or correction, nor do I deliver really large boluses like that (say, 20-30 U) more than once in an hour anyway, so the basal delivery method seems more than capable to handle any BOLUS need in a hypothetical Loop or APS system that worked with Omnipod.
As such, seems the system could be designed to handle bolus needs as well, by just entering the carbs into Loop (which it sounds like you already can), and having the system just deliver the “bolus” over the next hour. Heck, it could do it even faster with the ability to deliver at a rate up to 30U/hr… A 10U bolus could be delivered in 20 minutes by cranking up to the 30U/hr rate for 20 minutes, then dropping back down to the nominal basal rate.
The idea here is something I don’t think Loop does right now, based on what I’ve read in this discussion (admittedly scant data). That is, simulate a bolus by immediately turning the insulin to “full on” until the bolus amount has been delivered, then turning it back down to the nominal basal. Then, also, reacting differently to rising BG than it would otherwise assuming you are in “fasting mode”, accounting for the IOB from the bolus in deciding what to do about the elevated BG.
So, based on the maximum parameters of the pump(s) that already work with Loop, the fact that control is achieved through tinkering with the temp basal rates may be inconsequential in terms of handling boluses as well. If the temp basal rate capability is high enough, seems to me the bolus side of the AP is doable right now, with the system you’re using (in theory – someone would have to figure it out and write the code).
Hope that was clear… kind of complicated gendanken 
Ok. An important point I haven’t explained yet is how the whole temp basal thing works in Loop. First of all you program in whatever basal profile suits you. Let’s say, for purposes of this discussion, that you decide a 1.0 units per hour is your basal rate around the clock. When Loop calls for 0.0 unit temp basal, your pump actually delivers 1.0 units/hour (1.0 - 0.0 = 1.0), your background pump basal rate. If Loop decides that it wants to high-temp at say, 1.5 units/hour, then you’ll actually receive the pump background of 1.0 units/hour plus the 1.5 units/hour Loop temp for a total of 2.5 units/hour.
If Loop decides to execute a low temp basal, it can call for up to a negative 1.0 units/hour and then the pump will not deliver any basal insulin (1.0 - 1.0 = 0). Loop may decide to negative temp at minus 0.6 units/hour. In this example that means that Loop will only deliver 0.4 units/hour (1.0 - 0.6 = 0.4).
The example I used was for a daily trend for my blood sugar to rise when I get up in the morning without me eating anything or otherwise causing my BG to go up. So, if I deliver a correction bolus to counteract my expected morning rise then Loop responds with a negative temp basal and takes away from my attempt to pull down the expected morning rise. Loop doesn’t understand my larger strategy to counteract a trend that Loop doesn’t explicitly know about, that is the quantity and timing of carbs and insulin
That’s a lot of words to answer your question. Does it make any sense?
Whoah, okay, that’s the first time I ever saw that, and it was kind of weird
I was reading your post Terry (the one this is in response to) while you were editing it in real time, and right before my eyes a little bit of it changed (that parenthetical math).
That was freaky.
I’ve seen that happen, too. It is a bit weird. 
It does make sense. But I don’t understand this part:
I don’t understand why delivering a bolus would make Loop subsequently set a negative basal rate. When we do correction or meal boluses on a pump or MDI, we don’t then subtract from our basal rate…not unless we’re attempting a super-bolus, drifting too low, or anticipating exercise or something like that. I could understand Loop doing this if it predicted a low, but from what you’re saying, it seems to do this in response to just a delivered bolus.
I’m using a MiniMed 722 model. It allows the user to set the maximum basal rate. It maxes out at 35.0 units/hour.
I’m not sure that what you propose is any more desirable than Loop’s current practice for delivering a bolus. To bolus with the current configuration the user needs to tell Loop how many carbs will be consumed and when. Loop also needs to know how long it will take to absorb those carbs. In other words, using your proposal, if I understand it, one would still need to give Loop the food quantity and duration, no net advantage over current design.
It’s the delivery of a bolus without consuming any corresponding carbs that makes the basal rate go negative.
My post may be entirely based on ignorance – does Loop handle delivering bolus insulin? I thought, perhaps mistakenly, that it was only REACTIVE to BG levels. Can you tell Loop you ate X carbs, and it calculates a bolus based on an IC setting, then delivers the additional insulin through an increased temp basal setting?
That’s the core of what I’m talking about. The fast delivery via cranking up the basal to max rate was only an operational musing. The main point is, does Loop track and administer bolus insulin, IOB, etc., through the temp basal mechanism?
Loop does not deliver boluses for food through basal insulin. It asks the user how many carbs, when they will be eaten, and how long you expect them to absorb. Then it delivers the bolus immediately.
It tracks IOB using bolus insulin plus the net effect of +/- temp basals.
Okay, I’m a little confused, and this is really a technical question more than anything else.
I had thought that these systems (Loop and APS) could only control the pump through modifying the temp basal setting on the pump. Is that correct? Or can Loop also issue a bolus command to the pump?
So here’s my confusion. You eat 50g of carb. You now need to bolus some insulin for that. Do you tell Loop on your iPhone that you ate 50g, and Loop then controls the pump to deliver the bolus? Or do you use the controls on the pump to deliver the bolus, and tell Loop via your iPhone that you ate 50g (thereby having to enter that information twice in two places)?
Interesting. So even if you deliver a “normal” bolus (just straight insulin), as a “nudge” for example, it will still respond by decreasing the basal rates, even if blood sugar is currently rising?
Loop can only automatically deliver insulin using temp basal rates. It delivers bolus insulin using an interactive manual feature, much like a bolus wizard on the pump. That’s why it’s called a hybrid system. It requires human interaction for the bolus but the bolus can be delivered by the app on the iPhone, manually, not automatically.
Loop will still consider all its inputs before it decides how to respond. If blood sugar is rising, it will take that into consideration and act accordingly.
I understand now. So you do deliver bolus insulin through the Loop system, and it uses the temp basal mechanism of the pump to deliver the requested insulin (presumably by increasing temp basal rate, by how much, what sort of ramp up and down, etc. are details Loop works out).
This provides the base functionality to be able to offer a (very) complex and flexible bolus programming scheme. Something I discussed in another thread a few weeks ago as a wishlist sort of pump feature I’d like.
For example, create a pizza bolus that would deliver 33% immediately, 33% spread over 3 hours, then the last third in another impulse at the 3 hour mark. Does loop have any feature like this? It’s certainly possible with the technology and existing capability. Especially with a max rate capability of 35U/hr. That’s hefty.
As we say around here so often, YDMV. Mine certainly does, and there are some very repeatable, Dave-specific patterns that I see when I eat that I could create a more complicated bolus for than I can now, better avoid stubborn spikes, eat things that are problematic more easily.
Terry, I’d like to confirm my understanding that the pump itself is acting only as a controllable/variable insulin administering device, and nothing more…
[quote=“Terry4, post:117, topic:57501, full:true”]
That’s why it’s called a hybrid system. It requires human interaction for the bolus but the bolus can be delivered by the app on the iPhone, manually, not automatically.
[/quote]In my opinion, we will not get beyond hybrid systems without much faster insulin. The improvement in control by pre-bolusing will continue to be significant enough to make it standard protocol.
Once injectible insulins get as fast as something like Afrezza exogenous insulin chasing carbs may be viable to provide good enough control. This doesn’t mean no spikes, just means good enough a1c, and presumably the expected health outcome.
That, or a completely different delivery mechanism and insulin form. Like smart insulin, that operates on the molecular level. That would just about be a “cure”, without actually being a cure.