Category: Uncategorized

(Pull up a chair, this is a bit of an involved post)

UAM is “unannounced meals” feature in oref1 for OpenAPS.  You can read about UAM features and its development in Dana’s blog post here.

Here’s how my thought process has gone on UAM since I first read about it:

1st thought: Oh, I won’t need that since we always enter our carbs and prebolus.  UAM won’t offer me any improvements since we always “announce” our meals.

2nd thought: Well, there are times (ahem, school snack bar) where Anna or I have some hard carb counts.  I wonder if maybe when we were 20% off on a carb count, perhaps UAM might help then?  Because if we are 20% off on a carb count, that would sort of be like having 20% of an unannounced meal, right?  Hmmmm…let’s try enabling it and see.

3rd thought: Wow, that worked really well.  But WHY did it work well?  How is it different?  Oh piss…I’d better roll up my sleeves and look at code.

And that is how I ended up learning more about oref0’s logic for setting temp basal and (now with oref1) setting SMBs.

---

Side Note: If you care to do the same as I’ve done…the logic for how oref0 sets temp basal and gives SMBs is laid out in a file called determine-basal.js in GitHub.  This same file is pulled into your rig when you build your loop.  I’m not a code person, but a slow and methodical read of the file can provide some insight into the logic for how temp basals are set.  Plus, there’s certain lines in that file that start with “//”…those are plain english notes to help readers understand the code that follows the note.  If you start with the // lines, that may help anchor some of your read of the file.

---

When I went to the first endo appointment after diagnosis, I was shocked that they didn’t have a flow chart to tell us how to dose insulin.  Like those decisions flow charts that say “if answer is yes, go to this next square…if the answer is no, go to the other square.”  As I came to learn the hard way, the answer to “How much should I dose for a BG of 250 mg/dl?” will have about 18 questions that follow it before you can give an answer.  What’s her ISF?  What’s her IOB?  Is she exercising?  Is her BG rising or falling?  Did she eat recently?  How long ago did she eat?  How much did she eat?  How confident are you in the carb count?  Is she stressed/excited/nervous?   And so on.  It’s no wonder finding a babysitter for a T1D kid is almost impossible.

The same complications exist for loop logic.  Depending on whether BGs are rising/falling/steady, how fast BGs are rising, whether food is at play, and whether temp targets…how does your loop take those into account?   I’d previously heard OpenAPS developer Scott Leibrand refer to “blending” things like this into his loop, but I didn’t quite understand the term until I really looked into the determine-basal.js code.

So how does that blending work?  Traditionally, you’d start loop math using just insulin and carbs to predict future BGs.  You’d approximate how the insulin would behave based on published insulin effectiveness curves (like peaking insulin activity around 60-90 minutes and then tailing off) and you’d approximate carb absorption (like the Loop system does using the model from Think Like A Panceas).  You’d add the downward effect of insulin and the upward effect of carbs and voila…a predicted BG curve blending insulin and carb effects.

But, a good loop will go beyond that simple approximation to try to help with things that are happening outside the perfect-world scenario.  Things like “retrospective correction” and “BG momentum” in Loop system attempt to incorporate the “wtf is happening now? I’m not sure.” part of diabetes into a better BG prediction.

OpenAPS does this refinement through the use of several different predicted BG curves.  Ever wonder WHY OpenAPS has all those purple lines showing in Nightscout?  This is the reason why…those lines are the drivers of the logic.  They help blend the various scenarios about rising/falling/steady BGs, recent food, and activity to come up with a better chosen predicted BG curve.  And a better predicted BG curve should yield a better loop decision…avoiding lows and quicker recovery from high BGs.

Ready for this?  OpenAPS has the following types of “basic” predicted BG curves:

• IOBpredBGs: based on insulin only
• COBpredBGs: carbs and insulin together
• UAMpredBGs: “floating carbs” and insulin together

That’s not the exhaustive list of curves used though…depending on the situation (rising BGs or falling BGs, for example), OpenAPS also does other calculations using the predictedBG curves (for example, minPredBG and avePredBG) to help provide for safe looping.

Basically, determine-basal.js has a whole bunch of “if this (is happening), then do that (use THAT particular predBG curve to determine the delivery of insulin)”.  For example, IF carbs are on-board and UAM and SMB are enabled, and BG is rising but not as much as expected, and IOB is negative, and prediction is above target…THEN use the XXXpredBG curve to calculate how much insulin to deliver.  If you change any one of those IF inputs…like BG is instead dropping and faster than expected…then OpenAPS is going to make a different decision about how to adjust insulin delivery and may use a different predBG curve to do that.

So, determine-basal.js is that complicated set of 18 questions involving “IF this and this and this and this but not that or that, THEN that” that we all used to go through before giving a dose of insulin.  It even has an IF-term called “Deviation” which is basically a measure of how far off expected BG behavior you are.  Looking at the deviation term is a big part of the OpenAPS decision IF-logic.  We’ve all used it before…”dang it, she SHOULD be dropping right now, but she isn’t!”

That’s where UAM and floating carbs come into play in a new way.  Previously, looping was constrained mathematically around meal-times by the amount of carbs entered.  The COBpredBG curve could only go so far in its prediction of BGs because it was limited to the carbs entered.

UAMpredBG is not restricted to the carb entry you’ve provided.  In a way, it doesn’t “trust” your carb entry as much.  It fact-checks your carb entry by looking at deviation comparisons.   More mathematically stated, UAM is predicting the future BGs based on the slope (rate of change in BG) of your actual BGs during meals.  [“during meals” is user-defined as either having carbs on board, an eating soon temp target, and/or a bolus given].  So, if your BGs are rising during a meal and they continue to rise beyond what was predicted on carbs alone (strong deviations happening), UAM is going to carry that prediction forward…regardless of the carbs you entered.  And it will carry that forward until the slope stops and things settle down.  Without UAM, that continued BG prediction up would’ve been restricted shortly after the meal was eaten by the fact that the carbs would’ve decayed ( COB=0 ) fairly quickly based on the rise in BG.

So, do you ever find that perhaps you under-counted carbs?  You’ve watched a meal’s BG climb after unknown sauces and unidentified ingredients were clearly playing a part in the meal?  The recovery to target BG in that situation can be slowed by the fact that the carbs were eventually all “used up” by the loop logic to explain the rise in BG.  Any additional rise the loop had no explanation for, and tended to treat delicately (slowly).

With UAM, the curve says “I can see these deviations were not expected.  I will help.  Even if the deviations go beyond simple explanation of what COB would expect.”  So that mathematical freedom helps for poor carb counting.  (It’s not unlimited freedom, there are still safety mechanisms in place.)

Case in point…that mini McMuffin of unknown carb count.

See how the UAMpredBG is headed to 294, while the other predictions have lower eventual BG predictions?  UAM is taking into account that Deviation of 67 and COB of 16g…saying “wow, you have NOT shown the BG behavior that I would’ve expected at this point in time for the carbs and bolus you’ve told me about.  I’m gonna trust your carb entry less and instead trust the deviations more.  If my predictions are right, you will need 1.85 additional units of insulin to control this unexpected deviation.  But, predictions can change.  So let’s give you a SMB of 0.4 units to help with that right now.  If I’ve overshot my estimate, I can suspend enough basal later to fix. But that 0.4 is a good help right now for your deviations I’m seeing.  Let’s try that, we will regroup with the next BG and see where you are.”

The next BG reading comes in and loop has some new information to consider.  BG has slowed down and there’s more insulin on board from the 0.4 SMB.

Deviation is now a smaller number (the slope of the rising BGs has decreased), we are moving closer to what the expected behavior should be.  In fact, the UAMpredBG curve now predicts an eventual BG of 104 and the insulin required is now -0.12 units.  So, loop will suspend basals and wait for the next BG to come in…and go through all of its IFs and THENs again before deciding what to do with insulin.  The loop is beginning to be able to trust cob again; it has delivered enough insulin to cover the carbs that we undercounted and, through SMBs help too, we are going to spend less time out of range.

What about situations where you OVER counted carbs?  Will UAM be able to help there too?  Yes.  When UAM is not seeing enough carb absorption compared to what you’ve told it to expect (“hey, you promised me 25g carbs and I’m only seeing enough BG impact to trust that you ate 10g of carbs”), then the loop will hold off on basal insulin and dosing until the BGs catch up.  (See…it’s comparing those COBpredBG curves with the UAMpredBG curves to make decisions.  All those little purple lines and deviation values are part of the logic sequence to deliver insulin.)

Because UAMpredBG curve is not limited so much by your actual carb entry, it will tend to have a much more variable prediction after each new BG entry.  It will predict very high eventual BG if your BG is strongly rising, and then it will predict lower BG if your BG is dropping.  So, if and when, you decide to enable UAM…don’t be surprised by seeing an ever-changing UAM curve, that’s an expected result since it isn’t quite so restricted by your carb entry.

As I understand it, it took several iterations for Scott and Dana to figure out the proper blending (IFs and THENs) of UAM into the oref0 determine-basal.js code.  Then there’s been many early users that have put it to the test to validate or improve the blending.

Where I’d previously thought that UAM had very little value, because we always enter our meals and prebolus…turns out I was wrong.  I’m not a carb-counting expert.  I get it wrong sometimes.  And UAM helps mop-up my harder carb counts, in both directions.  When I’m right on carb counts, UAM plays almost no role…but with UAM I’m not going to be nearly as BG-impacted when I do get things wrong.

 

 

Now that we’ve had some time with SMBs enabled, I was ready to consider trying the other new feature called UAM (unannounced meals).  I wasn’t previously interested in this feature much, because (I’m lucky) Anna has only forgotten about 2 boluses in her 2+ years of mostly independent bolusing.  So meals generally don’t go unannounced.  I didn’t imagine there would be much value in a feature named “unannounced meals”.

But, then on some random school mornings…I am reminded that I should keep my options open.  School “nutrition” break is at 10:10am.  By 10:15am, I see a bolus come in on Nightscout.  And I think to myself “Huh, I wonder what that will be because I know she didn’t pack a snack today.”  By 10:30am, I see the BGs starting to climb and I wonder how it will go.

Nutrition break is never about quality food.  The things sold by the school for nutrition break usually involve chip bags, mini donuts, twizzlers, and the like.  These snacks are problematic because  (1) we don’t have a lot of practice for these foods because we don’t generally have lots of these particular foods around the house and (2) they are being eaten at a time where she doesn’t have a lot of time or interest in babysitting her BGs or IOB.  Also problematic is that pesky independence that Anna is really quite interested in.  She doesn’t want to tell me what she’s eating, nor does she want to have me telling her how to bolus things much these days.  She will tend to still ask me for input on new food boluses when it’s just the family around…but when she’s around her high school buddies at school?  Forget about it.  So, iteratively improving her bolus techniques for these foods is hard to do given the lack of communication on these snacks.

Anyways, I turned on UAM on Sunday late night with the thought that maybe Anna and I would have some help during those nutrition snacks.  My theory wasn’t that she isn’t bolusing or entering carbs…but that perhaps the carb counting on those snacks was particularly difficult and our desire to keep her independent probably wasn’t going to allow for much improvement on proper carb count/bolus techniques for the snacks. I really do value her growing self-confidence and want to cultivate it by not hovering on every new food and new bolus…but those nutrition snacks test those limits.

I didn’t tell Anna about the new feature, but she must have had that sixth sense because on Monday’s nutrition break…she decided to test it.  My pebble started to alert me around 10:45pm that her BGs had climbed above 130.  When I pulled up NS, there was 50g of bolused carbs entered.  BGs were climbing, but SMBs were started.  I sat patiently as I could.  But, eventually the curiosity got to me when she got to about 180 mg/dl.

So nice of her to be testing the new feature with exactly the part that I thought it might help with…some random new food that she was completely guessing the carb count on (without me involved).

Things went awesome…I was so impressed.  Somehow the rapid rise from that mini-McMuffin was halted pretty well and the decline back to target was looking smooth.

Sadly though…that experiment would have to end early.  Her rig’s battery came loose and looping stopped.  She couldn’t see that the wire had come loose so we just lived out the rest of the day old-school…no looping. (but look at how well those BGs slid in close to target of 90 even after 43 minutes of no looping.  UAM/SMBs sure did estimate that needed amount of suspension pretty accurately from a fair bit ahead of time)

When she came home on Monday and I suggested that maybe she could run the experiment again…she was more than happy to oblige.  So, today she got the mini McMuffin again and did the same bolus and same carb entry.  Started the meal looking pretty similar to Monday.

The UAM/SMBs worked together to control that peak BG as best as possible…looked good.  I like how even though clearly the sandwich may have been a little different carb count (or her prebolus time was a little longer today?), the loop was reacting well to the BG behavior rather than simply the carb count.

But then I got a little leery when I saw this…was the bottom falling out?

My worries were unfounded.  The loop’s math was solid.  We gently landed pretty much at our target of 90 mg/dl.

I’d say the experiment has been a solid success.  One of the biggest things I notice is the way the loop successfully managed this same meal without prejudice.  What do I mean by that?  It reacted to the ACTUAL BGs that it was seeing really well rather than seeming overwhelmed by strictly the carbs entered.  At the peak BG on Monday, Anna was carrying about 5.34 units of IOB.  At the peak BG on Tuesday, Anna was carrying about 3 units of IOB.  To have both of those peaks resolve close to target without overshooting or needing a low treatment or intervention is pretty impressive.

The question is “If it was UAM that did this, HOW did UAM do this?”  I spent a good portion of the day exploring the answer to that question.  And the answer probably deserves its own post.

---

There’s a line in the movie Labyrinth where the main character Sarah has an epiphany and says to the evil Goblin King “You have no power over me.”  I feel like I’ve just gotten to say to the snack bar “You have no power over me.”

Doritos are still devilish on BGs compared to a low-carb muffin, but at least the BGs are being handled better than if I stared at them and tried to micromanage with 8 text messages and distractions.  Anna comes home and tells me about the things she did with friends and her homework…no need to discuss how to do the snack bar “better” the next day.  What a freedom.

One of the most commonly asked questions I see is “How does OpenAPS handle periods?”  Well, lucky me!  I happen to have a teenage girl using OpenAPS…and a blog.  And she is open to bribes to allow me to opine on periods and type 1 diabetes in a public settings.

We used autotune previously on our OpenAPS rigs, but ended up disabling it as a part of our normal loop operations*.  I still run it as a once-in-awhile check, but mostly now depend on autosens for making our basal and ISF adjustments.

A quick note:  Autotune runs once per day (shortly after midnight) to create a new “autotune-profile” that your rig will use for the day with basals and ISFs based on the tune it performs.  The degree to which this autotune-profile can differ from the profile stored in your pump is based on the settings you have in your preferences for OpenAPS.  Once that autotune-profile is generated, changes to your pump settings will not affect the loop until autotune runs again at midnight.  And even then, the new pump settings are only a starting point for autotune to use.

The reason we disabled autotune was two-fold…(1) I don’t like being locked into a profile for the whole day necessarily because (2) hormones (or medicine) can cause us some pretty dramatic changes.  It’s not every month that we get hit super hard.  But, certainly sometimes, the swings needed in our pump settings are really more than you could reasonably ask from an automated program. And they happen in the matter of a couple hours or even less.

We switched to using just autosens for helping us with basal and ISF changes.  It has worked TREMENDOUSLY well.  We have numerous times that it has been able to fairly quickly (within 2 hours or less) detect periods of changing insulin needs and kept us steady, even when I wasn’t paying close attention.

But, every once in awhile, those hormones just come on really strong and fast.  More than autosens can control.  Sunday morning was one of those times.  The morning started off nice and steady.  No signs of problems in her basal rates.

But, when she woke up in the morning around 10am, she informed me her period had started.  Which then led to this by lunch time.  No food involved, and that BG was climbing.

When I saw the SMBs start up shortly after a manual bolus and no food…I knew that it was time to take this basal change more seriously.  Those little SMBs are a good visual clue when it’s time to take more action, I love that.  This was our first time going through a hormonal change with SMBs enabled.

The first thing I did was go to autosens to see what it was autosens doing for me.  And I could see that it was trying to help bring down that high by using temp targets…adjusting target down to 80 from 90 mg/dl to help.  Good.  But, it was also Mother’s Day and I was at the movies on a date with my husband.  Kids were home alone, and I left things alone for the rig to watch and do what it could.  No basal adjustments were made manually at that point.

But, by later that evening, it was clear that the period was not going to simply autosens away, this swing was bigger than some of the others we had.  The SMBs were again a useful visual clue that things weren’t settling down, even with a good front loading of insulin. We were holding steady, not coming back to range.

So, we started to make some manual adjustments to basal, and used autosens to “validate”, in a way, our changes.  If we kept seeing no drop in BGs and autosens adjusting stronger…we knew we needed more.  So, we bumped up from 0.8 to 0.85.  And then from 0.85 to 0.90…

In the end, we have adjusted from a basal of 0.8 u/hour to a basal of 1.3 u/hour to keep her BGs steady.  Which actually corresponded to the amount I would’ve guessed on the correction boluses that it was taking to keep her steady (although above target).  It’s taken us almost 24 hours to make those adjustments, moving about 0.05 or 0.1 u/hour increase at a time. (I did them incrementally and watched how the changes behaved before adjusting again.)  I could’ve just jumped to 1.3 u/hour, as it is a basal rate we are used to with periods, but I didn’t want to overshoot and the loop was doing a good job of keeping her reasonably close to range despite needing over 60% more insulin than usual.

Where do we stand now?  Close to 24 hours since the insulin-resistance started…

Looking at her autosens right now, it’s still seeing that 1.3 u/hour isn’t cutting it and is using a 1.55 u/hour (and a stronger ISF).  Which doesn’t surprise me given the recent SMBs needed to keep her in range.

I will just opt to let the rig take care of things for the rest of Anna’s school day before we make anymore changes to her pump settings.  These insulin-resistant parts of her cycle are powerfully strong, and used to be really hard to know what to do with.  But, between autosens’ numbers and SMBs visuals, this was much easier to navigate without stress or high BGs.  Making changes to her basal wasn’t as mentally burdensome as it used to be.  And hooray for SMBs keeping an insanely good job on controlling hormone-related climbs.

And now I have to bribe Anna for the permission to post.

Panda Express isn’t the first thing most type 1s call a “fun time”.  It’s a lot of carbs, both slow and fast.  BUT, oh how Anna loves their orange chicken.  It was the first meal that had made us cry after diagnosis.  We were fresh off our first endocrinologist visit only few days before.  They’d emphasized still living life and “just count carbs and dose, you’ll be fine.”  We desperately wanted to not live in fear and give her a small bit of her old life back after what had been a very tough week.  We picked up a plate of orange chicken, carefully weighed out the food and calculated the carbs.  We bolused 6 units, waited 15 minutes and she ate.  When she was 398 mg/dl not long later, we all started to cry.  She swore off food.  I swore at diabetes (and orange chicken).  And all the insulin shots later to bring her down…oh we were miserable.

Things got better though.  We learned that fats and proteins needed to be involved in all those dosing decisions  We learned that we needed to split the insulin up over time to keep her from going low early and high later.  We learned that weighing food was not going to happen very often for us and we needed to get better at eyeballing.  But, we also still ended up staying up late at night giving multiple corrections, usually to treat lingering high BGs and then eventually to treat a low BG when the food finally gave up.

So where do we stand on Panda now?  We do pretty well, but it takes about 16 units and the meal lasts close to 7 hours of impacts to BG.  We’ve learned through trial and error about how and when to split up the total needed bolus over time to help get smoother BGs.  But, there’s still some difficulty to that.  Mostly the first part is easy…we give about 8 units of insulin at least 30 minutes ahead.  Another 3-4 units about 5 minutes before eating.  And another 2-3 units usually just after she eats.

The hard part is knowing what to do nearly three hours later when the first boluses have lost their steam, but the chow mein noodles are still plugging away.  I always wonder when the right time to do that tailing bolus is.  And how much.  Of course, doing all this in the middle of the night adds to the fun.

Let’s cut to the chase…I wanted to see how Panda did using SMB and what I may (or may not) notice as a result.  Below is a comparison photo of Panda meals.  On the left is Panda on normal OpenAPS use.  On the right is Panda on SMB OpenAPS use.

Overall they don’t look THAT different, but there were some really notable difference in experience.

Early low on the left?  That was just my bad…too much early bolus.  We cut back on how much we gave up front…so that was human error.  After that though is the interesting part.  And probably the part that will be the hardest part for people to wrap their brains around in SMB use.  See that large long swath of suspended basal in the SMB side?  Yeah…traditionally it would be the opposite of what you’d want to see in a meal with large carbs that hits hard later.  BUT…bear with me as we talk through the math and logic (and safety).

The interesting part begins when OpenAPS first starts to see a significant carb impact.  It’s set its first SMB of 0.1 earlier. And maybe it was prepping to give more?

And now let’s see what the logic is for the looping decisions now by looking at the OpenAPS pill…

The loop has seen a positive “deviation” (Dev: 165) meaning BGs have gone up more than the rig had expected.  The Eventual BG is predicted to be 170 vs my normal target of 90.  The loop also predicts that an extra 1.58 units of insulin will be needed to bring Anna back to target eventually (HOW COOL IS THAT NUGGET OF INFO?!).

And here’s where the SMB logic absolutely caused me panic and confusion when I first saw it.  The loop sets a 90 min temp basal and only gives 0.4 units of super microbolus.  Myself thinking “OMG.  WHAT?!  Suspending in the middle of a Panda Express meal for 90 minutes?!  And ONLY 0.4 units when it knows it needs 1.58 units?”

So…these panic points need a little explanation and understanding of the SMB logic and safety points.  The key part is to remember that SMB is designed to give you reasonably SAFE amounts of bolus needed upfront and use suspensions to balance them out.  Suspensions will be part of the regular looping behavior in SMB mode.  Suspensions can vary in duration…all the way up to 120 mins long.  These suspensions are important safety factors because if the rig has been front-loading you with SMBs and the rig suddenly fails…you want that longer temp basal to help keep you safe.

Single SMB amounts are limited by several factors.  The largest a single SMB bolus can be is the SMALLEST value of:

• 30 minutes of the current regular basal rate, or
• 1/3 of the Insulin Required amount, or
• the remaining portion of your max-iob setting in preferences.

For Anna, her regular basal rate is about 0.8 u/hour therefore we’d never see a SMB given greater than 0.4 units typically.

SMBs can be administered every 5 minutes.  If SMB thinks Anna is going high, it would be able to administer approximately 5 units in an hour of SMB use (assuming the other two factors were not limiting doses).  That’s a lot of insulin…more than enough to make up for the 0.8 units that would be suspended for safety-sake during that same period of time.  So, the suspension really isn’t that much of an issue in the overall math and loop ability to administer sufficient insulin.  But, if you really missed a whole bolus for a meal that needs nearly 16 units to control…yeah, you’re still gonna have a high BG before coming down.  Bolusing is still important in looping if you want to stay near target range.

The next part…why doesn’t the loop just turn the regular basal (or a high temp basal) on while it’s also giving SMBs to more quickly give the required insulin?  SAFETY.  This system still needs to keep safety in mind (and you want it to).  If the deviations and trends show a real need, those suspensions will be canceled…but only when they safely can be.  The loop needs to see the deviations and BG predictions and IOB all showing that it would be safe to do so.

If she needed 1.6 units of insulin extra, that could be delivered in just 12-15 minutes with SMB.  That’s not a long time to sacrifice for safety sake to make sure that all that insulin is still needed.  Makes sense to confirm the need by collecting a little bit of BG trend to confirm that need, rather than laying it all on at once.  Remember…this isn’t a rage bolus loop.  😉

Ok, so then what happens a little later?  Just as I suspected…chow mein noodles are really coming on now.  But, SMB had been adding to the IOB and helping out every 3 minutes.  I also knew that around this time is when I normally give the start of the 2-3 boluses that chase the Chinese Food effect.

So, I looked at the OpenAPS pill to see what the logic was offering up at this point in the game.

Now it’s showing an Eventual BG of 401 (probably not that far off for what Panda has shown us in the past).  The loop was still setting SMBs but now the Insulin Required had grown to 3.96 units.  That confirmed what I suspected.  This is the part in the meal that the tail bolusing needed to start.  And normally this is where I kick myself that I’d missed the rise.  I was going to be chasing this rise…ugh.  I chose to give 2 units of the 3.96 units it wanted.  I figured that was sort of split the middle and provide some help, but also give some wiggle room if the meal also suddenly stopped BG impacts.  After all, diabetes rarely does the same things exactly the same in repeated experiments.

It worked great…except it was about 11:30pm, and I was ready to stop watching the experiment and go to bed.  I still had (my old logic) in my head that I’d probably waited too long to give that last bolus.  So, i gave another unit absentmindedly and called it a night.

Except it turns out that was a mistake.  I’d underestimated (and not looked at) how much the SMBs had been doing before 11:30pm.  That last bolus was not necessary.  So I gave a little juice (hence the climb at midnight) and then really called it a night.  Lesson learned (again): SMB do an excellent job of fine tune fixing when the insulin required is less than about 2-3 units.  Not a good idea to give extra corrections when the insulin required is that little (I cannot believe how I’m even able to write that 2-3 units is a loop correctable within comfort zone amount now…freaking amazing).

As you can see, SMB and OpenAPS took care of the rest of that meal no problem at all.  In fact, it saved me an extra bolus AND a temp target in the middle of the night that I used to have to do.  Thumbs UP.  I’m all for more sleep and less manual bolusing in the middle of the night.  And we got to wake up to this:

Kind of funny to see that my error caused the worst BG of the night.

My lesson from this:  SMB is a good help to know WHEN to do later boluses in extended bolus-type meals.  The Insulin Required estimate is a good help for deciding when a manual correction is needed and to provide a rough estimate of how much to give.  If the Insulin Required is over about 2-3 units, we will use that as an indication that a manual bolus will help.  I will likely never give the whole amount (since large meals are prone to so much carb counting error), but giving about half the required amount and letting SMB pick up the sloppy edges worked really well.

There’s a couple other random lessons about see RAW data (did you notice that her CGM pooped out early in the meal?!) and using bolus menu while SMBs are enacted (might require some habit changes…we are thinking about how to handle that).  I’ll post those items separately when I have more time.  Now I need to prepare…Anna has a BOY coming over to the house tonight so we can meet him before we allow a “date”.  Can’t wait to see the BGs from that.

You may have heard that OpenAPS got a couple new features in development…super microbolus (SMB) and Unannounced meals (UAM).  I’m currently testing out SMB features this week…seeing how they work, trying to wrap my head around some new ways of thinking, finding out if we have to change anything in our patterns.  I thought I’d report in on how that’s going.

We started SMB just before going out of town for a wedding.  Not a big deal except…lots of “perfect storm” events conspired against us in the usual diabetes way.  Anna wore a dress (hard to access pump and we had some unbolused food as a result), the music was loud and I misheard her food choice (and therefore gave her a bad carb estimate to bolus for dinner…she ate a large brioche bun and pasta.  I heard chicken.  yeah…you know where that went.), we happened to be in the only cell dead spot near LAX for several hours where I wasn’t paying any attention (and therefore I can’t say how the system would’ve behaved because it was offline).  We even had a couple random pump resets that made us need to reset the pump time (which proved to be important learning lesson on smb…pump and rig time must be within 60 seconds of each other).

So, a rough start just for my mental preparedness (although BGs on Sunday after the wedding were great).  We went back to normal non-SMB use for Monday while I read some more details about SMB and UAM.  I needed to understand more about the decisions and actions because I was not so pleased at first glance (there’s a lot more “suspend” after meals than I was mentally prepared for…I needed to understand how those played a part).  After a lot more reading, we restarted with SMB.  We are not yet trying UAM features…one step at a time.  Plus, we don’t usually have many unannounced carbs (thankfully Anna is a pretty diligent bolus unless she is wearing a dress, at a wedding, in a cell dead spot, with large brioche buns around.)

We restarted SMB yesterday and have been running it since.  I am very pleased with it now.  The basic idea is that SMBs are given in little increments earlier to help control a rising BG, as opposed to waiting the whole 30 min temp basal to deliver a needed insulin amount.  The program only gives as much as it can safely temp suspend for later…like the idea of a traditional super bolus…just on a micro scale and with the aid of a computer doing all the math better than my brain or time can permit.

Want to see some examples?  How about last night…

 

Here’s her 15g dinner (yes, low carb for this one).  But, it nicely suspended and prevented a low early after the bolus…and then SMB picked up on the tail end of meal when it needed to come back online.  See those little tiny boluses of 0.1 and 0.4 units?  Those are SMBs…automatic little boluses of insulin.  The only time she touched her pump in the above graph was the 15g meal bolus.

You can also see an earlier SMB help with controlling a rebound from a low treatment at school.  Why did she go low?  She gave a correction after cheetos-involved lunch without noticing that SMB already had done so.  So, note to kids…no corrections with SMB.  She’s pretty happy with that instruction.

How about her school mornings?  Here’s this morning…

Before DIY closed looping, school mornings were such a cluster @#$%.  We had huge basal set from 5am-8am plus an extra (always a guess) bolus when she left the house to help control the school morning nerves.  And then, this year, she has PE second period…oh but wait…not always second period because it might be a block day schedule.  You parents know what I’m talking about…always having to stay on my toes about what day of the week it is and make sure the bolus/basal program is the right one.  We regularly battled 220s in the morning using that system.  Plus interrupted her school day with about 5 text messages to try to get things right.

Then we got on Loop and OpenAPS…so much better.  We had to keep the basal patterns different for school days vs weekends when we used Loop…but that was ok.  When we went to OpenAPS, we’ve only used one basal pattern and autosens has taken care of our basal changes (magic?!).  But, we have still had about 75% of the mornings where she slowly climbs to 120s and even 130.  When her BG hits 130, Anna’s pebble will buzz and she mindlessly gives herself a set correction of 0.5 unit. (Parent note: Teens will not do math to check how much a loop has already given.  We finally told her to not give more than 0.5 unit for correction anymore, which equates to about a 15 point BG drop for her ISF.  That amount seemed to keep her from overcorrecting but also helped out on those days where she needed some help.)  We were pretty happy with this system because we no longer needed to text her, she wasn’t overdosing, and our basal switching around was no longer necessary.  Win-win-win.

And now two mornings on SMB have been flat-lines.  Like above.  It’s not a big sample set yet to draw conclusions, but I’m loving it.  I know SMB is playing a part (I can see the SMBs on my graph after all…none of those were administered by her or I.  She has been told to give no manual corrections while we test this SMB stuff.)

But also look…that 8g snack snuck in around 10am.  What is that?  I have no idea.  Fruit cup?  Likely.  Well she bolused for it but I have no idea what it is.  Here it comes…

I don’t interrupt with a text message asking what it was.  I don’t intervene.  But I do get to watch and that was fun.  So what was OpenAPS doing when that climb started?  It lowered her BG target. (This is a new feature, too.)  We normally have her BG target set for 90-90 mg/dl.  We have allowed OpenAPS now to temporarily lower her target when her BG rises like this to help get insulin in a bit faster.  Basically, it’s like having OpenAPS automatically set “eating soon” mode for me in these situations. That temp target adjustment also will be automatically stopped when not needed anymore.  Very nice.  (I will still need to watch how it behaves in other situations like exercise.)

OpenAPS also increased her basal reasonably and gave her a starting microbolus of 0.4 units based on this unexpected deviation up.

And then more BG data came in…and I could verify the 0.4 unit SMB had been given.

At that point, OpenAPS wanted to do a 0.1 unit SMB and lower that temp basal.  Things were slowing down, but not done yet.

So then we seemed to peak out about here…

Before starting a smooth decline…thanks to about 0.7 units of help from SMB, temp basals, AND suspended temp basals afterwards…because that’s how SMB works.  Able to give some reasonable part of the needed help up-front early and then suspend later.  Super nice.

But wait, that teen wasn’t done.  It’s lunch time now that I’ve spent all this time writing up the morning.  And so it begins for lunch…

OpenAPS will be there, helping with some SMBs and temp basals.

Note: I realize the BG control represented here is tight.  BUT, did you also notice that it was completely hands off?  I haven’t texted Anna.  She hasn’t done a correction.  I didn’t adjust a target, nor did I adjust a basal or ISF in over four weeks.  It’s been automated.  She has only done her usual bolus for carbs.

We will keep testing things out for awhile.  Keeping a close eye on things…looking if we need to change our habits, change our settings, or wear fewer dresses at weddings.  I’ll be back with a higher carb day (Panda Express anyone?) and more details on that (foreshadow though…she ate two Randy’s donuts for breakfast and in-n-out for lunch on the way home from wedding. And it was nice…I just didn’t grab screenshots.)