FDA warning against DIY systems

I’d like to address, in my own opinions, the recent announcement of the FDA warning “against the use of devices for diabetes management not authorized for sale in the United States”.

First, there’s a lot of rumors out there and the headlines from the various places trying to “explain” the situation do little to actually give good information. I just did a search to find the link above and let’s just look at those headlines…how many were misleading ledes or otherwise really not getting the whole message correctly explained.

About the only article that really gets it right is the JDRF statement. But, the average person trying to sift through the information this is a very confusing topic admittedly…so let’s pull out some of the specific quotes from the FDA warning and talk about what they mean in plain terms. This really wasn’t about DIY closed loop systems causing harm (although that could be part of it, depending on the situation)…the underlying cause of the warning was about DIY CGM apps.

“The FDA received a report of a serious adverse event in which a patient used an unauthorized device that receives the electronic signal from an FDA authorized glucose sensor and converts it to a glucose value using an unauthorized algorithm. Glucose values from this unauthorized continuous glucose monitoring system were sent to an unauthorized automated insulin dosing device to drive insulin dosing. The automated insulin dosing system gave too much insulin in response to repeated incorrect high glucose values sent from the [unauthorized] continuous glucose monitoring system (emphasis added). This unauthorized system resulted in an insulin overdose requiring medical intervention. ”

Before we can look at what this means…it would be helpful for many people to have a really basic introduction to continuous glucose monitors (and this is the really layman version).

CGM basics

Glucose sensors don’t actually read a blood glucose reading. Instead they read a “raw signal,” basically an electrical signal from the fluid surrounding the sensor wire. That raw signal is then converted to a “blood glucose reading” by an algorithm. The algorithm that does that job is a HUGE chunk of work by the company that makes the sensor. They do lots of design, testing, clinical trials, and reworking on that algorithm. That algorithm is really, really important for demonstrating that the sensor will be safe for the users in a variety of situations. For example compression lows, poorly timed calibrations, and rapid temperature changes are just some of the difficult situations that an algorithm will need to deal with.

Dexcom sensors showing ??? or “sensor error, wait up to 3 hours”…that is actually a part of the safety algorithm. The sensor wire’s raw signals are either varying wildly, perhaps the calibration entered is way out of its expected bounds, or the temperature suddenly shifted a lot. The sensor algorithm is rightly telling you “Hey, I’m unsure about telling you a number and I don’t want you doing something unsafe with a number I’m not sure about. Give me a chance to see if the raw signals settle down again.”

All sensors on the market have safety checks and sensor failure communications built into their algorithms. They also have enforced end-of-sensor (for example, Dexcom G6 is 10 days) timing in the apps. These features are all part of the safety of using CGMs for diabetes management decisions, and they undergo FDA review.

X-Drip and Spike Apps

Have you ever just wanted to avoid the ??? or enforced end-of-sensor sessions? I know you have because this blog’s post on how to restart a Dexcom G6 is one of the most popular blog posts I’ve ever written.

There’s two DIY CGM apps on the market that avoid those ??? and session ends. The apps (X-drip for Android phones and Spike app for iPhones) are popular in part because they offer the ability to just “always get CGM data”. While nice on the surface, those features can present a problem potentially…and that’s what the FDA warning was all about.

X-drip and Spike use their own algorithms to handle the raw signals. Calibrations, temperature variations, sensor noise, sensor failure notifications and other variables within the algorithm are not clinically-tested for those apps. (note: Generally, X-drip and Spike use the same algorithms between the two apps for several of the supported CGM devices. Therefore, X-drip and Spike are generally going to behave the same when we are discussing the general topic of DIY CGM apps.)

Reported Adverse Event

So what happened to trigger the FDA warning?

Plain and simple…a person was using a Libre sensor on one of these DIY CGM apps. Libre sensors are not continuous glucose monitoring devices. They are flash glucose monitors. In order to make them into continuous glucose monitors, some people have used non-FDA approved devices that sit on top of the Libre sensor to emulate someone “flashing” their Libre for a reading.  Those devices you probably recognize as either the Miao Miao or Blucon readers.

Since these readers are not officially associated with Libre sensors…there’s also no clinically-tested, FDA-approved app to receive the information from these readers. And this is where the warning comes in:

“The FDA received a report of a serious adverse event in which a patient used an unauthorized device that receives the electronic signal from an FDA authorized glucose sensor and converts it to a glucose value using an unauthorized algorithm….repeated incorrect high glucose values [were] sent from the [unauthorized] continuous glucose monitoring system…”

Someone using (1) a Miao Miao reader and (2) a Libre sensor and (3) a DIY CGM app had a situation where the sensor failed. Instead of the sensor failing by then reporting no data (such as ??? or “sensor error” like Dexcom), the DIY CGM app showed incorrectly high BG readings.

What does this look like?

The image above is from another recent report very similar to the one discussed in the FDA warning (minus the need for medical intervention). Details of this event can be found in the OpenAPS Github repository.

The user had Miao Miao + Libre sensor + DIY CGM app. The recently restarted sensor started to fail with a drift. The user, rather than pull the failing sensor, tried to calibrate the sensor to the 16 mmol (about 288 mg/dL) value shown near 10am. The failed sensor took the calibration and remained virtually stuck. The DIY CGM app continued to report nearly 16 mmol for 8 hours…

So, let’s stop there and assess.

  • Are we irritated when sensors stop providing data and instead say ??? or “sensor error”? Yes.
  • Are sensors expensive and we try to get them to work as long as they can? Yes, many people do.

But, if automated insulin dosing is also a part of someone’s DIY CGM app use…those safety factors (and your ability to do without them) may need to be re-evaluated in terms of whether or not you want to continue to make insulin dosing decisions on them. Can commercial CGM algorithms still get data wrong? Yes, but it is far less common these days…and if they do get data wrong, it is very unlikely to be so “off” that an automated insulin delivery system would cause a hypoglycemic event serious enough to cause medical intervention.

Automated Insulin Delivery

The FDA-reported problem of the failed sensor still sending bad CGM readings through the DIY CGM app…it affected the user’s DIY closed-loop automated insulin delivery and caused the system to over-deliver insulin. The user needed hospitalization for the hypoglycemic event that occurred as a result.

The figure above with the 16 mmol? See below the royal blue marks at the bottom of the figure? Those were automated insulin microboluses delivered by the user’s OpenAPS system to try to bring down the 16 mmol. If unnoticed by the user, those insulin deliveries could have caused hypoglycemia.

Is this potential to over-deliver (or under-deliver) insulin unique to DIY closed-loop systems? Nope, absolutely not. And that is the message that all this news coverage is missing. The REAL story. Access to quality CGM devices is the underlying need to be addressed.

Any automated, closed-loop system (commercial or DIY) will only be as good as the CGM data that is feeding the system.

Medtronic’s 670G system will kick users out of automode when their algorithm has sensor issues. All commercial closed loop systems will have safety checks that if the CGM part of the system reports an error…you’ll be kicked back to old-school insulin dosing decisions.

CGM Data is Critical

Now that we’ve addressed the background, it is pretty obvious just how important keeping quality CGM data is if you choose to use any closed-loop system.

Only one iCGM system, the Dexcom G6, is currently FDA-approved for eventual automated insulin dosing across future integrated pump/loop systems (Medtronic’s 670G’s Guardian 3 sensor is approved only for their system in particular). This is the system we use and I love it. I feel very safe with its use and messaging. The first 8-12 hours are a little jumpy and I can choose to open loop if I want to…but otherwise the sensor has proven to be exceptionally accurate for the 10 days we use it. Despite the fact I wrote the blog post about how to restart, we actually don’t restart our G6 sensors. Anna enjoys fresh clean adhesive and the insertion is so easy for her that it isn’t an impediment to change sensors any more.

Unfortunately, many areas outside the USA do not have access to or approval of Dexcom G6. This leaves them either incredibly expensive or entirely unavailable. The Libre sensors are more widely available and/or affordable in those markets…giving rise to this dilemma about DIY CGM apps.

Ideally, the FDA’s warning message hammers home a point that really is sorely true. The access to quality health tools to safely manage T1D is lacking. T1D is so inherently risky. The slowness of the world’s government systems to help with access and affordability of quality CGMs is adding to our community’s collective risk.

Dear FDA…if access and affordability of quality CGM systems were addressed, DIY CGM apps would not be needed. Adverse events can happen on your FDA-approved devices as well. T1D is risky with syringes and finger sticks through the most advanced FDA-approved closed loops. The warning is that diabetes is risky, and we need quicker iteration and better development in the commercial markets.

People might not necessarily want to use a Libre plus a reader plus a DIY app…but in some cases they’ve assessed their risk management baskets and decided that setup IS their best risk mitigation.

To those people, please…

  • be exceedingly careful about not extending sensors to beyond their safe lifespan,
  • make very careful calibration decisions,
  • watch for signs that the sensor wire as even partially pulled out of skin, and
  • if in doubt, change your sensor and take finger stick readings.

For us personally, we are grateful to have an iCGM (Dexcom G6) and that we can afford to change it regularly. We use the official Dexcom app because those times of “sensor error” or “???” provide a level of safety that I find appropriate, rather than an annoyance, since we are using a closed-loop. We replace sensors when they show any sign of failure, and I don’t feel in the least bit guilty about it. And the use of our DIY Loop app has decreased our overall risk exposure while managing T1D…but I can only say that because our CGM data is reliable. And that’s what the FDA warning was trying to tell you.

Juicebox Method to Loop

To all those who said hi to me from the Juicebox Podcast, thank you! I see you and hear you…(and hello similarly to Sugar Surfers…this post is also for you all…basically for everyone who tends to “know their boluses”.)

You may have heard my jaw drop on the floor just a touch during the podcast when Scott asked if he needed to count carbs and know his carb ratio in order to Loop…and I think it’s time to write up a blog post to help you all transition from what I’ll call the Juicebox method to Loop. Because yes, you need to know your carb ratio and carb estimate. I’ve noticed for many of you this may be quite an adjustment if you don’t have a head’s up about how to make this transition from where you are with insulin surfing.

Why? Because you all have been insulin surfing without settings (and no, I am not typing that in a derogatory fashion). There’s a book called Sugar Surfing that has the same general underpinnings as what Scott his podcast are really good at explaining for the Juicebox method…think dynamically and react according to what you are seeing. Scott’s coined phrase is “Be Bold with Insulin” and it’s allowed a lot of people to transition from feeling like they need a restricted diet to meet A1C goal, and instead eating higher carb meals quite successfully and getting more consistent results. I’m a big proponent to this concept…it is basically the idea of lining up the insulin dosing so that it is most effective against carbs rather than restricting carbs. Even low carbers have also embraced this concept of lining up insulin and carbs appropriately by using R-insulin (slower, longer peak action time) and eating slower foods like proteins and fats…so the concept crosses a lot of user groups similarly.

The rub is that what if someone else was doing the reacting and thinking dynamically for you so that you could take a break? You can’t react while you’re asleep. Your kid doesn’t want to react while taking their math test. And all the button presses you can save?! That’s what Loop does 24/7 even while you sleep.

BUT…to get Loop to react, you need to feed it information about yourself and your diabetes. That information you’re going to feed Loop is your settings; basal rates, carb ratios, insulin sensitivity factor (ISF, sometimes called correction factor). And this is where Juicebox users will perhaps run into trouble because the method approaches diabetes from the end result (how much insulin to give) rather than the beginning (what settings will affect how much insulin to give). So, how can we get you from managing at the end result (insulin) and shift you to the beginning (settings and meal entries)?

Let me give you an example to help illustrate. Enter friend Jane Doe.

I set up a good friend, Jane, on Omnipod Loop before it was publicly released. I’ve known her for a long time and she has a little daughter, Princess Buttercup, with type 1. My intent was to see how the docs would work for Jane and fix places where she told me it was not clear enough to a new user. Also, I wanted feedback on what common pitfalls in the Loop app might be for new Omnipod Loop users and such. She was my canary in a coal mine (thanks Jane!).

Jane had been using the Bold With Insulin approach for eating for a long time. She knew which foods her daughter ate and how to administer insulin. Meals had a predictable good result. But, she didn’t count carbs much and didn’t know her settings really. Her endo had given her some PDM settings, but they were never really tested because she didn’t use them. Meals didn’t use a carb count and corrections for out-of-range or changing BGs were done by “feel” based on how quickly BGs were changing, not through calculating insulin on board and ISF. If she saw a slight climb in CGM, she’d have a manual bolus “feeling” based on so many times she’d corrected before in the same situations. If the climb was steeper, she’d manually give more insulin, also based on previous experience. The only setting that got any kind of real use was basal rates…but even those were frequently being overrun manually with temp basal rates she’d enact herself.

I asked her how new meals that she’d never tried before would go. Jane described that there would be a first guess at a bolus based roughly on similar other meals with those similar types of ingredients. She’d watch the CGM and adjust insulin manually. She’d track in her head how those adjustments worked out and the next time she bolused for the same meal, Jane would try to use what she’d learned from the meal the previous time. This meant that new foods were kind of a learning experiment, but she’d pretty quickly dial-in a “known dosing” for the new food within a few tries.

A couple days into using Loop, Jane was pretty frustrated but I hadn’t known it. She was trying to figure it out on her own (she is a smart cookie) and something just wasn’t clicking.

In almost a straw-that-broke-the-camel’s-back moment, it was a bagel that finally made her ask what was going on with Loop and why this wasn’t working. And that opened up my eyes to the Bold With Insulin approach she’d been using and where that transition needed help.

Here’s the rough conversation (and it would probably be very, very similar to a convos any one of you could have as you transition):

Jane: I’m so frustrated. I can’t figure out where I’m going wrong. She had a bagel. Prebolused. Typically a food I bolus well for, like never above 150. (And a screenshot of a definitely-well-over-150 dexcom graph.)

Me: How many units would you have bolused for normally for that meal?

Jane: Normally, I would have dosed 1.25 units like I did this time, but I would have doubled her basal for awhile. This time when I gave the 1.25 units, Loop suspended insulin while she was waiting out the prebolus time.

And that conversation gave me a lot of insight into the issue.

  • Carb counts weren’t a big (or even small) part of her method on a regular basis
  • Bolusing was all being done with tools no longer available in Loop (extended boluses and temp basals)
  • Carb ratio wasn’t even used…she just had the boluses memorized for given meals.

So how has Jane turned it around? (Princess Buttercup has had a 0.5% A1C drop in two months of Looping now and Jane’s getting sleep)

Jane rolled up her sleeves and got to work on her settings.

If you are in Jane’s shoes and want to set yourself up for an easier transition, here’s a few tips you can do now.

Settings Testing

To transition successfully to Loop, Juiceboxers and Sugar Surfers alike are going to need to do some settings testing and meal deconstruction. Likely in open loop for a bit if you want to keep your frustrations down to a minimum.

This means not correcting immediately when you are testing basal rates for example. This means doing things in a sequential testing route…basals, carb ratios, insulin sensitivities in an ordered fashion. And also, you’ll need to look at how you’ve been successfully bolusing your meals and translate that to Loop.

It may take a couple weeks to finish the route…but the end result will be that you have decent settings to start with and Loop will be a less frustrating transition. Let’s start…

Work on your Basal Rates

Juiceboxers and Surfers have a lot of manual insulin adjustments running frequently. Temp basals and extended boluses are not at all uncommon.  Unfortunately, this is also a good chance to have difficulty in identifying if basals (especially daytime basals) are truly set correctly. There’s a high likelihood that all parts of your daytime are touched by insulin remaining from an extended or temp basal that ran within the last 6 hours.

When you get into food habits, and have “known boluses” for them, you can basically have two wrongs making a perfectly great right. For example, send kid to school with her favorite lunches every day and those boluses involving extended/temp basals…you might just be covering not only the food in the meal but also some basal needs from the day at school. Same for the breakfast you’ve been sending her out the door with. Or maybe you’re bolusing less for lunch than you’d typically need because she has PE class after lunch. Those are instances where having two compensating factors are showing a good result in BGs outside a Loop…but you may have problems when you go on Loop without truly knowing you were compensating for a settings issue.

Checking basals is a pretty easy starting place. Basals, in the absence of food and exercise, is the amount of insulin that should keep your blood glucose steady and flat.

So…test that. Go without food and exercise for a bit and see how that turns out. Start easy…these are kids and they won’t want to go without food (I get it). Perhaps start with some distractions to breakfast time. See if you can get 2-3 (or even 4 ?!) hours or so without a meal in the morning. Bribery works wonders here. Favorite video games, money, whatever. 😉 Do you notice a drift? Do BGs start to climb/drop without a breakfast bolus involved? If so, you will need to adjust your basals.

Do this check for a few times of day separately (morning, afternoon, night), if possible. Sleeping basals are the easiest to check since there usually isn’t food involved. But, if you can get a good morning basal test in…that will do WONDERS to helping get you off to a good start on settings during your transition. Did I mention the wonders of bribery? Seriously, if I were to invest money…basal testing is a great place to spend some money on your kid. Huge payback.

And hopefully this is obvious, don’t do basal testing if you are on steroids, medication, ill, or otherwise have something that is temporarily affecting your underlying insulin needs. Bad insulin sites and/or illness will not yield useful basal testing.

Personally, Anna has a basal rate that tends to be higher while she is awake vs asleep. Therefore on weekends (not school days), we can shift the start time of her “I’m awake” basal rate in Loop to match her sleeping-in habits. Anticipating your question: If we forget, it isn’t a big deal…Loop accommodates pretty well. Instead of hanging out at her 95 mg/dl target from 7am-10am on a weekend, she might hang out at 85-90 mg/dl if we forget to tell Loop she’s sleeping in. So, I don’t fret too much about telling Loop those kind of details…it’s up to you how you’d want to deal with that kind of details.

Work on your Carb Ratio

A well done meal bolus should bring you back to target BGs within three hours after a meal and not require low treatments as a result of the meal bolus. Pretty simple concept…difficult in execution for many. There’s a couple insights that really help with “successful” meal time BGs:

  • Prebolusing
  • Accounting for fats and proteins in total carb counts
  • Accounting for fats and proteins in the duration you need to bolus for

The good news is as a Juiceboxer and/or Sugar Surfer, you’re already likely doing those things. You have a good feel for bolusing. That’s a great thing. Don’t let that go to waste. What you need to do though is convert that knowledge into a carb ratio and meal entry so Loop can access that knowledge too.

Start as soon as you’ve completed your basal testing. Then try your meals again. When you have a meal…calculate how much TOTAL INSULIN you use on your Bold or Surfing method for the meal, including extended boluses and temp basals. In the bagel example, total bolus was 1.25 units up-front and another 1.5 units over two hours…so a total of 2.75 units for the bagel.

Now estimate the carbs for the amount of bagel you ate. Let’s say you ate 45g of bagel. Take the total grams and divide it by the total units…that is your carb ratio. 45/2.75 = 16 (rounded off). Therefore for every 16g of carbohydrates eaten, you’ll need one unit of insulin.

As a Juiceboxer, you probably have many meals you already know your bolus strategy for. Write out a list of them, look up some carb counts and do a table of calculated carb ratios. Do as many of your meals as you can think of. They should all roughly average out to about the same carb ratio. This would be an excellent place to start your carb ratio setting in Loop.

If you have meals with heavy fats and proteins, don’t forget that those often need some “equivalent carbs” added to the total count of carbs for the meal. For example, a protein bar may say 35g of carbs on the label…but I know that they are very heavy in protein and therefore I need to cover the carbs in that bar more than just 35g. As a juiceboxer, you’ve already done this by having a larger bolus for that bar than the first time you tried it…now you just need to realize it’s actually a larger carb count because of protein. For us, that protein bar really contains the equivalent of 60g carbs because the protein breaks down into sugar in the blood stream too.

So again…it’s a shift from thinking of things in the end result (insulin) to thinking of things from the beginning (settings and carb entries). Take your known insulin boluses and work backwards to your settings. If you have heavy protein meals, add some to your carb counts (perhaps 30-50% of the protein grams will convert to carb grams for estimations).

Work on Insulin Sensitivity Factor

Now the above example is really super exciting and an example of how great Loop can be…but that success also depended on one more critical factor you’ve yet to set; Insulin Sensitivity Factor (ISF), also called a Correction Factor in some systems.

Basically, your ISF is the amount of drop in BGs you can expect from one unit of insulin. That’s a pretty important value to Loop if you think about it in those terms. An awful lot of Loop’s decisions (in fact EVERY SINGLE ONE OF THEM) will depend on that setting in its calculations.

This ISF is a pretty simple concept, but also the most difficult to “get right” because experimenting and testing can be really hard if any of your other settings are wrong.

Unfortunately, this setting is also the place most new Loopers start with their adjustments (because they assume previous success means their settings were right…so it must be the ISF that is wrong?)…and they do it while in closed loop. Hint: DO NOT BE THAT NEW LOOPER. You may lose your marbles.

Instead, start in the sequence listed above…nail down those basal rates by testing them first or else messing with ISF will be counter-productive and you’ll go nuts.

Once you get basal rates set, you can test your ISF by taking a glucose tab. Get above target and steady at that higher BG for a bit. Now take an amount of insulin that will safely get you back near range. Wait about 4 hours with super chill lifestyle. Don’t exercise, don’t eat, don’t fight with your siblings and for God’s sake don’t get on the trampoline. See how much you’ve dropped in BGs. Take the drop in BGs and divide it by the amount of insulin you gave. If you dropped 30 mg/dl with a dose of 0.50 units, then your insulin sensitivity would be 60. Meaning one unit of insulin would be expected to drop your BG by 60 mg/dl.

I cannot stress enough how important ISF is, and how misunderstood as well. Let’s do some ISF myth busting/confirming:

  • Dropping the value of your ISF (say going from 100 mg/dl to 80 mg/dl) will be a good solution to a new Looper who is consistently stuck high. WRONG. This indicates more of a problem with lacking adequate basal rates.
  • Spikes after meals can be dealt with best by changing your ISF. WRONG. Meal spikes should be dealt with by meal entries AFTER you’ve done the work to test your settings as described. Prebolus, adjust carb counts, and adjusting your meal duration (lollipop, taco, pizza icon) are the best way to deal with meals that don’t result in desired outcomes once you’ve adjusted/tested your settings.
  • Illness, medications, and hormones can all change your ISF. TRUE. If you notice that settings that previously worked in Loop after all that great testing…you may have a hormonal female teen. Or a sick kiddo. And yes…you’ll need to adjust some settings for that. (Make a mental note to read my upcoming blog post about the new Override features in Loop…that’s coming up and can help with those situations.)
  • Roller-coastering BGs in Loop can be because ISF is set wrong. TRUE. One of the most common issues is impatience in starting Loop…seeing higher numbers than you are used to (blaming them on Loop not being aggressive enough) and therefore lowering your ISF value thinking that will make Loop correct “better”. WRONG. Lowering your ISF value will make Loop lay on more insulin, but unfortunately, it also works in reverse. Every unit Loop suspends is also undercounted as a result of the artificially low ISF value…leading to a rebound BG. You’ll ride a nice wave of high temp basals followed by suspended basals…and your BGs will reflect that same oscillation.

  • So, if you have tested your basals, tested/calculated your carb ratio, and even tried to take a good swag/test at ISF…yet are roller-coastering? Try raising your ISF value just a bit. If you were at 60, try 65. Keep tweaking slowly and watch for your sweet spot. You’ll find it. Eventually you will find it.

Next Level: Adjust your Meal Entries

Now that your settings are nice and solid…we have a really good place to adjust from. (Really…make sure that you did the work in the steps above. Getting some decent understanding of your fundamental settings will help more complex meal boluses go much better.)

You’re probably wondering right about now “So, I’ve done all that work for settings…but I still don’t quite understand how I’ll bolus for my meals now.” All those awesome extended boluses and temp basal work that you’d been doing and had nailed? How do you recreate that experience in Loop? Meals that tend to stick around longer than just an initial bolus that you used to extend bolus for?

Now that basal rates, carb ratios, ISF are pretty well known, let’s make note of the meals that you normally might give less upfront and more of the total insulin later instead. Like pizza anyone? Chinese food. Quesadillas. Rice (omg, the rice) and sushi.

If you gave all that insulin upfront, you’d be going low early and high later…not the best outcome. Think of it like a game of tortoise and the hare (rabbit).

A quick carb meal like a fruit snack is a rabbit…it can out-run any insulin. It is super fast digestion and uses all its energy very quickly.

A slow carb meal like pizza and pasta is a tortoise. If you gave all the insulin up-front, you’d go low low within about an hour of eating and then be high high for hours later.

As a Juiceboxer and Surfer on a tortoise meal, you’ve gotten accustomed to some insulin upfront but using an extended bolus or temp basal to make sure insulin is still around to deal with those late BG climbs. Loop has a way of dealing with those meals too…it’s actually a pizza icon. Literally. You tell it the total grams of carbs for that meal (remember to add “equivalent carbs” to your total meal carb count if there are fats and proteins) and tap a pizza icon…that is equivalent to telling Loop that you are extending a bolus.

Let’s look at an example, Anna has a bowl of pasta for dinner.

If Anna and Loop had bolused based on carb ratios alone, her bolus would have been 6.25 units. Her carb ratio is 8, meal is 50 grams.  50g/8 = 6.25 units.

But, Loop only recommended 4.85 units up-front. Why? Because I told it this was the kind of meal that was a tortoise. It was going to be sneaking slow at first and stick around for a long time. Loop gave an appropriate amount up-front and then waited like a stealth ninja to deliver the rest when the danger of low BGs had passed.

How did that meal go then? Let’s show that in pictures

And how did that meal do hours later while I slept? Pretty freaking fabulous. As that slow tortoise tried to get to the finish line, Loop kept pushing back. Hours later, Loop had won the war and the tortoise had run out of steam (pasta had finished digesting).

Similarities with Juicebox and Sugar Surfing

All of this reading and do you see it now? Where Loop and the other methods are similar with regards to “nailing” a meal?

They all still involve a bit of learning when encountering a new food. And that is a-ok. Getting friendly with a new meal? Here’s the differences in behavior between the two:

  • With Loop: You adjust how you enter carbs to fine tune Loop’s insulin deliveries.
  • With Juicebox or Sugar Surfing: You adjust insulin in reaction to observed BGs. Carb entries are relatively unimportant.

So…in practice these are actually kind of similar, just different where you are adjusting. If you have a meal, you can learn from it in both systems. If you have a meal in Loop and end up stuck on a high later…add some carbs to the meal entry next time (or even edit the carbs mid-meal to help Loop know that perhaps you didn’t quite guesstimate carbs right) and use a longer food icon (move from taco to pizza). How many carbs to add? If your settings homework was done, the Insulin Counteraction Effects screen in Loop can help you TREMENDOUSLY to dial in those meal entries. Loop will help you see just where your carbs impacted you and help you for the next time to estimate total carbs to enter and how long.

If you really want to fine tune, you can do mixed meal carb entries…give a portion of the total carbs to the tortoise and a portion of the total carbs to the rabbit. My teen doesn’t usually go through that much effort, but that’s ok for us. Could we get slightly better results if we were super diligent about telling Loop the exact mix of a meal? Yes…but we’ve decided the effort’s not worth it overall after 2.5 years of Looping…but I’m glad the option is easy to access for those who would want to.

Read the Docs

Don’t forget to read Looptips.org. There are loads of helpful tips about how to deal with situations in Looping. How to do these settings tests. And for Juiceboxers and Surfers especially, work on converting those old bolus techniques into settings and carb techniques. Identify the results-oriented tools you’ve been using (insulin dosing) and back those into settings understandings.

And then recognize that you’ve been doing the work of a closed-loop system for awhile now. Kudos to you. If you can take the time to dial in the settings as described above, you will have successfully developed the tools to let Loop know the needed info so that Loop can take that closed-loop job for you. It can babysit the reactions to BGs now.


Loop for you?

Loop is on the cusp of releasing support for Omnipod users.

This is a monumental change to the tools available to the type 1 diabetes community. BUT, it has also created a vortex of emotions and shoe-box-speeches that I struggle with in a more broad sense. How can I make sure that a HUGE influx of new users come to this system well-prepared and educated? I can’t hold each person’s hand through this process one-by-one. So I need your help. If you are considering Loop, or have a friend considering Loop…read and share this post.

Many people have excluded themselves from DIY looping because they assume Loop requires some difficult technical knowledge about computers or software. (Spoiler alert: It doesn’t.) In November 2016, I made it my personal mission to make Loop-use inclusive of everyone, tech geeks to busy parents to grandparents to college students, when I started working on instructions and documentation of the Loop app. My goal was that anyone who was willing to read some simple instructions, aided by pictures, could build and use Loop successfully.

My work seems to have been successful as there are now many, many people using Loop who likely would have never tried otherwise. I’m delighted when I hear feedback that tells me the documents I’ve written were easy to follow and helped.

What slays me is when it is obvious that people ONLY read the parts that deal with building Loop.  They never read the parts about USING Loop.

Instead, they built the app…walked away from all the awesome other information online about USING Loop…and assumed they’d just be fine.

It bears repeating the obvious: This app is automating insulin delivery to you (or your kid). That simple fact alone should make you want to read all about how to use it.

So as all these people are out there excited for when the Omnipod Loop code will be released…this is a great time to remind you about the importance of learning all about Loop beyond the build. Loop doesn’t behave like your old pumping life did. A few examples:

  • Did you know that you can’t set your own temp basal on Loop?
  • Did you know that you can’t set your own extended bolus on Loop?
  • Did you know that if your settings (scheduled basal, carb ratio, etc) need adjusting (illness, hormones, etc), Loop won’t do that for you?
  • Do you know what a reasonable maximum basal rate might be?
  • Do you know what might cause a roller coaster of BGs on Loop?
  • Do you know how you are going to share data with your Endo if you aren’t using your PDM anymore?

If you read those statements and thought “WHAT? Then how does it work? What am I supposed to do now?” then head on over to LoopDocs.org and LoopTips.org. Those two websites have a ridiculous amount of helpful information for you to get familiar with the new Loop life you’d be living.

And after your Loop is up and running…remember those resources will be there still for you when you have new situations and questions. No shame in going back to the docs when in doubt.


Tidepool and Loop

If you weren’t aware, I am now working with Tidepool to release Loop as a supported, FDA-regulated mobile app available in the App Store. So, now there’s a DIY Loop to talk about and a Tidepool Loop.  There’s a lot of work to be done to accomplish this project, and a LOT of people pulling for us to do well. If you are interested in staying up on the progress, you can fill out this form to get updates.

With that introduction made, now I am going to talk a little bit MY personal involvement with Tidepool from even before Loop days.

As a person with diabetes, you’re probably carrying around a lot of different devices that are holding a lot of different data; a blood glucose meter for your finger sticks, pump for insulin delivery, continuous glucose monitor for real-time glucose measurements, phone app for tracking meals, etc. When you go to your endocrinology office, you probably start the process by dropping many of those devices at the front desk to be individually downloaded and then having to pack all them away 20 minutes later.

Then your clinic staff have the less-than-efficient process of trying to overlay all those different devices into some sort of cohesive strategy for how your diabetes may need some tweaks. Our clinic currently has to look at separate reports from Medtronic pump, Contour Next Link BG meter, Dexcom CGM/Clarity, and our iPhone Health app. Oh, how I don’t envy them.

Enter Tidepool. Tidepool said “Hey, this is your data and all that data is more useful when viewed together.” So, Tidepool is like your diabetes data hub. Upload all those devices into ONE place so that the meal that you ate, the blood glucose response, pump actions, and the finger checks all overlay into a nice single timeline. Makes figuring out how to adjust your diabetes settings a whole lot easier when you can see this all at once.

Actually, let me borrow my own employer’s words:

Our mission is to make diabetes data more accessible, actionable and meaningful for people with diabetes, their care teams and researchers.

We believe that connected data leads to better decision-making. Tidepool’s free software liberates data from diabetes devices, and places it in context of the real world. Tidepool is designed to help you discover insights and bring context to your diabetes management. And, to help make your data more actionable, we allow you to share your data with anyone you choose: caregivers, clinicians, endocrinologists, friends, researchers – anyone.

We started using Tidepool when Anna was on the Omnipod pump and Dexcom. We would plug in her Omnipod PDM and Dexcom receiver into our desktop computer, use the Tidepool Uploader program and <voila!> Anna’s data be in one lovely place for us to see. Were there drawbacks? Yup, had to remember to actually do it myself. Which eventually ended up being about every week before an endo appt.

While I didn’t have the forethought to capture screenshots of our Tidepool data at the time, it looked much like this for comparison…

And then we started Looping, and life was grand as far as our diabetes lifestyle.

However with Looping, we had to stop using Tidepool. There just wasn’t a way to upload from our old Medtronic pump. Tidepool only had (at the time) uploader support for the following Loop-compatible pumps: Paradigm 523 /723 and Veo 554/ 754. We started Loop using a 722.  We were out of luck. As were all of the people using 522, 722, 515, and 715 pumps.

We ran into a couple issues with Looping when it came to viewing our data using other means, too.

  • Medtronic’s pump gets so clogged up by the numerous temp basal records being recorded that the endo clinic can only pull about 7 days of data from the pump.
  • Endo clinic basically lacked an overlay of basal/bolus actions with BGs from our Dexcom, which really limited their ability to recommend any settings changes.
  • Nightscout reports could fill some of the gap as far as overall management, but the problem was with the actual gathering of the reports. It’s a little hard for the endo clinic to bring up your NS reports live time, and I am terrible about remembering to print them out ahead of time. Plus, the data presentation was just not quite the same as the Tidepool look I had grown accustomed to.

    • I don’t bother to make manual notes in my Nightscout’s careportal about things we are doing…so if the endo asks me “What happened here?” chances are good that I won’t remember a darned thing about it and there will be no note. Trying to find an old meal to help with the next time we bolused/ate it? Forget about it.
    • With all my experimenting with Dexcom gear *cough, cough* I sometimes cluttered up my daughter’s clarity account with my BG data unintentionally. Dexcom’s servers did not always like my constant switching of accounts and transmitters, so sometimes our Clarity reports would print out as a black ink jet blob basically. Oops.

Well, I’m here with wonderful news!

Tidepool is bringing in Loop data!  

How does it work?

The Tidepool Mobile iOS app is getting an update (soon to be in beta release) to sync a Looper’s diabetes-related Health data into their Tidepool account. The app will continuously upload that data so long as the Tidepool Mobile app is open, even if it is only open in the background. That data will then be viewable in two places: on the Tidepool Mobile app itself or on your Tidepool account using desktop Chrome browser (although they are not identical viewing platforms, see discussion below). This means a Loop user will not have to plug any of their devices into a USB cable in order to upload their information to Tidepool.

Is this a replacement for Nightscout?

Nope. This was not designed nor intended to be a replacement for your Nightscout site. I think they complement each other, rather than compete. This new upload of Loop data will allow me and my clinic to have a powerful tool to analyze Anna’s Loop data through an easy-to-use, shared hub.

What data will you see in desktop Chrome view?

You will see your temp basals, Dexcom CGM readings, boluses, notes, and various metrics about your data distribution. If you separately load your BG meter or any other supported device to Tidepool, those will also overlay. See discussion below about what’s missing (hint…carbs aren’t showing yet).

How can I share this data?

Sharing the data is simple. You can click on your account’s Share option and enter in the email addresses for those that you want to share with. Those people will need a Tidepool account. If they don’t have one currently, they will follow easy prompts for an account setup after they’ve received your share invitation. Clinics using Tidepool will have a Tidepool account email that you can add to your account, enabling the clinic to easily view your data. You can also remove access for anyone with a simple click.

Are there any known issues?

Sure, of course…you may have missed the word BETA in all the excitement. There are some bugs currently being worked out. For example, the carbs associated with the Loop uploads are being uploaded by Tidepool Mobile, but they aren’t currently rendered in your desktop view or the Tidepool Mobile view. If you look at the Daily view screenshot a little above…notice that the little yellow carb circles are missing? We will be getting that bug addressed. Soon, hopefully, your chart will include little carb circles like below (rendered with my crude skills for demonstration only).

There are some calculated data areas that need updating, too. If you see a NaN (“not a number”), it is a placeholder for where a number will eventually go. We know and we don’t like seeing those either. We are keeping a list of the things that need addressing.

What will I see in the Tidepool Mobile app?

The Tidepool Mobile app is not a live-viewing app of looping data. For people coming from Nightscout, this may be a bit confusing but realize the intended purpose of the Tidepool Mobile app isn’t live-viewing. It is the place that you can (1) upload/sync Health data, (2) easily add/edit/delete notes to the data set, and (3) search for notes and view Loop data surrounding that note.

In fact, you will basically see NO data in the Tidepool Mobile app unless you have Tidepool data uploaded and notes are added. Once you add a note, you are basically placing a bookmark on the data set. You will be able to click on the note and see 7 hours of old data before the note, and then the note will continue to collect 7 hours of data to display after the note. So, technically, you’ll be able to refresh the app’s view to see current data for approximately 7 hours after a note is placed.

For example, here’s Anna’s data tonight as I was typing this blog post. Over the last couple hours, Anna noticed that she was staying above target (unusual for us on Loop and with the meal she had) for quite a while. She had given a couple small corrections without result. Which then she started her secondary troubleshooting…if it’s not the food, maybe it’s my site? Ah yes, she realized it has been 4.5 days since changing her site. So, she just logged a note using the app. That note showed on my phone, shows up on her Tidepool data for her endo to see too, and we can refresh the view to see how the BGs go for the next 8 hours after the site change if we want.


What cool thing does Katie use this Tidepool Mobile app for?

I think the best thing about this Tidepool Mobile app (other than importing all Anna’s valuable Loop data automatically) is that I can keep a really easy searchable log of meal boluses. If you are still learning new meals in Loop…how much to bolus, how long of a carb absorption…these notes are searchable and super easy to add. Learning how to bolus for that Tofu Breakfast Burrito? (Don’t ask, that’s really a thing Anna is eating now.) Simply record a note of how you bolused for it. If you want to, come back afterwards and leave yourself some suggestions for the next time to try. This searchable information can also help for those teens that are learning and exercising independent skills. If they aren’t sure of how to bolus for a meal, this could give them an easy way to get tips from past success without necessarily having to stop and ask a parent. As much as a parent might scoff at the idea of a kid looking up a meal, if the alternative is asking a parent…that might be all the motivation it takes. Anna learned this little trick pretty quickly. Or how about co-parenting? Want to leave a note that another parent or caregiver can look up? How were the last Chicken McNuggets bolused for or when was the last site change can easily be tracked and retrieved with notes.

Search for the word burrito (doesn’t have to be a hashtag) and any notes with the word “burrito” will be available for review, as well as any added comments.


Another useful thing to track…hormones. What day-of-the-month and how did I change the basals? Looking to find patterns in those female hormones? This could be a really slick tracking tool to easily log periods of insulin resistance and what part of the cycle they are occurring at.

Is this app only for Loop users?

The updated Tidepool Mobile app will upload diabetes-related Health app data regardless of the source. Loop users store their data in Health app, so this is a nice fit. Other diabetes devices (e.g., OneDrop BG meter) and apps (e.g., Spike and Dexcom) also store their data in Health app. Some people even manually enter their diabetes data into Health app. For all those uses, the Tidepool Mobile app will upload the Health data. OpenAPS does not store its data in Health app, so this will not upload OpenAPS-related data.

How can I get this?

Frankly, probably a lot of Loop users may not be familiar with Tidepool at all…so this post was part introduction and part announcement. Tidepool’s goal is to get a limited number of beta testers to help us identify bugs or problems.  We’d like to cover a variety of  Health-app users such as Loop, Dexcom, InPen, OneDrop, SpikeApp, SugarSense, OneTouch Reveal, and Accu-Check Connect. We’d like people who are willing to report bugs and won’t curse my name if you find one.

In summary, if you are interested in being a Tidepool Mobile iOS Beta participant, click here to fill out the recruitment form.  Thanks!

WWLD: What would Loop Do?

Probably one of the hardest things about closed looping is when you find yourself not understanding the direction that your loop is taking.  “WHY is Loop not giving more insulin right now?” or “Why is Loop doing nothing?”

To answer these questions, you have to Think Like A Loop.  In other words, we need to know about Loop’s algorithm and understand what its decision points are.  Tonight in Looped group, I posted this figure of a simulated BG curve and asked:

It’s 8pm and your predicted BG curve looks like the following. What do you expect Loop to recommend/enact at 8pm?

A. Zero (suspend) temp basal
B. Scheduled basal from your settings
C. High temp basal
D. Lower temp basal (between zero and scheduled)

Let me just say…LOVED the engagement and thought people put into it.  The responses also help me focus on the next project I’m working on…super excited to release it in a week or two.  But, back to question at hand.

What would your answer be?  Before you give your final answer…consider this next twist.  Would you give the same answer to this graph as you gave the graph above?  If not, what would the answer be for this graph and why? (ignore the timestamp mismatch)

This second case has a dramatic drop happening.  Suspend threshold is still at 60 mg/dL, correction range is still 90-110, the lowest value on the predicted BG chart is 75 mg/dL, and the eventual BG is 171 mg/dL for this example.  So, pretty similar to the first example except this precipitous drop going on right now.

Let me tell you some of the common pitfalls we all can easily slip into when trying to answer these “Why is Loop giving me this basal?” questions.

  • Wondering about IOB, COB, or DIA in order to answer…those aren’t a factor to answering the question as they have already been used to make the predicted BG curve.  In other words, they are accounted for already in the information presented.  All you need to answer this question is provided by the predicted BG curve, your suspend threshold, and your correction range.
  • Thinking about this as a human…humans tend to say “well, I’m on a rise/fall right now so…[insert Loop action based on that]”  Loop isn’t looking at the past BG movement, instead it’s looking at the prediction curve ahead and applying its rules based on that.  Any drop or rise going on will have been added to the predicted curve through the BG momentum and retrospective correction components of the algorithm…so again they’re already incorporated into the predicted curve.

Restating for emphasis:  All you need to answer this question is provided by the predicted BG curve, your suspend threshold, and your correction range.

The answer is B:  Loop will give your scheduled basal in both situations shown above.  When your predicted BG curve (A) drops for a time below correction range but (B) all of the curve still above suspend threshold, and Eventual BG is (C) above range or (D) within range…Loop will give your scheduled basal.

The logic is a bit of a wait and see.  Scheduled basal will maintain the delivery of insulin.  Your settings haven’t told it this is an “oh my gosh…stop the insulin!” moment (you’re predicted to still stay above suspend threshold), but we also don’t want to give high temps yet (to correct the eventual BG) because we’d like to safely make it through the part that is below correction range coming up.

  • If BGs were to drop (enough) or keep dropping (enough), your predicted BG curve would likely slip to your suspend threshold and then Loop would suspend. (One important take away is to not to set your suspend threshold so low that it no longer acts as a safety in these situations.)
  • If BGs were to rise enough such that the whole predicted curve comes back into or above the correction range completely, you’d then get high temp basals to correct for that eventual BG that is above correction range.

Want to practice a little more?  Here’s a sequence of actual screenshots from a running Loop.  Think for each of these…

A. Zero (suspend) temp basal
B. Scheduled basal from your settings
C. High temp basal
D. Lower temp basal (between zero and scheduled)

Time A

Time B

Time C

Ok, got your answers?  You can see what Loop has done by looking at the middle basal rate change in the head’s up display.

Time A

Loop has provided no adjustments to the scheduled basal rate.  The predicted BG curve has a temporary excursion below correction range, doesn’t dip as low as the suspend threshold and eventual BG is above correction range.

Time B

A few more BG readings have come in and affected the predicted BG curve.  Now the predicted curve is entirely within or above the correction range…and since the eventual BG is above correction range…let the high temps begin.  Loop is safe to correct for that eventual BG. (see Loop has increased temp basal by 1.5 u/hour)

Time C

And a few more BGs later, that BG has dropped some and the predicted BG curve has now gone below the correction range again.  Hasn’t dipped low enough yet to hit the suspend threshold at the lowest predicted point…so Loop is going to continue to just provide scheduled basals.

Hopefully that little walk through helps illustrate what you can be looking at to understand why your Loop is recommending/enacting basals at a particular time.  It’s all about the predicted BG curve, your suspend threshold, and your correction range.