Hybrid Closed Loops

First a couple terms as we embark on this discussion:

Hybrid closed loop (HCL): An automated system that modulates a pump’s insulin delivery, based on a connected CGM, to try to keep user at a specified target BG. The “hybrid” part of the description means that the user is still responsible for bolusing food themselves in the traditional sense (carb counting and a carb ratio). The term “artificial pancreas” is often used interchangeably with HCL. For the purposes of this post, I’m going to shorten the term to simply “closed loop”.

Automatic bolus: The first closed loops only modulated insulin delivery by settings temporary decreases/increases in basal insulin deliveries. Some closed loops are also capable of delivering boluses in some situations to help bring high blood sugar back to target a bit quicker than basal modulations usually achieve alone. The term “automatic bolus” does not refer to the bolus involved with meals.

At a recent diabetes conference, there was a lot of buzz around the options for closed loop systems. At this conference, I had the privilege of speaking about my perspective of the JDRF Open Protocol Initiative. If you haven’t heard about it, you can read more about it here. In a nutshell, there’s a shift in the industry leading to potentially more choice for us (the people living with diabetes) in the near future. The shift means that you’d be able to pick your favorite CGM, favorite pump, and favorite looping algorithm/controller to combine together into your own little “customized” closed loop. So, instead of all the pieces being pre-picked for you…you get choice about the individual pieces and they don’t all have to be from the same company. The term describing this mix-and-match idea is “interoperable” components. The Open Protocol Initiative seeks to clear the regulatory, legal, and funding pathways needed get interoperable devices on the market and FDA approved.

Interoperable’s Current Status

There’s three components that make up the necessary part of a closed loop; CGM, insulin pump, and the controller/algorithm. In order for a potential interoperable device to be sold in the US, it will need FDA approval specific to that category…and the nicknames used for these categories early on were iCGM, iPump, and iController. To borrow Tandem’s wording, “This new category of devices will make it easier for separate companies to integrate their products into advanced automated insulin delivery systems without having to resubmit each of the components and their associated clinical data every time. It’s a great move on the behalf of the FDA to make it easier for companies with leading-edge technologies to more quickly develop and deliver innovations for the diabetes community.”

So what’s the status on any devices getting approvals for these new categories?

iCGM: The only iCGM thus far is the Dexcom G6 system. The FreeStyle Libre 2 has been submitted for FDA review for this iCGM designation…and it’s taking a little longer than initially expected.

iPump (ACE pump): Ultimately when the first device was approved, the official name of the iPump category was made “ACE pump” standing for “alternate controller enabled”…rather than iPump. The first ACE pump  was Tandem’s t:slim X2 pump. Insulet’s DASH pod were the next to get ACE approval. (FAQ answer: the Medtronic 670G pump is a pump that does closed loop…but it is NOT an interoperable pump. The pump was approved as part of a defined system, meaning it must be used with the Guardian 3 sensor and the algorithm inside the 670G pump itself in order to access closed loop operations…so the 670G pump is NOT an ACE pump)

iController (iAGC): Ultimately when the first device was approved in this category, the name became “iAGC” standing for “interoperable autmated glycemic controller). The recent approval of Tandem’s Control-IQ as an iController marked the first (and so far only) for the category. Tidepool announced its intention to take a version of Loop app through that same approval process and is hopefully close to submitting to FDA soon.

Development Partnerships

Partnerships have been, and continued to be, announced all the time as part of this industry movement…a signal of which devices may be available in the future. It is nice to see that there are more partnerships that appear to be giving more choices for the pairing of system components.


With all this awesome discussion about choice…some people could be in a little bit of a pickle right now in terms of finding the proper information so that they can choose the best system for their needs/wants. So, let’s take a quick peek at the currently available commercial systems, DIY systems, and upcoming systems in trials now. But, I’m adding some color commentary on the systems based on the feedback I’ve heard from other users, too.


There are two commercial options right now; Medtronic 670G and Tandem’s Control-IQ.

Medtronic 670G

Medtronic 670G overview: This was the first commercially available option, approved in September 2016 by the FDA. The 670G uses the 670G pump and Medtronic’s Guardian 3 CGM. When using the closed loop feature for the 670G, it is called being in “auto mode”. The standard target setting is 120 mg/dL and the target can be set temporarily to 150 mg/dL for exercise and other events. The system has you use it in “manual mode” for at least 2-3 days before you go into auto mode. Although you have a scheduled basal profile that you enter into the pump and will be used in manual mode, things change with auto mode. In auto mode, the 670G uses a basal schedule that it decides is appropriate from the previous 6 day’s experiences, not the one you’ve programmed into your personal profile. You will not be able to have a corrective bolus recommended for a high blood sugar until you are above 150 mg/dL and then the corrective bolus recommendation will only provide a recommendation to reach 150 mg/dL. These recommended corrections are not applied automatically, the user will need to implement them manually.

670G Clinical data: To read up on the pivotal trials data that lead to the approval of the system, diaTribe has an excellent summary article here.

I also found this data from this study of the real-world users of 670G after launch to be particularly interesting. The interesting parts?  Teens have the most trouble, staying in auto mode about 66% of the time and achieving a 62% time in range (70-180 mg/dL).

670G user experiences: There’s a whole world of experience that needs to be considered beyond what a clinical trial would tell a user. Beyond time in range and A1C is an evaluation of how easily you can LIVE with the requirements of using the gear. Here’s some of the most frequent user experiences I’ve seen…

  • You cannot change the 120 mg/dL target. No going lower.
  • You cannot use a different CGM (such as Dexcom) and still use “auto mode”.
  • Users have often reported setting very aggressive settings changes in order to achieve better time-in-range. The only two that you can change in auto mode are the duration of insulin action (DIA) and carb ratio. You do not have the ability to simply adjust basals to make the system more aggressive, because the “auto mode” operations are automatically setting your basal profile based on the previous 6 days of data.
  • You must calibrate the Guardian sensor twice daily, sometimes more often. The sensor will provide additional prompts for calibrations when it is unsure of the accuracy of its readings. This leads to what’s called a “pretty needy sensor” experience. It is often cited as one of the major reasons that the 670G auto mode has drop-out rates from 33-49% of its users in studies…they just don’t like all the work required to stay in auto mode and intentionally choose to stay in manual mode. For those users that try to stay in auto mode, there is still a low percentage of time in actual auto mode consistent with the clinical trial results.
  • There are no “automatic bolus-type” corrections…all corrections are accomplished through basal modulations.
  • If you stay at “too low” or “too high” of a basal rate for too long, you’ll be kicked out of auto mode. Practically speaking this means the times when you’d most want to be in auto mode critically (stuck on lows or stuck on highs), you’ll be kicked back to basals in you entered in your profile settings within 2.5-4 hours (see below) of these limits. *Note, Medtronic does not tell you the value of your “personal minimum delivery rate” and “personal maximum delivery rate”. It’s a black box mystery.
  • You will be forcibly kicked out of auto mode, and placed in a “safe basal” mode for 90 minutes (no automated basal adjustments will happen in safe basal mode) if any of the following issues below occur. If the issue is not resolved during that 90 minute span, the user is dropped back into manual mode and will not be getting automated basal adjustments:
    • CGM is outside of the 40-400 mg/dL range
    • CGM has not been calibrated within 12 hours
    • Auto Mode has been at your personal minimum delivery limit for 2.5 hours
    • Auto Mode has been at your personal maximum delivery limit for 4 hours
    • Auto Mode detects that your sensor might be underreading
    • An entered BG is 35% or more different than your current CGM value
    • No CGM data has been received for more than 5 minutes
Tandem Control-IQ

Tandem Control-IQ overview: The Tandem t:slim x2 pump combined with a Dexcom G6 sensor can be used with Control-IQ algorithm to provide a closed loop. This system has been on the market since early 2020. Previously, many users were using the low-suspend-only version called Basal-IQ. The standard target setting is 112.5-160 mg/dL, but there are two alternate target settings users can implement. Sleep targets are 112.5-120 mg/dL and exercise targets are 140-160 mg/dL. With the standard targets enabled, the behavior of Control-IQ can be summarized as shown based on the predicted CGM in the next 30 minutes:

The system uses an initial weight and total daily insulin entry, when entering closed loop mode on Control-IQ, to help establish its model and maximum settings. You don’t get dropped out of closed loop automatically by any condition except CGM data not being refreshed within 20 minutes.  If that happens, you’ll be reverted back to your saved profile settings and no automated insulin delivery changes will happen. As soon as CGM data becomes available again, the system will automatically resume Control-IQ operations and you’ll be back to closed loop operations. There are automatic boluses available, if you are using standard targets. You will get 60% of the needed correction to 110 mg/dL as an automated bolus, when BGs are predicted to go above 180 mg/dL in the next 30 minutes. You can get one automated bolus no more frequently than once per 60 minutes since a previous bolus event (either automatic or manual bolus).

Tandem Control-IQ clinical data: To read up on the pivotal trials data that lead to the approval of Control-IQ, diaTribe has an excellent summary article here. One notable take-away when I initially read this article was that all users stayed in the trial and stayed in closed loop mode 92% of the time. This was a significant improvement from the first-to-market 670G’s results. Additionally, Control-IQ achieved an improved time in range from 59% baseline to 70% after using Control-IQ (670G had clinical trial from 67% baseline to 72% after using auto mode, for comparison). So, while the  data looks like it achieved similar time in range ultimately, I’m actually more impressed at the difference in improvement…Control-IQ brought people up from a far more challenging starting point than 670G did.

There aren’t any real-world clinical studies yet of Control-IQ users, but the Basal-IQ system ended up out-performing the pivotal trials data. I’m excited to see how Control-IQ performs.

Tandem Control-IQ user experiences: To be fair, Control-IQ has not been on the market for nearly as long as the 670G has been…so user experiences are still being gathered. Thus far, the results have been very positive. Complaints that I’ve heard include the usual (can’t aim for lower than 112.5-160 mg/dL) and mundane (pump clip sucks). There have been reports of some users keeping sleep targets turned on 24/7 to achieve a lower overall target range throughout the daytime. Users have been requesting to see more data about their Control-IQ status and to have it link to a mobile phone app (and that is in the works, but I don’t know of a launch estimate on that). There are a couple real-world reviews from users here and here.

An interesting “interoperability” note…this platform could conceivably be the first on-market actual interoperable choices since the announcement of a development partnership between Abbott and Tandem in October 2019. If Abbott’s Libre 2 gets approved for iCGM status (currently under review by FDA), then Tandem customers, using the t:slim x2 ACE pump and the Control-IQ iAGC, could have the G6 or Libre 2 as their iCGM choices. There’s still work to be done for sure to make that happen for Tandem, but it’s an exciting pathway to see finally achieved.

My daughter has been using Control-IQ for about 2 weeks now (after nearly 3+ years using Loop and half a year of OpenAPS). The results so far have been very encouraging. I’m going to do a separate blog post about that when we hit the 30-days of use so that I can have more comprehensive data to share. I never trust that diabetes isn’t just playing nice every time she tries a new system, so I am waiting for more data to really believe it. Thus far, it is out-performing our Loop experience though.


There are many DIY closed loop systems, but the most notable three are Loop, OpenAPS, and AndroidAPS (each of those are links to read more about the individual systems). Most of you know me from Loop, but we also used OpenAPS for quite sometime as well. We have never used AndroidAPS because (1) we don’t use android phones and (2) we don’t have access to the pumps that are compatible with AndroidAPS (those are more commonly available in Europe).

DIY systems are not FDA approved, nor do they come “pre-assembled”. You will have to do some work yourself to build the system and understand how to operate it. There’s a great comparison between each of the systems here. But the short summary is that picking which system is right for you will depend on what aspects you value the most. For example if you absolutely won’t use an Android device, then you need Loop or OpenAPS. Pump choice will also make a large difference. For example if you won’t move away from using your Omnipods, then you need to consider Loop (although AndroidAPS is getting close to a stable inclusion for Omnipod). AndroidAPS is the only system that has the ability to remove the use of an in-between device (such as a RileyLink or Edison rig) because it supports some versions of pumps that have built-in bluetooth capability. AndroidAPS also has the ability to send remote boluses through text messages (although that concerns me a bit from a safety aspect, but that’s a larger topic for another discussion).

All of these systems allow for a level of transparency that is currently unavailable in commercial systems. You can see every aspect of the algorithm’s decision making by examining the code itself and the documentation online. As well, they all integrate with Nightscout and upload live-time with CGM, carbs, insulin, temp basals, and predicted BG values. This live-time view gives remote care givers incredible insight into every aspect of the looper’s status.

There’s also some drawbacks of using a DIY system. You won’t be able to just pick up the phone and call customer support if you have a question (although…holler to the Facebook Looped group for always having pretty quick answers). You may find resistance from your health care provider or school system for using a not FDA approved system. You will likely need to rebuild your system periodically as the code or OS systems of devices get updated.


Tidepool Loop: Tidepool is working on developing a version of the DIY Loop system as an iAGC (that will not require a RileyLink). So far, Tidepool has shared that it is partnering with Omnipod and Medtronic for the ACE pump and Dexcom G6 for the iCGM. They have already stated that the initial platform will be on an Apple device (Android devices will follow later). The observational study has been going for 12 months now and is due to collect data through March 31st. Jaeb Center released initial results at the ATTD conference on February 20, 2020. You can download that presentation here or see it in the browser here. The results are encouraging, with time in range increasing from baseline 67% to 73%. However, as noted in the study, the starting user was demographically from an already “above-average” population. The teen population rose from a baseline 63% to 68% time in range. The time in closed loop mode was 79% on average. Generally speaking, Loop does not go out of closed loop mode unless CGM data is missing, RileyLink communications are failing, or the user has chosen to manually end closed loop operations for awhile. It is unclear from the data so far why the time in closed loop mode is relatively low given the simple requirements for staying in closed loop. No word on the timing of when Tidepool Loop will be available, they are working on getting a submittal ready to send to FDA as of the date this was posted. We also don’t know the specifics on what will be different from DIY Loop ultimately, but Tidepool has stated they are trying to stay fairly similar to the app that DIY users have been familiar with so far.

Note: Tidepool has stated often that it wants to partner with more interoperable devices to provide more choice. So far, Tidepool Loop has partnered with Medtronic and Insulet ACE pumps…but if other companies develop ACE pumps, they could conceivably partner with Tidepool Loop, too. Same for iCGMs, currently just Dexcom G6 but they want more partners to promote more choice for users.

Insulet’s Horizon: Insulet filled its enrollment need for pivotal trials recently and that trial is on-going. They previously conducted a 48-72 hour study with 14 participants and a 36-hour in-clinic study with 58 participants.  What do we know about it right now? Well, the algorithm is contained within the pod itself. So if you walk away from the Android device that controls the pod (aka the PDM), the system will still be able to modify your basals while you are away from the PDM. That’s a pretty useful feature. What we don’t know is any details about the algorithm’s strengths or weaknesses in every day use.  As the 670G and control-IQ experiences have demonstrated, the final user experience will be more than just simply what the time in range or A1C is possible.

Note: Insulet’s Horizon appears to be headed to a partial interoperable product since it has announced partnerships for the Horizon system with Abbott and Dexcom CGMs. Users would need the Horizon system to round out the ACE and iAGC approval portions to be able to switch between CGMs on Horizon.

Beta Bionics: The iLet closed loop system being developed by Beta Bionics has a major difference already…they are aiming for dual-hormone closed loop. So in addition to the usual insulin cartridge in a pump, the iLet will have a pump-friendly version of glucagon to help prevent lows. Beta Bionics is about to begin enrollment for a pivotal trial of their Gen 4 iLet in its insulin-only configuration.  Once they complete a pivotal trial, they should be able continue with the next pivotal trials for dual-hormone looping. Beta Bionics has been around for quite sometime now, and this article has a good history and information:

“The iLet is different from the current commercially available pumps in a few ways: it does not require any settings (carb ratios, basal rates, and correction factors), nor does it require carb count entries for meal boluses (though you do still have to announce meals).

This is an adaptive system that is constantly fine tuning and adjusting its insulin delivery settings, and uses the user’s weight as the starting point to dose insulin. This means that users may expect the pump to go through learning curve at pump initialization with more volatile blood sugars, as it may take a few days for the pump to learn about your specific diabetes patterns and management needs.”

Bigfoot: Bigfoot was originally on-scene when they purchased Asante pumps around 2015. We do know that the Bigfoot smartloop would utilize an app to control the pump and run the algorithm. Bigfoot also has states they intend to use prefilled cartridges and a streamlined ordering process. Bigfoot announced the first enrollments in a clinical trial back in 2016, but to date has not begun pivotal trials to support an FDA submission. Awhile back, Bigfoot raised capital and stated they had hoped to have pivotal trials in 2018, but that schedule apparently slipped as Bigfoot changed CGM partners from an expected Dexcom to Abbott. Unfortunately, there’s not much else that I know about Bigfoot’s plans as it appears their progress is currently quickest on smart-pens.

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.

Pre-soak, hotswap, and 65 minute “warm up” for G6

Since we use Loop (ok…and because we just like having as much continous BG coverage as we can possibly get with the supplies we have)…we had gotten into the habit of “pre-soak and hotswap” with the G5 system.  If you haven’t heard of those terms before, let me explain them quickly.

Pre-soak:  Inserting a sensor hours in advance of before you intend on putting it into service.  Why pre-soak?  When you insert a sensor, there are micro-traumas under the skin that take some immune response.  Chemical changes and tiny micro-responses to the “insertion trauma”.   Plus there’s a coating on sensor wires that needs to come into equilibrium with the surrounding tissues where you have inserted.  That time to equilibriate with the new tissue surrounding is why there is a 2 hour warm-up.  It’s a balancing time for the system to settle down from the trauma of insertion.  You’ve probably already seen this yourselves if you’ve noticed that even the first 6-10 hours after warm-up can still be jumpy.  So, pre-soaking a sensor is a way to let the new sensor settle into its surroundings before putting it into use.  This helps the sensor start off right away with less jumpiness and more closely holding calibrations quickly.

In order to pre-soak, you need to NOT wait for your existing sensor to fail.  In other words, when you start to suspect that your sensor is going to fail soon, or you notice that it isn’t holding calibrations well, then you would want to go ahead and insert a new sensor ahead of time.  YES, this means that the person is wearing two sensors at once…(1) the existing one that is soon to fail and still has transmitter in it and (2) a new one, just inserted, that doesn’t have a transmitter in it yet.  For safety, you want to go ahead and put a band-aid, wrap, or dead transmitter to hold down the little flap in the middle of the new sensor that attaches to the wire in the skin.  You don’t want that flap accidentally being pulled up while the sensor is presoaking.

Hotswap:  Hotswap is when you take the transmitter directly from one sensor over to another without stopping the sensor session.  The idea being that you are trying to avoid the two-hour warmup.  While some people get lucky and have minimal downtime during a hotswap…I have ALWAYS had 65 minutes without CGM data right after a hotswap.  It’s not surprising to have some ??? from the hotswap as the transmitter is noticing that the environmental conditions from one reading (in old sensor) and next reading (in new sensor) are very different.  The ??? is giving the sensor time to “find its legs” again and get used to the new surroundings.  From what I’ve experienced, that’s a 65 minute wait for the ??? to clear and BG data to start coming in.  So, while the hotswap doesn’t totally avoid the whole 2-hour warm up, it can shorten it to about 65 minutes of time without BG data.

Here’s the important part though…you really should only do hotswaps with a presoaked sensor.  That 2-hour warm up gives a chance for the sensor to settle in…so hotswaps should only be done onto a sensor that has had at least 2 hours soaking, if not more.

For the G5, the hotswap wouldn’t stop your existing session…it would just keep going.

But, for the G6 as outlined below, it does involve stopping and starting a new sensor session.  So…technically not the same kind of “hotswap” that you did (or will do) with a G5…but same idea.  Avoiding the full 2-hour warmup by using a pre-soak with it.

Can the G6 do a pre-soak and hotswap?

Tonight I experimented with trying a pre-soak/hotswap with the G6 for the first time.  Our sensor was starting to show signs of wear.  Normally we test once each morning to make sure the sensor is still accurate.  This morning the sensor was off by about 15 mg/dl.  Sure, not a huge amount…but for the G6 this is usual for us.  And then we noticed a few steep BG changes that clearly were just out of place and unusual for the G6 trends we normally see.  If you look at the screenshot below, the red dots are what her finger check was on the meter.  You can tell that the first check of the morning was quite a bit higher than the sensor value, and then the second check of the morning (done to test the sensor since it was off in the first check) showed that it was off quite a bit but this time low.

Noticing that the sensor was on its end of days (this was day 11.5 for us…about average), we did the following steps to have just 65 minutes of lost BG data vs the usual 2-hours.  Extra bonus?  When a pre-soaked sensor comes online, it doesn’t have the jumpiness that a new sensor usually has.

Pre-soak, Hotswap Procedure
    1. Got out a new sensor.  Took note of the new sensor’s code.
  1. Got out the receiver and WHILE between BG readings (they happen every 5 minutes), did a “stop sensor”, “new sensor”, entered sensor code from above, and then “start sensor”.  Immediately after starting the new sensor, I put the receiver in a faraday bag (you can put it in microwave, etc) to let the two hour warm up go by without connecting to transmitter again.
  2. Inserted the new sensor from step 1 onto Anna’s other arm.  Wrapped the new sensor in vet wrap to keep the sensor protected while no transmitter was in it.
  3. Waited 4 hours.  Ideally, I like to pre-soak for about 6 hours with the G5 system, but 4 hours is the way our life worked out tonight.  It was my first try doing this with the G6, so I wasn’t sure what to expect.  (Spoiler alert: four hours seems to have worked nicely)
  4. After 4 hours, we took the old sensor off and removed the vet wrap from the new sensor.  Immediately moved the transmitter over to the new sensor and then took the receiver out of the faraday bag.  Pretty soon after (less than 5 minutes), the transmitter connected and we got the following on the screens (both I expected).  The transmitter noticed the dramatic difference between the old sensor’s surroundings and the new sensor’s surroundings…and thus begins the ??? time period. 
  5. The next thing that happened was we got one errantly high BG before the session when to ??? sensor error for 65 minutes.
  6. After 65 minutes, the G6 came back online with a value of 149, and finger check was 163.
  7. We calibrated and VOILA…our new pre-soaked sensor was online, super accurate and not jumpy at all with only 65 minutes of lost BG data.  Here’s to the next 10 days of awesome G6 use.

So why doesn’t everyone do this?  Because a lot of us like to squeeze every last day out of our sensors and we end up having them completely fail before we start a pre-soak.  BUT, I have found that I usually can see a G6 sensor failure coming up about 6 hours ahead.  We tend to see either a few missed BG readings start to happen, jumpiness in the data, or calibration drifting.  Given that heads up, this process will be pretty easy to implement for the G6 going forward.  Small amount of pre-planning and we can get immediately smooth CGM data on a new sensor session with just 65 minutes of downtime.  Pre-soak, receiver warming up in faraday bag, hotswap, wait 65 minutes and new session underway.


But I wasn’t restarting….why the error??

Last night, we had a bleeder on a new Sensor #1.  A couple hours into its session, the sensor was losing data and just plain struggling.  Anna also said it was hurting a bit.  With those symptoms all together, we opted to pull Sensor #1 and put in a new one.

I called Dexcom to get it replaced while she put on her new Sensor #2 for the night.  Not long into warmup, about 35 minutes, the dreaded “Replace Sensor Now” message popped up accusing us (incorrectly) of trying to restart an old sensor.  (Turns out a lot of people have been having this happen to them, too.)

Anna thought it was weird, cleared the message without telling me, and tried restarting the warmup again.  Same message after another 35 minutes again.  At this point, she woke me up and told me she was having troubles.  The screen on the app was taunting us to start a new sensor, but that just didn’t sit right with me.  This was a NEW sensor.  It was about 3am now.  The last thing I wanted to do was:

  • Call Dexcom again,
  • Waste a brand new sensor,
  • Have to do a third sensor insertion, or
  • Dig out a transmitter from the brand new sensor.

So, instead I told her to just go to bed, and we left her app screen asking for a new sensor.  I grabbed the receiver out of the closet where we store it normally (we don’t usually use a receiver except for restarts).  I started a new session on the receiver, without even having the receiver connect to her transmitter first like I normally do when we are doing Option 1 restarts.  I just entered the sensor code for Sensor #2 that was still on her body, started a new session, put it in the faraday bag and went to sleep.  (If you don’t have a faraday bag, then you can keep the receiver out-of-range of the transmitter simply with adequate physical distance or by shielding it in a good microwave for the two hours.)  When I woke up about 4 hours later, I took the receiver out of the faraday bag.  It was showing “no data” and “signal loss” (like this old screenshot).  Exactly what I expected and wanted to see.  The receiver had stayed out-of-range of the transmitter for the whole warmup time.


Within 5 minutes, the receiver connected with the transmitter and was showing the last part of the warmup circle.  Also exactly what I expected and wanted to see.

And then 5 minutes after that…voila, receiver was showing its first BG value and my new Sensor #2 was no longer “needing to be replaced”.

So…the question is “Why would a brand new sensor be failing as if it is a reused one?”  I have heard from some people that Dexcom tech support is telling them that the sensor needs to pick up the “signs of trauma” that are expected from a recent insertion.  If the insertion doesn’t produce that kind of scatter and trauma in the data, the algorithm decides that this is a reused sensor.  It would appear the algorithm checks for this sensor scatter at 35 (or 65?) minutes (as that is when the “replace sensor now” messages pop-up).  By keeping the entire warmup period shielded from the transmitter, you bypass those scatter checks and can finish the startup.  I have no idea if all of this “trauma insertion check” is the truth…but that’s what Dexcom is telling people and it actually sounds plausible to me based on the observations.

The real problem is for consumers…we (and Dexcom, too) are having to be inconvienced as part of this “trauma detection” issue.  Pulling perfectly good sensors will cost Dexcom and/or the users money that doesn’t need to be spent.  And, even if the G6 doesn’t hurt for insertion (your experience may vary), nobody wants to have to do another pull of fresh adhesive off their skin unnecessarily.  Ouch.  Plus, Dexcom tech support is spending time answering phone calls about perfectly good sensors that are being rejected…adding wait times for us all unnecessarily.

So, until the “issue” is resolved (which I wouldn’t expect given the required FDA-approvals that went into this product’s design)…I highly recommend just pulling out your receiver and doing the restart like I’ve described above if you experience the same issue on a new sensor.  Save yourself the call to tech support, save yourself the new insertion, save the hassle.

Side Note:  This also confirms another nugget.  You could do this same procedure to restart an old sensor in the event you forgot to start the restart process in time.  Instead, wait for the session to end, then do this procedure that I’ve outlined above.  You’ll be able to restart an old sensor.

Side Note #2:  Based on what we know so far, I expect that a person who does not have a receiver could also just do Option #2 and restart similarly.     I haven’t tested it, but it would seem probable to be successful so long as there is no communication with the transmitter during the warmup.