Loop -- a dynamic answer to a dynamic problem

[Jen]

Keep in mind, too, that @Terry4 is eating a low-carb diet (or at least was before using this system). I wonder how these Loop graphs would look from someone eating 150+ grams of carbs per day and how (or whether) the system would be able to keep up with such spectacular results.

I think I like the idea of a basal rat which automatically ramps up or down to deal with impending highs or lows while still being able to bolus as usual for food or corrections. This is, supposedly, what the next generation of the Animas pump will be able to do.

[Dave26]

[quote=“Jen, post:122, topic:57501, full:true”]
Keep in mind, too, that @Terry4 is eating a low-carb diet (or at least was before using this system). I wonder how these Loop graphs would look from someone eating 150+ grams of carbs per day and how (or whether) the system would be able to keep up with such spectacular results.
[/quote]This is what I’m trying to understand.

Functionally, a pump is very simple: It delivers a precise does of insulin with a single “pulse”. All pumps work this way, regardless of the actual mechanism metering the dose (in an Omnipod, it’s a ratchet mechanism actuated by the contraction of an SMA wire when energized). There is a maximum rate the pump can deliver these small doses at.

That’s it. There really isn’t any more to an insulin pump that distinguishes between “basal”, “bolus”, or anything else. The rest is all programming.

So, that’s what I’m trying to fully understand in the Loop system: Which software is involved in control during bolus delivery? I think I’ve learned that Loop is running the show, from the iPhone, using the temp basal feature of the pump to turn it into essentially a “dumb pump”, analogous to a simple pump with a knob on it to turn insulin delivery up or down, Loop turning the knob.

In that case, “bolus” and “basal” really have nothing to do with the pump. They’re concepts that exist in Loop, managed by Loop, presented to the user for control by Loop. Loop is in control of ALL insulin delivery – the pump does not initiate insulin delivery or adjust the rate of delivery.

In terms of timing, let’s look at the Omniipod for an example (as I know the specs). The dosing increment is 0.05U. The maximum rate it can impulse doses is every 2 seconds. So, it can deliver insulin at a maximum 0.05U/2s, or 0.025U/s (although insulin is delivered in 0.5U amounts every 2 seconds when a bolus is being delivered). This is equivalent to 90U/hr.

The omnipod has a hard limit for basal rates of 30U/hr, so at best using the temp basal mechanism as the “knob to turn” and deliver boluses would mean at best boluses would take 3x as long to deliver. A 10U bolus delivered through the Omnipod PDM interface (and software) will take 6:40 to deliver while Loop would be limited to taking 20 minutes to deliver the same bolus.

This is quite significant in terms of how the insulin will act in blunting any spikes from carbs eaten.

[Jen]

Yeah, it’s unclear to me whether the pump delivers a bolus (when carbs are entered into the app manually) or basal.

As you point out, not being able to pre-bolus would be a huge issue in a completely closed-loop system with today’s insulins. I don’t know about others, but any fast-acting carbs (fruit, rice, bread, etc.) are pretty much instant double up arrows on my CGM. Even when I’ve bolused the correct amount delivered all at once (the Ping can deliver 1.0 units per second, I believe), today’s insulins just can’t keep up with the speed of that rise, so I end up spiking high for perhaps an hour or two and then coming back down. With a significant pre-bolus (30-60 minutes) I can reduce that spike quite a bit or, sometimes, even eliminate it. A fully automated system, where the user doesn’t even enter food but where the system just responds to changes in BG, would have even more trouble keeping blood sugars in range without a much faster-acting insulin (and also, for a fully closed-loop system, glucagon to eliminate lows).

[Terry4]

@Jen

Yeah, it’s unclear to me whether the pump delivers a bolus (when carbs are entered into the app manually) or basal.

When dosing for meals, data entry and bolus calculation are done on the phone app and then a command is issued to the pump to deliver the bolus insulin all at once – it does not get delivered as an addition to the temping basals.

[Dave26]

@Terry4

@Jen

Yeah, it’s unclear to me whether the pump delivers a bolus (when carbs are entered into the app manually) or basal.

When dosing for meals, data entry and bolus calculation are done on the phone app and then a command is issued to the pump to deliver the bolus insulin all at once – it does not get delivered as an addition to the temping basals.

Sorry to seem dumb as a lump of granite here, Terry, but does Loop issue a bolus command to the pump the same as programming a bolus directly from the pump, or does Loop use the temp basal mechanism of the pump to deliver the bolus via raising the basal rate for a suitable period?

My understanding is the latter, because controlling the temp basal rate is the only access Loop has externally to control insulin delivery from the pump. If, instead, they also figured out how to directly initiate a bolus through the pump – that is, tell the pump program to deliver a bolus – that’s even better.

[Terry4]

@Dave26

Sorry to seem dumb as a lump of granite here, Terry, but does Loop issue a bolus command to the pump the same as programming a bolus directly from the pump, or does Loop use the temp basal mechanism of the pump to deliver the bolus via raising the basal rate for a suitable period?

I know you’ve resisted the idea that Loop is only capable of basal communication despite my repeated effort to describe it otherwise.

When I issue a bolus command through Loop to the pump, the pump acts just like and delivers insulin as if the pump itself had issued the bolus command. Loop appears to both communicate and act in distinct basal and bolus actions.

Loop only uses the temp basal rates as its feedback mechanism to drive blood glucose toward its target. The bolus mechanism is completely manual even though it is done through the iPhone app.

[Dave26]

@Terry4

@Dave26

Sorry to seem dumb as a lump of granite here, Terry, but does Loop issue a bolus command to the pump the same as programming a bolus directly from the pump, or does Loop use the temp basal mechanism of the pump to deliver the bolus via raising the basal rate for a suitable period?

I know you’ve resisted the idea that Loop is only capable of basal communication despite my repeated effort to describe it otherwise.

When I issue a bolus command through Loop to the pump, the pump acts just like and delivers insulin as if the pump itself had issued the bolus command. Loop appears to both communicate and act in distinct basal and bolus actions.

Loop only uses the temp basal rates as its feedback mechanism to drive blood glucose toward its target. The bolus mechanism is completely manual even though it is done through the iPhone app.

Well, you seem to be getting annoyed with me – I’m not resisting anything, I just am trying to understand. I don’t have a Loop system, so I’m feeling around in the dark to some degree. I had heard some time in the past that the “hack” on these pumps only cracked manipulating the temp basal control, and it was from this understanding I’ve been questioning. That’s why I’ve been so explicit trying to get a clear statement whether or not the pump was delivering all insulin through basal adjustments. I’m an engineer, I have access to and am coding on the xdrip+ open source CGM app, so I have a (perhaps obsessive) focus on underlying engineering implementation. I just want to know how it works.

Sorry if I got too annoying… I’ll drop out now.

[Dragan1]

@Dave26

I had heard some time in the past that the “hack” on these pumps only cracked manipulating the temp basal control,

Many (possibly all, but we do not really know) pump controlling commands have been cracked, including commands to adjust temp basal rate, issue boluses, and many others, such as reading pump history (which is super important for closed-loop systems). As @Terry4 explained, Loop and OpenAPS, which are both based on the reverse-engineered communications to compatible MM pumps, do not automate bolus delivery, not because that would be impossible to do, but because that would make the closed-loop operation less safe. With Loop, a user has essentially complete control over the pump from iPhone - there is no need to touch the pump except to change reservoir+infusion set, or to do a few other less important functions. A user issued bolus from iPhone requires fingerprint authentication, which is a nice safety feature.

[Dave26]

@Dragan1 that was (for me) the clearest explanation filling in the holes in my swiss cheese. No poor reflection on Terry – I just think there we were missing each other in the back and forth, and much of that was because of assumptions I was operating under.

Anyway, I have a clear understanding now of how the system is implemented, as well as what treatment functions can be executed from the iPhone (essentially, all of them).

Which brings me to… anything like the more complex bolus programming I talked about above, or are the current systems more in keeping with the typical pump combo/extended bolus program we’re already familiar with?

As for fully automatic, as I mentioned above I don’t expect anything like that to even be possible until we have much faster insulin, on the order of Afrezza pharmacodynamics. Once we have an insulin with suitable delivery mechanism to interface with something like Loop we can think about the fully realized Artificial Pancreas. With current insulins, the “hybrid” is as good as it can get, if large excursion spikes are to be avoided.

[tim2000s]

As far as I understand it, the Loop algorithm is triggered by the G5 data collection process, so it runs every five minutes, rather than every minute.

[tim2000s]

None of the systems have the “advanced” bolus features, so no square waves or dual waves. This is the point at which OpenAPS and Loop differ though.

With Loop you tell it an absorption profile for the carbs (based on Scheiner’s carb absorption curves) and it then follows the bolus up by adjusting insulin based on this data. It has a feature called “Retrospective Correction” that allows it to adjust a bit if the glucose changes don’t match what the static curve and DIA appear to be producing. We’ve determined that the best way to create advanced wave functions is by being clever with food entry. Essentially, you can create a Dual Wave by entering a carb amount bolus for it immediately and then a second carb amount with longer absorption (usually five or six hours) and no bolus. Loop then does a pretty good job of mimicking the Dual Wave option. If you want it to provide insulin in a square wave style, you’d do the latter part of that, with no upfront bolus, but it’s not quite so effective.

OpenAPS has a feature called Advanced Meal Assist that looks at rate of absorption. It compares to a standard rate (that you are supposed to determine when setting it up) and then if the rate is different, adjusts the insulin accordingly and also pushes 50% of the amount still to be absorbed out, with a rate of decay based on current consumption.

I’ve found that AMA works more effectively with badly calculated carbs and difficult to determine absorption, but both systems would be vastly improved with faster insulin. Interestingly, you can, with AMA, get away with eating sub-40g of carbs without going ridiculously high, as long as you’ve applied an “Eating Soon” temporary target.

[Tia_G]

This is very interesting. I’ve been a bit stymied lately by how AMA calculates carbs. For our son, it seems like the carbs decay very very slowly, if at all, when he’s not rising. But if I timed the food, picked the food, and administered the insulin optimally, then he probably shouldn’t have risen much!
The other thing I’m really hoping to figure out is how to enter carbs for things like Indian food, where there are multiple waves over the next 7 hours.

[Terry4]

Thank-you @tim2000s and @Dragan1 for help articulating better how Loop handles insulin delivery. I am still very much still learning how Loop works and how I can best control my blood sugar using it. @Dave26, I’m happy that confusion is behind us.

Prior to using Loop I dosed my meal insulin using two boluses, one simple immediate bolus based on carbs and then a second extended bolus based on protein and fat. Switching over to Loop, I still deliver the immediate bolus based on carbs but then I let Loop decide how to handle the nutrition, via temp boluses, formerly covered in the extended bolus. It’s working reasonably well but I sense that a definite limit exists as to how far I can push this concept.

@tim2000s, are you using one or both of these do-it-yourself open source systems? While I’ve been trying to follow user issues in gitter chat and the FaceBook “Looped” group, I’ve struggled to decode the various acronyms flying about. With your comment above I now know that AMA is not the American Medical Association but Advanced Meal Assist. Thanks for that!

[tim2000s]

@Terry4

Prior to using Loop I dosed my meal insulin using two boluses, one simple immediate bolus based on carbs and then a second extended bolus based on protein and fat. Switching over to Loop, I still deliver the immediate bolus based on carbs but then I let Loop decide how to handle the nutrition, via temp boluses, formerly covered in the extended bolus. It’s working reasonably well but I sense that a definite limit exists as to how far I can push this concept.

This is one of the more frustrating aspects of both Loop and OpenAPS, in that neither of them makes the best hash of what you might have extended bolused for. That’s why I started to use the “double meal” version. Ultimately, because you know carbs are coming, that’s where the benefit of having extended bolus functionality is. Having said that, if you use the low temporary target approach when eating slow absorption foods, you can extend the action of the loop to give you some cover.

@Terry4

are you using one or both of these do-it-yourself open source systems?

I’m using both, as I mentioned in the OpenAPS topic. I find the portability of Loop to be great, and it’s a great way to show off what can be done, but I also find the OpenAPS algo requires a whole lot less thinking about, which is what an “artificial pancreas” is about, after all.

[Terry4]

I just saw my new endocrinologist yesterday. Since I moved in the spring, I had to line up with a new doctor. I made the appointment in July for yesterday’s December date. (Wait – I thought only the Canadians had to wait for health care!)

I showed the new endo my Loop artificial pancreas and he quietly listened and asked some thoughtful questions. The office had downloaded my Dexcom CGM and the doctor looked at the 14-day Clarity report. Here’s what he saw:

Here are the summary statistics:

The doctor was impressed with the numbers and he also compared the previous 14-day report that showed a marked improvement from the first to second period. He found it very interesting and my appointment went beyond the original schedule. I think there must have been some odd feelings with this seasoned doctor as medical solutions have almost always moved from big pharma through the doctor and to the patient.

My office finger-prick A1c came in at 6.0% and didn’t surprise me. My lab A1c’s have always been about a 0.5% increment higher than the Clarity reports. My 30-day Clarity estimated A1c was 5.6% and the 90-day was 5.7%. In any case, I don’t think any individual A1c is a good statistic to guide everyday care decisions. In fact the number that impressed me the most was my 14-day time in range of 92.1%. That is directly the result of the Loop A/P.

[Tia_G]

Woo hoo! So happy for you @Terry4. We’re finding it is just such a useful tool. So thankful for all the great people who worked on this technology. It truly is life-changing for us.

[WestOfPecos]

@Terry4

I showed the new endo my Loop artificial pancreas and he quietly listened and asked some thoughtful questions. The office had downloaded my Dexcom CGM and the doctor looked at the 14-day Clarity report

@Terry4, this is quite amazing for us, and a truly wonderful thing for you. Thrilling.

Thank you for sharing all this.

[Trying]

Fantastic results, @Terry4! I agree, the 92% in range is the most important and impossible for me to attain. Maybe one or two days but never 14 days straight!

[Terry4]

@Trying

Maybe one or two days but never 14 days straight!

I know before the Loop I could produce numbers like this a few days at a time, but doing it for even three days in a row was difficult. I’m getting better results with less effort. Thank-you for your comment.

[Lucia]

Thanks for all the info, and congratulations on your continued improved numbers and time in range!! Really impressive and inspiring.

I use a 6mm canula, as I’ve had much worse absorption/numbers with the 9mm. I find the first few hours/half day, and sometimes last day of a set my numbers aren’t as good, which can be half of the total! But it’s reassuring to hear that others have these issues too.

Finding good sites is crucial, and I’m limited in which ones are comfortable, but try hard to rotate as much as possible. I HATE to take out a site before the 3 days, because of cost and waste…but if it’s painful or just not working I will of course.

I’ve had some bad reactions that start on the 3rd day (pain, itching, big hard red lumps), which has somewhat been resolved by switching between Humalog and Novolog every few months, once I start having a reaction to one, I can switch back…
So many variables to look at - always! Thanks for your help.