IOB using OmniPod

My son is using OmniPod for a while now, and since we know that it does not calculated IOB from carbs, we pretty much just manually deduct the left-over part of previous meal from the correction, if the correction is less than 3 hours from last meal. It seems like a normal situation for us, since he is a toddler and eats every 2-3 hours all the time.

He started to go to a day-care, and I am confused in how to adjust the PDM, so they could correct without calculating manually. Any suggestions?

For example, he eats around 8am at home and then at 10 he has a snack. Sometimes he is already high at that time and they correct, which makes him crash down because of huge IOB from breakfast.

How do you all deal with this?

Faina,
One way is when doing a meal/carb bolus, just write down the PDM’s suggested bolus, then don’t proceed and just cancel out of that. Now just do a normal (correction) bolus and use that previously suggested amount. This way I think the bolus will be considered a “correction” bolus and the whole amount will be in the IOB calculation.
Cheers,
Gil

Thanks, sounds good, except… This way it will count it as IOB even if there is no correction.

So at 10 am snack he will get free grams, since the pump will think that there is a ton of IOB from breakfast.

And I do not want to switch off the reverse correction for day-care, I need it to make sure he will get free carbs if needed.

Does he usually need a small amount of correction mid morning? Or could they bypass the correction at morning snack all together by clicking the “NO” on use for bolus calculations - or click “NO” unless he is over a certain amount?

This might be a pain, but if they do correct mid morning, have them check one hour later to catch the crash before it gets bad? Not an easy situation! I feel for you!

You could also raise his I/C ratio during that window to compensate. My son has exactly the same pattern. He stays a bit higher in the morning and then by lunchtime comes way down. During school, I usually have him eat a snack with no bolus at all. We have also brought his I/C ratio up for that 2 hour window.

Yeah, thought about not correcting, but again, they need to say “Yes” to use reverse correction. Otherwise, even if he is lower than I want him to be for a day-care, they will not bring him up.

Brrrr, this is impossible…

I even tried calculating different targets/correction factors to account for approximate IOB, but OmniPod does not let me set upper limit for corrections higher than 200… And I do not want to correct if he is less than 220.

You mean, I/C ration up to compensate for IOB in case of correction? In this case if he is in a normal range he will go up, correct?

Huumm… then maybe you should use my suggested “cancel out” scheme only for the “meals” (breakfast, lunch, dinner) but not for the “snacks” (mid-morning, mid-afternoon, and if applicable, late night), so that way it will be like they are more than 4 hours apart… sorry, that’s a tough one.

Thinking of the little “charts” school nurses would have with children on MDI - Maybe a system like that, It would require the day care worker to do a little thinking, but still use the PDM. A little flow chart of sorts, with a number range - if between (lower numbers requiring reverse correction) YES for bolus calculations, or if between other numbers “no” use for bolus calculations?

I think I would turn off the correction, and just treat it as mdi - if over 250, add 1 unit humalog, if under 100, add 15 carbs to meal. etc…

Does your dr. or diabetic educator have caregiver forms, or suggestions?

There are alot of us on this board that are dealing with the same issue - trying to get people other than yourself to understand that our child’s pump does not account for carb boluses. The good news - the new PDM (when it finally gets approved) WILL account for all insulin.

But for now, I have dealt with it two ways. The first, I told his school to NOT let the Omnipod account for that blood glucose number when giving him a snack before the 2-3 window is up. The bummer about that if he is unusually high, it does not get corrected. This summer, for summer camp, I tried something new. I changed his “Target BG” for the morning snack time frame. So instead of it correcting him if he’s above 120, I have it only correct if he’s above 180. This has seemed to work better. The only bummer here is that you can only have four timeframes entered, so it is limiting.

Millions of limits:
4 correction timeframes
4 IC timeframes
Upper trash hold only goes to 200, and we do not want to correct if he is below 250 etc.

Thanks, at least I know that other people are struggling too… and it is not that I am just missing something simple.

I understood from OmniPod that the next generation of PDM will still not calculate IOB for carbs.

The thing with MDIs was the same… I can not add 1 unit of humalog if over 250, since it depends on how long ago he had his last carbs. Sometimes I can not correct 250 at all, and sometimes I need a full correction.

I can’t remember where I heard it from exactly, but I do remember thinking it was a very reliable source (omnipod annual report? a response from omnipod directly?). The PDM units in Europe already have this feature. They would be crazy not to add it - if so, the Solo pump will blow them out of the water!

Solo is waaaay out there… Who knows if it ever will show up?

Faina,
I’m trying to define parameters for anew diabetes management medical device (pump, cgm, etc). Please help me out with a couple of questions:

  1. How many correction and IC time slots are ideal? 12, 24, 48?
  2. How high should the threshold be for skipping a correction? Should there be a limit at all?
    Thanks,
    Gil

Even if the PDM included all carb bolus in the IOB calculation, it would still not solve your problem, right? Or would it?

Earlier you told me if it did that then “this way it will count it as IOB even if there is no correction”.

I’m just trying to understand the ideal way to include different types of bolus in the IOB calculation, again for a future product features list definition.

Thanks!

I do not understand that statement either. You would want it to track it as IOB so when correcting the machine would be able to tell if there is a difference between how much insulin is needed for correction and how much IOB is still available. Simply put, if you give a bolus it needs to be tracked regardless of the the reason for the bolus. The only negative to what you had previously suggested is that when you download it will not seperate the reasons why you gave that full bolus.

When Roche bought Solo they said from the very beginning that at the earliest it would be 2012. My understanding from Solo’s website before Roche bought it was that it was already FDA approved. Roche said it would be delayed because they wanted to make sure they had the manufacturing to be able to meet demand worldwide.

  1. I can’t imagine more than 12 would be needed. If you go up to 24 you would never have a problem. That many actually programmed in and actively being used is making diabetes management too complicated.
  2. Because it is highly dependent on the particular person and the particular situation I would not put a threshold on it. Not sure what the FDA would have to say about that but FOR ME I do not want predefined limitations.

One thing I would recommend is to have different patterns for I:C ratios and correction factors like the current pumps have for basals to make it easier for people doing shift work. It has been a while since I used the OmniPod so they may have it but I know for sure Animas and Medtronic do not.

8 correction slots (meals and snacks and late night eating) and 24 I:C spots (actually my pump allows for an I:C change pretty much every hour if i use the PDA (Palm Pocket Compass) but its convoluted setting the ranges.



Im thinking 250 would be the MOST a BG youd want to skip a correction, id be more worried about the low end how low would you want to skip a correction for… Id put a limit so if someones floating over 250 something needs to be done… Id consider letting a higher limit but it should throw up a dialog telling the user… Are you sure you want to do this… Perhaps set a soft limit before the warning shows around 200, and have the warning dialog show if a higher limit is entered and require a confirmation, bit id set a hard limit at 300… at that point a correction is more than warranted…