Running and fueling for runs with type 1 diabetes

This blog post is not for you. (Well that sounds mean, doesn’t it? It’s not meant to be mean. But this post is written for a very small subset of people like me who are stumbling around on page 16 of Google trying to find someone sharing experiences and specific details around methods (both successful and less so) for fueling for longer endurance events such as full marathons or ultramarathons with type 1 diabetes. So – please don’t be offended, but also don’t be surprised if you don’t find this post very useful!)

I’ve started running again, and more, this year, and am now to the point where I’m considering running another full marathon sometime next year. As I adventure into running longer distances, and more miles, I’m reflecting on what I did in my first full marathon that worked related to diabetes, and what I want to try to do differently. This post is logging some of my experiences and notes to date, in honor of fellow page-16-of-Google-seekers, rather than waiting til after I run another full (if I do) and there continuing to be not much info out there.

Some background on my running:

I’m not a runner. And not a good runner. I never liked running. But, I walked the Seattle half marathon in December 2012 and thought it might be fun to then walk the full marathon in December 2013. However, I also tried snowboarding for the first time in January 2013 and majorly damaged my knee. I could barely walk the few blocks to work every day, let alone do my normal activities. It took several months, and several PT sessions, to get back to normal. But part of my frustration and pain manifested into the idea that I should recover enough to still walk that full marathon in December. And in order to be off the course by the time it closed, I would need to run a little bit. And I could barely walk, and never ran, so I would need to do some training to be able to run a mile or two out of the 26.2 I planned to otherwise walk. So I set off to teach myself how to run with the idea of walk/running the full, which evolved into a plan to run/walk it, and mostly eventually run it. And that’s what I did.

Now – this marathon was December 2013. This was right when we created DIYPS, and a year before we closed the loop, so I was in full, old-school traditional manual diabetes mode. And it sucked quite a bit. But now, almost 5 years later, with the benefit of everything I’ve learned from DIYPS and OpenAPS about insulin and food timing etc., here’s what I realized was happening – and why – in some of my training runs.

What I worried about was going low during the runs. So, I generally would set a low temporary basal rate to reduce insulin during the run, and try to run before dinner instead of after (to reduce the likelihood of running with a lot of active insulin in my body). I would also eat some kind of snack – I think for energy as well as making sure I didn’t go low. I would also carry a bottle of Gatorade to drink along the way.

With the benefit of 5 years of lots of learning/thinking about all the mechanics of diabetes, here’s what was happening:

Per the visualization, the carbs would hit in about 15 minutes. If I reduced insulin at the time of the run, it would drive my blood sugar up as well, over a longer time frame (after around 45+ minutes as the lack of insulin really started to kick in and previous basal impact tailed off). The combination of these usually meant that I would rise toward the middle or end of my short and medium runs, and end up high. In longer runs, I would go higher, then low – and sip gatorade, and have some roller coaster after that.

Now, this was frustrating in training runs, but I did ok for my long runs and my marathon had pretty decent BGs with no lows. However, knowing everything I know now, and commencing a new burst of running, I want to try to do better.

Here’s what I’ve been doing this year in 2018:

My original interest in running was to set a mileage goal for the year, because I didn’t run very much last year (around 50 miles, mostly throughout summer), and I wanted to try to run more regularly throughout the year to get a more regular dose of physical activity. (I am very prone to looking at Seattle weather in October-December and January-March and wanting to stay inside!) That mileage goal was ambitious for me since I didn’t plan to race/train for any distance. To help me stick to it, I divided it by 12 to give myself monthly sub-goals that I would try to hit as a way to stay on top of making regular progress to the goal.

(Ps – pro tip – it doesn’t matter how small or big your goal is. If you track % progress toward whatever your mileage goal is, it’s really nice! And it allows you to compete/compare progress, even if your friends have a much bigger mileage goal than you. That way everyone can celebrate progress, and you don’t have to tell people exactly what your mileage goal might be. What’s tiny for you is big for others; and what’s big for you may be small to others – and that doesn’t matter at all!)

This has worked really well. The first few months I scraped by in keeping up with my monthly goal. Except for February, when I had three weeks of flu and bronchitis, so I surged in March to finish February’s miles and March’s miles. I then settled back into a regular amount, meeting my monthly goals…and then surged again in August, so I was able to finish my yearly mileage in the middle of September! Wahoo! I didn’t plan to stop there, though, so I planned to keep running, and that’s where the idea of running the Seattle half (always the Sunday after Thanksgiving) popped up again, and maybe a full next year. I started adding some longer runs (two 7.5 miles; a 9.35 miler, and now a 13 miler) over the past month, and have felt really good about those, which has enabled me to start thinking more carefully about what I did last time BG-wise and why this time is so much easier.

Earlier in the year, even on my short runs (one mile or so), I quickly realized that because of the shorter peak of Fiasp, I was less likely to have previous insulin activity drive me low during the run. Within the first handful of runs, I stopped eating a snack or some carbs before the run. I also stopped setting a super high target an hour before my run. I gradually moved into just avoiding >1.5u of insulin on board before short runs; and for longer runs, setting a target of ~110 about 30 minutes before I walked out the door, mostly to avoid any of that insulin activity dosed that would kick in right after I started running. (Keep in mind when I talk about setting targets: I’m using OpenAPS, my DIY closed loop system that does automatic insulin dosing; and for fellow DIY closed loop users, I’m also using exercise mode settings so I can set lower targets like 110 and the targets also automatically adjust my sensitivity and recalculate IOB accordingly. So without those settings, I’d probably set the target to 130 or so.)

And this has worked quite well for me.

Is it perfect? No, I do still go low sometimes..but probably <10% of my runs instead of 50% of them, which is a huge improvement. Additionally, because of having OpenAPS running to pick up the rebound, there’s not usually much of a rebound and resulting roller coaster like I would have in 2013. Additionally, because autosensitivity is running, it picks up within a few hours of any additional sensitivity to insulin, and I don’t have any overnight lows after running. Yay!

However, that all assumes I’m running at a normal-for-my-body or slower speed.

There’s a nice (annoying) phenomenon that if you sprint/run faster than your body can really handle, your liver is going to dump and your BG will spike as a result:

I didn’t ever notice this in 2013, but I’ve now run enough and at varying paces to really understand what my fitness level is, and see very obvious spikes due to surges like this when I’m sprinting too fast. Some days, if I run too fast (even for a mile), I’ll have a surge up to 180 or 200 mg/dL, and that’ll be higher than my BG is for the rest of that 24 hour period. Which is annoying. Funny, but annoying. Not a big deal, because after my run OpenAPS can take care of bringing my down safely.

But other than the running-too-fast-spikes, my BGs have been incredible during and following my runs. As I thought about contributing factors to what’s working well, this is what’s likely been contributing:

  • with a mix of Fiasp & another short-acting insulin, I’m less likely to have the ‘whoosh’ effect of any IOB
  • but I’m also not starting with much IOB, because I tend to run first thing, or several hours after a meal
  • and of course, I have a DIY closed loop that takes care of any post-run sensitivity and insulin adjustments automatically

As I thought more about how much I’ve been running first thing in the morning/day, and usually not eating breakfast, that made me start reading about fasted long runs, or glycogen depleted runs, or low carb runs. People call them all these things, and I’m putting them in the post for my fellow page-16-of-Google-seekers. I call it “don’t eat breakfast before you run” long runs.

Now, some caveats before I go further into detail about what’s been working for me:

  • Your Diabetes May Vary (YDMV). in fact, it will. and so will your fitness level. what works for you may not be this. what works for you will probably not work for me. So, use this as input as one more blog post that you’ve read about a potential method, and then tweak and try what works for you. And you do you.
  • I’m not doing low carb. (And different people have different definitions of low carb, but I don’t think I’m meeting any of the definitions). What I’m talking about is not eating breakfast, a snack, or a meal before my runs in the morning. When I return from runs, I eat lunch, or a snack/meal, and the rest of my day is the usual amount/type of food that I would eat. (And since I have celiac, often times my gluten free food can be higher carb than a typical diet may be. It depends on whether I’m eating at home or eating out.) So, don’t take away anything related to overall carb consumption, because I’m not touching that! That’s a different topic. (And YDMV there, too.)
  • What I’m doing doesn’t seem to match anything I’ve read for non-T1D runners and what they do (or at least, the ones who are blogging about it).

Most of the recommendations I’ve read for glycogen depletion runs is to only do it for a few of your long runs in a marathon training cycle; that you should still eat breakfast before a full marathon; and you should only do fasted/glycogen depletion for slow, easy long runs.

I’m not sure yet (again, not in a full marathon cycle training), but I actually think based on my runs to date that I will do ok (or better) if I start without breakfast, and take applesauce/gatorade every once in a while as I feel I need it for energy, and otherwise managing my BG line. If I start a downtick, I’d sip some carbs. If I started dropping majorly, I’d definitely eat more. But so far, managing BG rather than trying to prescriptively plan carbs (for breakfast, or the concept of 30-60 per hour), works a lot better for me.

Part of the no-breakfast-works-better-for-me might be because the longevity of insulin in your body is actually like 6 hours (or more). Most non-T1D runners talk about a meal 3 hours before the start of your race. And they’re right that the peak and the bulk of insulin would be gone by then, but you’d still have a fair bit of residual insulin active for the first several hours of your race, and the body’s increased sensitivity to that insulin during exercise is likely what contributes to a lot of low BGs in us T1 runners. There’s also a lot of talk about how fasting during training runs teaches your body to better burn fat; and how running your race (such as a marathon) where you do carb during the race (whether that’s to manage BGs or more proactively) will make your body feel better since it has more fuel than you’re used to. That’s probably true; but given the lower insulin action during a run (because you’ve been fasted, and you may be on a lower temp basal rate to start), you’re likely to have a larger spike from a smaller amount of carbs, so the carb-ing you do before or during these long runs or a marathon race may need to be lower than what a non-T1D might do.

tl;dr – running is going better for me and BG management has been easier; I’m going to keep experimenting with some fasted runs as I build up to longer mileage; and YDMV. Hope some of this was helpful, and if you’ve done no-breakfast-long-runs-or-races, I’d love to hear how it worked for you and what during-race fueling strategy you chose as a result!

Presentations and poster content from @DanaMLewis at #2018ADA

DanaMLewis_ADA2018As I mentioned, I am honored to have two presentations and a co-authored poster being presented at #2018ADA. As per my usual, I plan to post all content and make it fully available online as the embargo lifts. There will be three sets of content:

  • Poster 79-LB in Category 12-A Detecting Insulin Sensitivity Changes for Individuals with Type 1 Diabetes using “Autosensitivity” from OpenAPS’ poster, co-authored by Dana Lewis, Tim Street, Scott Leibrand, and Sayali Phatak.
  • Content from my presentation Saturday, The Data behind DIY Diabetes—Opportunities for Collaboration and Ongoing Research’, which is part of the “The Diabetes Do-It-Yourself (DIY) Revolution” Symposium!
  • Content from my presentation Monday, Improvements in A1c and Time-in-Range in DIY Closed-Loop (OpenAPS) Users’, co-authored by Dana Lewis, Scott Swain, and Tom Donner.

First up: the autosensitivity poster!

Dana_Scott_ADA2018_autosens_posterYou can find the full write up and content of the autosensitivity poster in a post over on OpenAPS.org. There’s also a twitter thread if you’d like to share this poster with others on Twitter or elsewhere.

Summary: we ran autosensitivity retrospectively on the command line to assess patterns of sensitivity changes for 16 individuals who had donated data in the OpenAPS Data Commons. Many had normal distributions of sensitivity, but we found a few people who trended sensitive or resistant, indicating underlying pump settings could likely benefit from a change.
2018 ADA poster on Autosensitivity from OpenAPS by DanaMLewis

 

Presentation:
The Data behind DIY Diabetes—Opportunities for Collaboration and Ongoing Research’

This presentation was a big deal to me, as it was flanked by 3 other excellent presentations on the topic of DIY and diabetes. Jason Wittmer gave a great overview and context setting of DIY diabetes, ranging from DIY remote monitoring and CGM tools all the way to DIY closed loops like OpenAPS. Jason is a dad who created OpenAPS rigs for his son with T1D. Lorenzo Sandini spoke about the clinician’s perspective for when patients come into the office with DIY tools. He knows it from both sides – he’s using OpenAPS rigs, and also has patients who use OpenAPS. And after my presentation, Joyce Lee also spoke about the overarching landscape of diabetes and the role DIY plays in this emerging technology space.

Why did I present as part of this group today? One of the roles I’ve taken on in the last few years in the OpenAPS community (among others) is a collaborator and facilitator of research with and about the community. I put together the first outcomes study (see here in JDST or here in a blog post form on OpenAPS.org) in 2016. We presented a poster on Autotune last year at ADA (see here in a blog post form on OpenAPS.org). I’ve also worked to create and manage the OpenAPS Data Commons, as well as build tools for researchers to use this data, so individuals can easily and anonymously donate their DIY closed loop data for other research projects, lowering the friction and barriers for both patients and researchers. And, I’ve co-led or led several research projects with the community’s data as a result.

My presentation was therefore about setting the stage with background on OpenAPS & how we ended up creating the OpenAPS Data Commons; presenting a selection of research projects that have utilized data from the community; highlighting other research projects working with the OpenAPS community; announcing a new international collaboration (OPEN – more coming on that in the future!) for research with the DIY community; and hopefully encouraging other diabetes researchers to think about sharing their work, data, methods, tools, and insights as openly possible to help us all move forward with improving the lives of people with diabetes.

That is, of course, quite an abbreviated summary! I’ve shared a thread on Twitter that goes into detail on each of the key points as part of the presentation, or there’s a version of this Twitter/presentation content also written below.

If you’re someone who wants to do research with retrospective data from the OpenAPS Data Commons, you can find out more about it here (including instructions on how to request data). And if you’re interested in prospective research, please do reach out as well!

Full content for those who don’t want to read Twitter:

Patients are often seen as passive recipients of care, but many of us PWDs have discovered that problems are opportunities to change things. My journey to DIY began after I was frustrated by my inability to hear CGM alarms at night. 4 years ago, there was no way for me to access my own device data in real time OR retrospectively. Thanks to John Costik for sharing his code, I was able to get my CGM data & send it to the cloud and down to my phone, creating a louder alarm. Scott and I created an algorithm to push notifications to me to take action. This was an ‘open loop’ system we called #DIYPS. With Ben West’s help, we realized could combine our algorithm with small, off-the-shelf hardware & a radio stick to automate insulin delivery. #OpenAPS was thus created, open sourcing all components of DIY closed loop system so others could close the loop, too. An #OpenAPS rig consists of a small computer, radio chip, & battery. The hardware is constantly evolving. Many of us also use Nightscout to visualize our closed loop data, and share with loved ones.

2018ADA_slide12018ADA_slide 42018ADA_slide 32018ADA_Slide 2

 

 

 

 

 

 

I closed the loop in December of 2015. As people learned about it, I got pushback: “It works for you, but how do you know it’s going to work for others?” I didn’t, and I said so. But that didn’t mean I shouldn’t share what was working for me.

Once we had dozens of users of #OpenAPS, we presented a research study at #2016ADA, with 18 individuals sharing outcomes data on A1c, TIR, and QOL improvements. (See that publication here: https://twitter.com/danamlewis/status/763782789070192640 ). I was often asked to share my data for people to analyze, but I’m not representative of entire #OpenAPS community. Plus, the community has kept growing: we estimate there are more than (n=1)*710+ (as of June 2018) people worldwide using different kinds of DIY APs. (Note: if you’d like to keep track of the growing #OpenAPS community, the count of loopers worldwide is updated periodically at  https://openaps.org/outcomes ).  I began to work with Open Humans to build the #OpenAPS Data Commons, enabling individuals to anonymously upload their data and consent to share it with the Data Commons.

2018ADA_Slide 52018ADA_Slide 62018ADA_Slide 72018ADA_Slide 8

 

 

 

 

 

Criteria for using the #OpenAPS Data Commons:

  • 1) share insights back with the community, especially if you find something about an individual’s data set where we should notify them
  • 2) publish in an accessible (and preferably open) manner

I’ve learned that not many are prepared to take advantage of the rich (and complex) data available from #OpenAPS users; and many researchers have varying background and skillsets.  To aid researchers, I created a series of open source tools (described here: http://bit.ly/2l5ypxq, and tools available at https://github.com/danamlewis/OpenHumansDataTools ) to help researchers & patients working with data.

2018ADA_Slide 10 2018ADA_Slide 9

 

 

 

We have a variety of research projects that have leveraged the anonymously donated, DIY closed loop data from the #OpenAPS Data Commons.

  • 2018ADA_Slide 112018ADA_Slide 12One research project, in collaboration with a Stanford team, evaluated published machine learning model predictions & #OpenAPS predictions. Some models (particularly linear regression) = accurate predictions in short term, but less so longer term when insulin peaks. This study is pending publication, but I’d like to note the challenge of more traditional research keeping pace with DIY innovation: the code (and data) studied was from January 2017. #OpenAPS prediction code has been updated 2x since then.
  • In response to the feedback from the #2016ADA #OpenAPS Outcomes study we presented, a follow up study on #OpenAPS outcomes was created in partnership with a team at Johns Hopkins. That study will be presented on Monday, 6-6:15pm (352-OR).
  • 2018ADA_Slide 13Many people share publicly online their outcomes with DIY closed loops. Sulka Haro has shared his script to evaluate the reduction in daily manual diabetes interventions after they began using #OpenAPS. Before: 4.5/day manual corrections; now they treat <1/day.
  • #OpenAPS features such as autosensitivity automatically detect sensitivity changes and insulin needs, improving outcomes. (See above at the top of this post for the full poster content).
  • If you missed it at #2017ADA (see here: http://bit.ly/2rMBFmn) , Autotune is a tool for assessing changes to basal rates, ISF, and carb ratio. Developed for #OpenAPS users but can also be used by traditional pumpers (and some MDI users also utilize it).

I’m also thrilled to share a new tool we’ve created: an #OpenAPS simulator to allow us to more easily back-test and compare settings changes & feature changes in #OpenAPS code.
2018ADA_Slide 14

  • Screen Shot 2018-06-22 at 4.48.06 PM2018ADA_Slide 16  We pulled a recent week of data for n=1 adult PWD who does no-bolus, rough carb entry meal announcements, and ran the simulator to predict what the outcomes would be for no-bolus and no meal-announcement.

 

  • 2018ADA_Slide 172018ADA_Slide 18 We also ran the simulator on n=1 teen PWD who does no-bolus and no-meal-announcement in real life. The simulator tracked closely to his actual outcomes (validated this week with a lab-A1c of 6.1)

 

 

 

The new #OpenAPS simulator will allow us to better test future algorithm changes and features across a diverse data set donated by DIY closed loop users.

There are many other studies & collaborations ongoing with the DIY community.

  • Michelle Litchman, Perry Gee, Lesly Kelly, and myself have a paper pending review analyzing social-media-reported outcomes & themes from DIY community.
  • 2018ADA_Slide 19There are also multiple other posters about DIY outcomes here at #2018ADA:
  • 2018ADA_Slide 20 There are many topics of interest in DIY community we’d like to see studies on, and have data for. These include: “eating soon” (optimal insulin dosing for lesser post-prandial spikes); and variability in sensitivity for various ages, pregnancy, and menstrual cycle.
  • 2018ADA_Slide 21I’m also thrilled to announce funding will be awarded to OPEN (a new collaboration on Outcomes of Patients’ Evidence, with Novel, DIY-AP tech), a 36-month international collaboration assessing outcomes, QOL, further development, access of real-world AP tech, etc. (More to come on this soon!)

In summary: we don’t have a choice in living with diabetes. We *do* have a choice to DIY, and also to research to learn more and improve knowledge and availability of tools for us PWDs, more quickly. We would love to partner and collaborate with anyone interested in working with the DIY community, whether that is utilizing the #OpenAPS Data Commons for retrospective studies or designing prospective studies. If you take away one thing today: let it be the request for us to all openly share our tools, data, and insights so we can all make life with type 1 diabetes better, faster.

2018ADA_Slide 222018ADA_Slide 23

 

 

 

 

A huge thank you as always to the community: those who have donated and shared data; those who have helped develop, test, troubleshoot, and otherwise help power the #OpenAPS and other DIY diabetes communities.

2018ADA_Slide 24

Presentation:
Improvements in A1c and Time-in-Range in DIY Closed-Loop (OpenAPS) Users

(full tweet thread available here; or a description of this presentation below)

#OpenAPS is an open and transparent effort to make safe and effective Artificial Pancreas System (APS) technology widely available to reduce the burden of Type 1 diabetes. #OpenAPS evolved from my first DIY closed loop system and our desire to openly share what we’ve learned living with DIY closed loops. It takes a small, off-the-shelf computer; a radio; and a battery to communicate with existing insulin pumps and CGMs. As a PWD, I care a lot about safety: the safety reference design is the first thing in #OpenAPS that was shared, in order to help set expectations around what a DIY closed loop can (and cannot) do.

ADA2018_Slide 23ADA2018_Slide 24As I shared about my own DIY experience, people questioned whether it would work for others, or just me. At #2016ADA, we presented an outcomes study with data from 18 of the first 40 DIY closed loop users. Feedback on that study included requests to evaluate CGM data, given concerns around accuracy of self-reported outcomes.

This 2018 #OpenAPS outcomes study was the result. We performed a retrospective cross-over analysis of continuous BG readings recorded during 2-week segments 4-6 weeks before and after initiation of OpenAPS.

ADA2018_Slide 26For this study, n=20 based on the availability of data that met the stringent protocol requirements (and the limited number of people who had both recorded that data and donated it to the #OpenAPS Data Commons in early 2017).  Demographics show that, like the 2016 study, the people choosing to #OpenAPS typically have lower A1C than the average T1D population; have had diabetes for over a decade; and are long-time pump and CGM users. Like the 2016 study, this 2018 study found mean BG and TIR improved across all time categories (overall, day, and nighttime).

ADA2018_Slide 28ADA2018_Slide 29ADA2018_Slide 30ADA2018_Slide 31ADA2018_Slide 32

Overall, mean BG (mg/dl) improved (135.7 to 128.3); mean estimated HbA1c improved (6.4 to 6.1%). TIR (70-180) increased from 75.8 to 82.2%. Overall, time spent high and low were all reduced, in addition to eAG and A1c reduction. Overnight (11pm-7am) had smaller improvement in all categories compared to daytime improvements in these categories.

Notably: although this study primarily focused on a 4-6 week time frame pre-looping vs. 4-6 weeks post-looping, the improvements in all categories are sustained over time by #OpenAPS users.

ADA2018_Slide 33 ADA2018_Slide 34

ADA2018_Slide 35Conclusion: Even with tight initial control, persons with T1D saw meaningful improvements in estimated A1c, TIR, and a reduction in time spent high and low, during the day and at night, after initiating #OpenAPS. Although this study focused on BG data from CGM, do not overlook additional QOL benefits when analyzing benefits of hybrid closed loop therapy or designing future studies! See these examples shared from Sulka Haro and Jason Wittmer as example of quality of life impacts of #OpenAPS.

A huge thank you to the community: those who have donated and shared data; those who have helped develop, test, troubleshoot, and otherwise help power the #OpenAPS and other DIY diabetes communities.

And, special thank you to my co-authors, Scott Swain & Tom Donner, for the collaboration on this study. Lewis_Donner_Swain_ADA2018

Getting ready for #2018ADA (@DanaMLewis) & preparing to encourage photography

We’re a few weeks away from the 78th American Diabetes Scientific Sessions (aka, #2018ADA), and I’m getting excited. Partially because of the research I have the honor of presenting; but also because ADA has made strides to (finally) update their photography policy and allow individual presenters to authorize photography & sharing of their content. Yay!

As a result of preparing to encourage people to take pictures & share any and all content from my presentations, I started putting together my slides for each presentation, including the slide about allowing photography, which I’ll also verbally say at the start of the presentation. Interestingly to me, though, ADA only provided an icon for discouraging photography, saying that if staff notice that icon on any photos, that’s who will be asked to take down photos. I don’t want any confusion (in past years, despite explicit permission, people have been asked to take down photos of my work), so I wanted to include obvious ‘photography is approved’ icons.

And this is what I landed on for a photography encouraged slide, and the footer of all my other slides:

Encouraging photography in my slides Example encouraging use of photography in content slidesEncouraging photography in the footer of my slides

And, if anyone else plans to encourage (allow) photography and would like to use this slide design, you can find my example slide deck here that you are welcome to use: http://bit.ly/2018ADAexampleslides

I used camera and check mark icons which are licensed to be freely used; and I also licensed this slide deck and all content to be freely used by all! I hope it’s helpful.

Where you’ll find me at #2018ADA

And if you’re wondering where and what I’ll be presenting on with these slides…I’ll be sharing new content in a few different times and places!

On Saturday, I’m thrilled there is a full, 2-hour session on DIY-related content, and to get to share the stage with Jason Wittmer, Lorenzo Sandini, and Joyce Lee. That’s 1:45-3:45pm (Eastern), “The Diabetes Do-It-Yourself (DIY) Revolution”, in W415C (Valencia Ballroom). I’ll be discussing some of the data & research in DIY diabetes! A huge thanks to Joshua Miller for championing and moderating this session.

I’m also thrilled that a poster has been accepted on one of the projects from my RWJF grant work, in partnership with Tim Street (as well as Scott Leibrand, and Sayali Phatak who is heading our data science work for Opening Pathways). The embargo lifts on Saturday morning (content will be shared online then), and the poster will be displayed Saturday, Sunday, and Monday. Scott and I will also be present with the poster on Monday during the poster session from 12-1pm.

And last but not least, there is also an oral presentation on Monday evening with a new study on outcomes data from using OpenAPS. I’ll be presenting during the 4:30-6:30pm session (again in W415C (Valencia Ballroom)), likely during the 6-6:15pm slot. I’m thrilled that Scott Swain & Tom Donner, who partnered on this study & work, will also be there to help answer questions about this study!

As we have done in the past (see last year’s poster, for example), we plan to share all of this content online once the embargo lifts, in addition to the in-person presentations and poster discussions.

A huge thanks, as always, goes to the many dozens of people who have contributed to this DIY community in so many ways: development, testing, support, feedback, documentation, data donation, and more! <3

Hormones, CGM preferences, DIY, and why so many things are YDMV even when #WeAreNotWaiting

I posted one of my Nightscout graphs yesterday, showing a snapshot of my morning:

I hadn’t eaten, and my blood sugar still spiked up. I’ve noticed this happens in the mornings sometimes. When I have mentioned it over the years, people are quick to tell me my basal rates are wrong, and I should adjust them because dawn phenomenon. But actually, this isn’t dawn phenomenon. This happens after I physically get up and start moving for the day, whether that happens at 4am, or 6am, or 10am, or even waking up after noon. So, it’s not a basal thing, and modifying my basal rates doesn’t fix it. (And this is why I wanted to add wake-up mode to my suite of tools, to help address this.)

To me, this is a great example, (as I mentioned in my Twitter thread), of why diabetes is so hard: sooooo many things impact BG levels, and in many cases, we PWDs just have to roll with it and respond the best we can. In my case, #OpenAPS did a great job responding to the spike and bringing me back down within an hour or so.

One of the questions that popped up yesterday in response to that graph, though, was about the BG line: how did I have two BG lines?

The answer: I wear a G4 sensor, and usually have 2 receivers running off the same transmitter and sensor. One receiver is Share-d to my phone, and uploads to NS via the interwebz. The other receiver, although Share-capable, doesn’t (because the company only allows you to pair one receiver and upload via Share). I leave that CGM plugged into a rig to enable it to be a backup for offline looping. When online, this rig with the plugged in CGM uploads BGs from that receiver to NS.

Sometimes, because of different start/stop times and therefore differing calibration records, the receivers “drift” from each other, making it obvious on the graph when that happens.

Because if you give a mouse a cookie, other questions come up, someone had also asked me why I’m using G4, and why not G5. Someone else asked me in a different channel why I’m not using G5 and xDrip+ (a DIY option that doesn’t use Dexcom app or a Dexcom receiver for receiving the data or processing it), or another DIY tool to process my CGM data.

Now, as always, what I chose to use is my personal preference. It’s colored by my preference for what equipment I’m willing to carry; what phone I want to use; what data I want to have; my safety backup preferences; what my insurance covers and what I can afford; where I live; etc. So, just because I use this method, doesn’t mean I expect anyone else to want to do it. It’s just what I do. I don’t try to convince other people to use this method, and I also hope others can share info about what works for them without trying to hammer me over the head because what I’m doing is different. This is where YDMV (your diabetes may vary) comes in. It’s so true, and even within “people who DIY”, there’s a ton of variation – and that’s a good thing! I adore having options to find what works for me, and I want to have other people have options and choices to choose what works for them.

That being said, here’s the answer to how I run my CGMs and some of the things that have factored into my choice to not DIY CGM receivers/data processing most of the time:

  • With two G4 receivers, I can keep one in my pocket, paired to my phone and uploading via Share. When I’m out and about in the city or usually during the day, this is what I carry. When I run, I take the Share receiver.
  • But, I also like emergency back-ups. I like keeping a receiver plugged into an #OpenAPS rig so that if connectivity goes out/down, I can keep looping without a break in my stride. So, I could keep my Share receiver plugged into the rig, but that would involve me unplugging and replugging fairly frequently when I run errands or actually go for a short run, and meh. Hassle. So I keep “non-Share” receiver as the one that’s usually plugged into my ‘offline’ rig.
  • Having the G4 receiver plugged into the rig enables me to see raw data. Raw data is nice for a couple of things: assessing the health of my sensor (if it gets jumpy compared to the filtered data, I know the quality of the sensor is decreasing, and that helps me decide when to change it); giving me a clue to what’s going on when the filtered data goes to ??? or during the start up of a new sensor; and actually being able to run my rig and loop off some* of the raw data when I need to. (*With OpenAPS, you can choose to loop off of it within a certain range, and there’s an option to only set a certain amount of correction for a proportion of what otherwise would be proposed, with a higher level of raw data.)
  • With two receivers running, that also gives me more flexibility around sensor changes. Technically, the sensor is approved for 7 days. At the end of the 7 days, the receiver stops giving you data and forces you to “start” a new sensor session. That could be by inserting a new sensor; or it could be the same sensor on your body. But either way, theoretically it’s a 2 hour ‘warm up’ period from that session where you can’t see data. With 2 receivers, I can stagger the end and start of sensor sessions. I usually set a calendar alarm to restart one of the receivers on the night of the 6th day of the session, allowing me more flexibility on day 7 to choose when to restart or change my sensor.
  • This also means I can choose to “hot swap” when actually changing a sensor. I may choose to not hit ‘stop’ and ‘start’ on a sensor session on one of the receivers, but rather shut it off for about 30 minutes, and just do the stop/start on the other receiver (leaving it plugged into a rig to upload raw data to NS, and be able to see where the new sensor’s readings come in compared to the old one). When I power the non-restarted receiver back on about 30m after swapping the transmitter over to the new receiver (as soon as the raw readings have flattened out), it usually either goes to “no signal” for a few minutes, and then comes back with some data, an hour or more before the restarted sensor allows me to calibrate it and get data. There are downsides to this method: the data on the receiver that didn’t get restarted can be fairly inaccurate, as it’s still using the calibrations from the old sensor. So I don’t always do that, but when it’s more important to me to be able to see relative trend of where BG is (flat, or dropping or spiking), it’s nice to have that option. And since I often soak my new CGM sensors, the data from “day 1” of the sensor after a session “start” on the receiver is often better than if it was truly day 1 of the sensor being in my body.

Phew. Maybe that sounds like a lot of work, but the above setup works well for me for a variety of reasons, and also allows me the flexibility and choice for when I change sensors, when I am forced to be without data or potentially not loop, etc. Given that my schedule varies a lot, it helps since I’m not consistently in the same time zone and what works for starting or changing sensors one week in one part of the world doesn’t always align with convenience exactly 168 hours (7 days) later in another part of the world that I’m in, doing something differently.

Some of the reasons I haven’t switched to G5 include the fact that the transmitters only last for ~3 months instead of 6+ months; I’ve observed many people being frustrated by sensor not talking to the phone even when it’s right beside them; there’s no raw data on G5; you can’t have multiple receivers paired with your transmitter; etc.

Now, you might say, but that’s using Dexcom’s app, etc. With DIY solutions, those limitations don’t apply! And that’s true, to a degree – savvy folks in the community have figured out how to make it so you don’t *have* to use Dexcom’s app to display or process the data; you can replace the batteries on the transmitter; etc. But, just like my method above of using raw data isn’t necessarily going to work for everyone or might not be something someone else choose to do, the DIY options that go with G5 (or even G4 in some cases), aren’t something I believe is the right thing to do for me.

A lot of it comes down to safety. When we first started designing my DIY closed loop, we spent eons discussing how we could do this safely for me. And that evolved into further discussions about how other people could do this safely, too. A core of the OpenAPS Reference Design is that we are using already approved and vetted devices that exist on the market (e.g. existing pumps and CGMs). Those devices include approved and vetted methods for CGM data processing, too, which is even more important when the CGM data is being used to dose insulin as in OpenAPS. Now – this is not a requirement we can enforce: people can do what they want, and some people are even using non-CGMs (such as the Libre, a “Flash Glucose Monitoring” solution, plus a DIY NFC reader) as a CGM source for looping. But, whether it’s a DIY app or algorithm on CGM data, or a different glucose measuring device that’s not a CGM, that’s choice has some safety implications that I hope people are aware of.

First, the background for those who aren’t familiar: the CGM companies display a processed (“filtered”) version of the CGM data. That’s part of their proprietary stuff, but there’s reasons behind it: the raw data can be hectic and weird, and individual readings aren’t the point, anyway. The beauty of CGM is you can see the trends in addition to the estimated BG number.  In some scenarios, such as during sensor starts, during error messages that are displayed as ???, etc, the companies/FDA decided that the CGM should not show data, and instead show an error message/symbol, to help prevent anyone from making incorrect treatment decisions based off of confusing or misleading data.  That’s good enough most of the time.  As mentioned above, there are edge cases when seeing the raw is helpful, but most of the time, I’m happy with the filtered data.

But to me, there’s a difference between using raw or DIY-calibrated data for edge cases, vs. using them all the time. I’ve seen several cases in just the past few days with a newer “DIY CGM app”, which uses its own calibration algorithm for processing the unfiltered CGM readings.  These people have reported the app displaying normal BGs (say, 90 mg/dL), while they found themselves in the 40’s (rather low). It’s not clear whether that is due to the app’s calibration algorithm, something the user did in testing and calibrating, or if it’s just a bad sensor, and since most of them are not using the official receiver/app in parallel, that’s difficult to figure out.  But regardless, it’s happened enough times across numerous people for me to be concerned about a DIY CGM app being used as the primary source of CGM data. There are limitations to using company-built apps or physical devices for CGMs, but in the case where people can afford it, for safety I think it is important to at least use the approved and vetted receiver/app in parallel, to provide a backup and baseline level of alerting and alarming. The FDA & the companies have worked to create something that can be reliable for alarming when your BG is actually low (say <55 mg/dl) and alerting a human that something is going on. This is important regardless of whether people are looping or not, but it’s perhaps even more important when people are looping, since that data is driving insulin dosing decisions. Additionally, the company-created devices have been designed to deal with miscalibrations that aren’t in line with what the data from the receiver is showing, and have safety measures in place to “reject” calibrations and request new ones when necessary. Sure: there are times where that’s frustrating, but those features truly are “there for safety”, and are important for avoiding the rare but potentially serious outcomes that could be caused by incorrect CGM readings. Since safety is what we prioritize and design around in DIY closed looping, I hope people will consider that ,and prioritize safety first when choosing what to use as their primary data source.

Tl;dr – YDMV. I currently use G4 with two receivers, for the reasons described above. I think it’s important to prioritize safety over convenience most of the time, and understand the limitations of the solution that you choose (DIY or commercial). But everyone’s different, and their situation, preferences, etc. may drive different decision making. And did I mention YDMV?

Exploring other sensors that could be used with #OpenAPS and for diabetes in general

Nobody appeared to notice the other day when I tweeted about going through airport security with 13 pieces of adhesive on my body. Which is amusing to me, because normally I sport two: my insulin pump site, and my continuous glucose monitor (CGM) sensor. That particular day, I added another diabetes-related piece of adhesive (I was giving the Freestyle Libre, a flash aka not quite continuous glucose monitor, a try), and 10 pieces of adhesive not directly related to diabetes. Or maybe, it will be in the future – and that’s what I’m trying to figure out!

Last fall, my program officer from RWJF (for my role as PI on this RWJF-funded grant – read more about it here if you don’t know about my research work) made an introduction to a series of people who may know other people that I should speak to about our project’s work. One of these introductions was to a researcher at UCSD, Todd Coleman. I happened to be in San Diego for a meeting, so my co-PI Eric Hekler and I stopped by to meet Todd. He shared about his lab’s work to develop an ambulatory GI sensor to measure gastric (stomach) activity and my brain immediately started drooling over the idea of having a sensor to better help assess our methods in the DIY closed looping community for articulating dynamic carb absorption, aka how slow or fast carbs are absorbing and therefore impacting blood glucose levels. I took over part of the white board in his office, and started drawing him examples of the different data elements that we have #OpenAPS (my DIY hybrid closed loop “artificial pancreas”) calculate every 5 minutes, and how it would be fantastic to wear the GI sensor and graph the gastric activity data alongside this detailed level of diabetes data.

I immediately was envisioning a number of things:

  • Assessing basic digestion patterns and figuring out if the dynamic carb absorption models in OpenAPS were reasonable. (Right now, we’re going off of observations and tweaking the model based on BG data and manual carb entry data from humans. Finding ways to validate these models would be awesome.)
  • Seeing if we can quantify, or use the data to better predict, how post-meal activity like walking home after dinner impacts carb absorption. (I notice a lot of slowed digestion when walking home from dinner, which obviously impacts how insulin can and should be dosed if I know I’ll be walking home from dinner or not. But this is something I’ve learned from a lot of observation and trial and error, and I would love to have a more scientific assessment of this impact).
  • Seeing if this could be used as a tool to help people with T1D and gastroparesis, since slowed digestion impacts insulin dosing, and can be unpredictable and frustrating. (I knew gastroparesis was “common”, but have since learned that 40-50% of PWDs may experience gastroparesis or slowed digestion, and it’s flabbergasting how little is talked about in the diabetes community and how few resources are focused on coming up with new strategies and methods to help!)
  • Learning exactly what happens to digestion when you have celiac disease and get glutened.
  • Etc.

Fast forward a few months, where Todd and his post-doctoral fellow Armen Gharibans, got on a video call to discuss potentially letting me use one of their GI sensors. I still don’t know what I said to convince them to say yes, but I’m thrilled they did! Armen shipped me one of the devices, some electrodes, and a set of lipo batteries.

Here’s what the device looks like – it’s a 3D printed gray box that holds an open source circuit board with connectors to wearable electrodes. (With American chapstick and unicorn for scale, of course.)

DanaMLewis EGG for scale

And here’s what it looked like on me:

DanaMLewis wearing an ambulatory EGG

The device stores data on an SD card, so I had many flash backs to my first OpenAPS rig and how I managed to bork the SD cards pretty easily. Turns out, that’s not just a Pi thing, because I managed to bork one of my first EGG SD cards, too. Go figure!

And this device is why I went through airport security the other day with 10 electrodes on. (I disconnected the device, put it in my bag alongside my OpenAPS rigs, and they all went through the x-ray just fine, as always.)

Just like OpenAPS, this device is obviously not waterproof, and neither are the electrodes, so there are limitations to when I can wear it. Generally, I’ve been showering at night as usual, then applying a fresh set of electrodes and wearing the device after that, until the next evening when I take a shower. Right now, hard core activity (e.g. running or situps) generates too much noise in the stomach for the data to be usable during those times, so I’ve been wearing it on days when I’ve not been running and when I’ve not been traveling so Scott can help me apply and connect the right electrodes in the right places.

This device is straight from a lab, too, so like with #OpenAPS I’ve been an interesting guinea pig for the research team, and have found even low-level activity like bending over to put shoes on can trigger the device’s reset button. That means I’ve had to pay attention to “is the light still on and blinking” (which is hard since it’s on my abdomen under my shirt), so thankfully Armen just shipped me another version of the board with the reset button removed to see if that makes it less likely to reset. (Resetting is a problem because then it stops recording data, unless I notice it and hit the “start recording” button again, which drives me bonkers to have to keep looking at it periodically to see if it’s recording.) I just got the new board in the mail, so I’m excited to wear it and see if that resolves the reset problem!

Data-wise, it’s been fascinating to get a peek into my stomach activity and compare it to the data I have from OpenAPS around net insulin activity levels, dynamic carb absorption activity, expectations on what my BG *should* be doing, and what actually ended up happening BG-wise. I wore it one night after a 4 mile run followed by a big dinner, and I had ongoing digestion throughout the night, paired with increased sensitivity from the run so I needed less insulin overall despite still having plenty of digestion happening (and picture-perfect BGs that night, which I wasn’t expecting). I only have a few days worth of data, but I’m excited to wear it more and see if there are differences based on daily activity patterns, the influences of running, and the impact of different types of meals (size, makeup of meal, etc).

A huge thanks to Todd, Armen (who’s been phenomenal about getting me the translated GI data back in super fast turnaround time), and the rest of the group that developed the sensor. They just put out a press release about a publication with data from one of their GI studies, and this press release is a great read if you’re curious to learn more about the GI sensor, or this news piece. I’m excited to see what I can learn from it, and how we can potentially apply some of these learnings and maybe other non-diabetes sensors to help us potentially  improve daily diabetes management!

Vitamin D and insulin sensitivity

tl;dr – for me, Vitamin D hugely influences insulin sensitivity.

After the flu, I continued to be sick. We did the usual song and dance many people do around “hey, do you have pneumonia?”. Which, luckily, I didn’t, but I was still pretty sick and my after visit summary sheet said bronchitis. Also, my average BGs were going up, which was weird. After all, when I had the flu, I had spectacular BGs throughout. So I was pretty concerned when my time in range started dropping and my average BG started rising.

In diabetes, there are a lot of things that influence BGs. It can be a bad pump site; a bad bottle of insulin; stress; sickness; etc etc. that causes out of range BGs. Most of these are helped by having a DIY closed loop like OpenAPS. So, when your BGs start to rise above (your) normal and stay there, it’s indicative of something else going on. And because I was sick, that’s what I thought it was. But as I continued to gradually heal, I noticed something else: not only were my BG averages continuing to rise (not normal), but I also was needing a lot more insulin. Like, 20-30u more per day than usual. And that wasn’t just one day, it was 4 days of that much insulin being required. Yikes. That’s not normal, either.

So, I was thinking that I was hitting the Fiasp plateau, which made me really sad. I’ve been using Fiasp for many months now with good results. (For those of you who haven’t been tuned into the diabetes community online, while many people like Fiasp because it’s slightly faster, many people also have experienced issues with it, ranging from pump sites dying much faster than on other insulins; having issues with prolonged high BGs where “insulin acts like water”, etc.) But, I was prepared mentally to accept the plateau as the likely cause. I debated with Scott whether I should switch back to my other insulin for 2-3 sites and reservoirs to give my body a break, and try again. But I was still sick – so maybe I should wait until I was not clearing gunk out of my lungs. Or I was also pretty convinced that it was correlated with my absolute ZERO level of activity. (I had some rising BG averages briefly over Christmas where I was fearing the plateau, but turns out it was related to my inactivity, and getting more than zero steps a day resolved that.) I knew I would be moving around more the next week as I gradually felt better, so it should hopefully self-resolve. But making changes in diabetes sometimes feels like chicken and egg, with really complicated chickens and eggs – there’s a lot of variables and it’s hard to pin down a single variable that’s causing the root of the problem.

One other topic came up in our discussion – vitamin D. Scott asked me, “when was the last time you saw the sun?”. Which, because I’d been sick for weeks, and traveled for a week before that, AND because we live in Seattle and it’s winter, meant I couldn’t remember the last time I had seen the sun directly on my skin. (That sounds depressing, doesn’t it? Sheesh.)

So, I decided I would not switch back to the previous insulin I was using, and I would give it some time before I tried that, and I would focus on taking my vitamin D (because I hadn’t been taking it) and also trying to get at least SOME activity every day. I took vitamin D that night, went to bed, and….

…woke up with perfect BGs. But I didn’t hold my breath, because I was having ok nights but rough days that required the extra 30 units of insulin. But by the end of the day, I still had picture-perfect BGs (my “normal”), and I was back to using my typical average amount of insulin. PHEW. Day 2 also yielded great BG levels (for me, regardless of sickness) and around average level of insulin needed for the day time. Double phew. Day 3 is also going as expected BG and total insulin usage wise.

You might find yourself thinking, “how can it be as simple as Vitamin D? There’s probably something else going on.” I would think that – except for I have enough data to know that, when I’m vitamin D deficient, getting some vitamin D (either via pill or via natural form from sunlight) can pack a punch for insulin sensitivity. In 2014, Scott and I went out in February even when it was cold to sit in a park and get some sunshine. After about an hour of sitting and doing nothing, with no extra insulin on board, WHOOOSH. I went mega-low. I’ve had several other experiences where after being likely vitamin D deficient, and then spending an hour or so in sunlight, WHOOSH. And same for when there was no sunlight, but I took my vitamin D supplements after a while of not taking them. And no, they’re not mixed with cinnamon 😉 (That’s a diabetes joke, cinnamon does not cure diabetes. Nothing cures type 1 diabetes.)

So tl;dr – my insulin sensitivity is influenced by vitamin D, and I’ll be trying to do a better job to take my vitamin D regularly in the winters from now on!

Making changes in diabetes is hard by DanaMLewis

Quantified sickness when you have #OpenAPS and the flu

Getting “real people sick*” is the worst. And it can be terrifying when you have type 1 diabetes, and know the sickness is both likely to send your blood sugars rocketing sky high, as well as leave you exhausted and weak and that much harder to deal with a plummeting low.

*(Scott hates this term because he doesn’t like the implication that PWD’s aren’t real. We’re real, all right. But I like the phrase because it differentiates between feeling bad from blood sugar-related reasons, and the kind of sickness that anyone can get.)

In February 2014, Scott got home from a conference on Friday, and on Saturday complained about being tired with a headache. By Sunday, I started feeling weary with a sore throat. By Monday morning, I had a raging fever, chills, and the bare minimum of energy required to drag myself into the employee health clinic and get diagnosed with the flu. And since they knew I was single and lived by myself, the conversation went from “here’s your prescription for Tamiflu” to “but you can’t be by yourself, maybe we should find a bed for you in the hospital” because of how sick I was. Luckily, I called Scott and asked him to come pick me up and let me stay at his place. And there I stayed in complete misery for several days, the sickest I’d ever been. I remember at one point on the second day, waking up from a fitful doze and seeing Scott standing across the room with his laptop on a dresser, using it as a standing desk because he was so worried about me that he didn’t want to leave the room at that point. It was that bad.

Luckily, I survived. (And good thing, right, given that we went on to build OpenAPS, yes? ;)) This year’s flu experience was different. This year I was real-people sick, but without the diabetes-related fear that I’d so often experienced in the past. My blood sugars were perfectly managed by OpenAPS. I didn’t go low. It didn’t matter if I didn’t eat, or did eat (potato soup, ice cream, and frozen fruit bars were the foods of choice). My BGs stayed almost entirely in range. And because they were so in range that it was odd, I started watching the sensitivity ratio that is calculated by autosensitivity to see how my insulin sensitivity was changing over the course of the sickness. And by day 5, I finally felt good enough to share some of that data (aka, tweet). Here’s what I found from this year’s flu experience:

  • Night 1 was terrible, because I got hardly any deep sleep (45 minutes, whereas 2+h is my usual average per night) and kept waking up coughing. I also was 40% insulin resistant all night long and into Day 2, meaning it took 40% more insulin than usual to keep my BGs at target.
  • Night 2 was even worse – ZERO deep sleep. Ahhhh! It was terrible. Resistance also nudged up to 50%.
  • Night 3 – hallelujah, deep sleep returned. I ended up getting 4h53m of deep sleep, and also was able to sleep for closer to 2 hour blocks at a time, with less coughing. Also, going into night 3 was pretty much the only “high” I had of being sick – up around 180 for a few hours. Then it fell off a cliff and whooshed down to the bottom of my target, marking the drastic end of insulin resistance. After that, insulin sensitivity was fairly normal.
  • Night 4 yielded more deep sleep (>5 hours), and a tad bit of insulin sensitivity (~10%), but it’s unclear whether that’s totally sickness related or more related to the fact that I wasn’t eating much in day 3 and day 4.
  • Night 5 felt like I was going backward – 1h36m of deep sleep, tons of coughing, and interestingly a tad bit of insulin resistance (~20%) again. Night 6 (last night) I supposedly got plenty of deep sleep again (>4h), but didn’t feel like it at all due to coughing. BGs are still perfectly in range, and insulin sensitivity back to usual.

This was all done still with no-bolus, and just carb announcement when I ate whatever it was I was eating. In several cases there was negative IOB on board, but I didn’t have the usual spikes that I would normally see from that. I had 120 carbs of gluten free biscuits and gravy yesterday, and I didn’t go higher than 130mg/dl.

It’s a weird feeling to have been this sick, and have perfectly normal blood sugars. But that’s why it’s so interesting to be able to look at other data beyond average, time in range, and A1c – we now have the tools and the data to be able to dive in and really understand more about what our bodies are doing in sick situations, whether it’s norovirus or the flu.

I’m thinking if everyone shared their data from when they had the flu, or norovirus, or strep throat, or whatever – we might be able to start to analyze and detect patterns of resistance and otherwise sensitivity changes over the course of typical illness. This way, when someone gets sick with diabetes, we’d know generally “expect around XX% resistance for Days 1-3, and then expect a drop off that looks like this on Day 4”, etc.

That would be way better than the traditional ways of just bracing yourself for sky-high highs and terrible lows with no understanding or ability to make things better during illness. The peace of mind I had during the flu this year was absolutely priceless. Some people will be able to get that with DIY closed loop technology; but as with so many other things we have learned and are learning from this community, I bet we can find ways to help translate these insights to be of benefit for all people with diabetes, regardless of which therapies they have access to or decide to use.

Want to help? Been sick? Consider donating your data to my diabetes sick-day analysis project. What you should do:

  1. If you’re using a closed loop, donate your data to the OpenAPS Data Commons. You can do all your data (yay!), or just the time frame you’ve been sick. Use the “message the project owner” feature to anonymously message and share what kind of illness you had, and the dates of sickness.
  2. Not using a closed loop, but have Nightscout? Donate your data to the Nightscout Data Commons, and do the same thing: Use the “message the project owner” feature to anonymously message and share what kind of illness you had, and the dates of sickness.

As we have more people who identify batches of sick-day data, I’ll look at what insights we can find around sensitivity changes before, during, and after sickness, plus other insights we can learn from the data.

What you should know about closed looping (DIY like #OpenAPS or otherwise)

I’ve been wearing a DIY closed loop for something like 979 days..which means something like ~20,000 hours with this technology. Additionally, I’m not the only one. At the time of writing this post (see the latest count here), there are (n=1)*369+ (and that’s an undercount just based on who’s told us they’re looping) other DIYers out there, so the community has an estimated 1,800,000+ hours of cumulative experience, too.

Suffice to say, we’ve all learned a lot about this technology and how hybrid closed loop makes a difference in life with diabetes.

I previously gave a talk almost two years ago to the Sports & Diabetes Group Northwest here in Seattle, talking about #DIYPS, how we closed the loop, and #OpenAPS. (And you can see a recent TEDX talk I gave on OpenAPS here.) That was a springboard for meeting some awesome individuals who became very early DIY loopers in the Seattle area. And one of them (who also wore a pancreas at HIS wedding :)) had suggested we do another talk for SDGNW to update on some of what we have learned since then. But unfortunately, he got called out of town for work and couldn’t join me for presenting, so I went solo (ish, because Scott also came and contributed). I used a new analogy, because I think there’s a lot to think about before choosing and using closed loop technology, whether it’s DIY or commercial, and wanted to write it up for sharing here.

what_to_know_about_looping_danamlewis

First, some reminders for those familiar and some context for those who are not close to this technology. We’re talking about a hybrid closed loop, which is what I’m referring to when I say “artificial pancreas” or “AP” here. This type of technology makes small adjustments every few minutes to provide more or less insulin with the goal of keeping blood glucose (BG) levels in range. It’s complicated by the fact that insulin often peaks at 60-90 minutes…but food hits in ~15 minutes. So there’s often “catch up” being done with insulin to deal with food eaten previously, and also with hormones and other things that impact BGs that aren’t measurable. (This is also why it’s called hybrid, because for best outcomes people will still be doing some kind of meal announcement/bolus to deal with insulin timing.) As a result, even with pumps and CGMs, diabetes is still hard. A closed loop can do the needed math every five minutes, doesn’t go to sleep, and is very precise. It can respond more quickly (because it’s paying attention) than a human will in most situations, because we’re out living our lives/working/sleeping and not paying attention ONLY to diabetes. It’s not a cure, but it helps make living with diabetes better than it used to be.

However, I equate it to being a pilot who has seen technology on planes evolve to include “autopilot”. Even with hybrid closed loop technology, we’re still flying the “plane”.

looping_is_like_flying_plane_danamlewis

Here’s what I mean. There are stages for picking out and deciding to use the technology; preparing to use it/getting in the mode where you CAN use it; using it successfully; getting ready for the times when you can’t use it; and smoothing the way for the next time you use it.

It’s not perfect 24/7, you see, because we’re still using pump sites and continuous glucose monitor (CGM) sensors. The CGM sensor may last for 7 days, but then you have to change it out (or cough restart it cough), and you have a gap in data, which means you can’t loop. So you have this type of cycle regularly, and here’s what you need to know about each of these stages, regardless of whether we’re talking about DIY (like OpenAPS) or a commercial closed loop solution.

Preparing for takeoff

prepare_for_looping_danamlewisWhen you’re getting into the plane, you have a flight plan. You know when you will and won’t use the technology on board. Same for diabetes & closed looping. Make sure to think about the following for your tech of choice:

When will your loop work? When does it not? What happens if it breaks? What are your back up tools? How do you operate it: what happens if your sensor loses data, or you don’t calibrate? How does the algorithm work? What will it target your BG to be? What behaviors will you have to do (meal bolus or announcement, etc.) and how can you alter those to optimize performance? Also, what are the warning signs of failure to let you know when you need to take additional action with corrective insulin or eating carbs?

Taking off and the new technology learning curve

taking_off_learning_curve_danamlewisJust like switching from MDI pump (or even iPhone to Android and vice versa), you have a learning curve. When you go into looping or automated insulin delivery mode, you have to figure things out. You need to be able to figure out what’s happening and why it’s doing what it’s doing, so if you’re not happy with what’s happening, you can make a change. Why are you running high? Why are you running low? Knowing why it’s doing what it’s doing is critical for adjusting – either tweaking the closed loop settings, if you can, or adjusting your own behavior. Especially in the first few cycles of new tech, you’ll have a lot of learning around “I used to do things like X, but now I need to do them like Y.”

Why you might not be taking off and able to loop

blocking_takeoff_danamlewisYou also need to know why you can’t loop. There are three major categories of things that will prevent you from looping:

  1. No sensor, no looping.
  2. In some systems, wonky or missing data, no looping
  3. Communication errors between pieces of a system.

Some of these are obvious fixes (put in a new sensor if one fell out, or decide to put in a new sensor if the old one is bad), but depending on the system may involve some troubleshooting to get things going again.

Also, some of the commercial systems will kick you out of looping for various reasons (including lack of calibration), in addition to preventing you from looping in the first place without them, so knowing what these basic things are required for looping is useful to make sure you CAN automate.

Flying high: maintenance when you’re actually looping

maintenance_when_looping_danamlewisThere are some critical behaviors required for looping. (After all, when flying, there’s always a pilot present in the cockpit..right?!)

Some of these are basic behaviors you’ll be used to if you’ve been wearing a pump and CGM previously: keeping pump sites changed so the insulin works, and changing and calibrating CGM sensors.

HOWEVER – many people who “stretch” their CGM sensors find that they don’t want to stretch their sensors as far, as the data degrades over time. You do you, but keep in mind this might change when you’re looping vs. not, because you’re relying on good data to operate the system.

That being said, in addition to good sensor life, calibration hygiene is critical. You don’t want to loop off of wonky data, but also some commercial systems will kick you out if your calibration is way off and/or if you miss a calibration. (Personal opinion on this is a big ugh, which is why no DIY system that I know of does this.)

But if you keep your sites and sensors in good condition, this is where life is good. You’re looping! It’s microadjusting and helping keep things in range. Yay! This means better sleep, more time in range, and feeling better all around.

However, you still have diabetes, you’re still in the plane, so you still need to keep an eye on things. Monitoring the system is important (to make sure you’re still in autopilot and don’t need to actually fly the plane manually), so make sure you know how you (and your loved ones) can monitor the system’s operation, and know what your backup alarms are in case of system failures.

Note: there are approximately eleventy bajillion ways to remote monitor in DIY systems, but even if you have a commercial system that comes pre-baked without remote monitoring… you can add a DIY solution for that. So don’t feel like if you have a commercial AP that you can never use anything DIY – you can totally mix and match!

Dealing with turbulence

turbulence_danamlewisWhat kind of airplane/flight analogy would this be without including turbulence? :)

Like the things that can prevent looping in the first place, there are things that can throw off your looping. I already mentioned wonky sensor data that may mean either a blip in your looping time, or may kick you off looping. Again, your sensor life and your calibration practices will likely change.

But the other big disturbance, so to speak, is around body sensitivity changes. You know all the ways it can happen: you’re getting sick, recovering from getting sick, getting ready for/or are on/or are right after your period, or have an adrenaline spike, or have hormones surging, or have a growth spurt, or just exercised, etc.

This is what makes diabetes oh so hard so often. But this is where different closed loop systems can help, so this is one area you should ask about when picking a system: how does it adjust and adapt to sensitivity changes, and on what time frame? (In the DIY world, we use a number of techniques with this, ranging from autosensitivity to adapt on a 24 hour rolling scale of sensitivity changes, as well as using autotune to track bigger picture trends and changes needed to underlying settings. Reminder – anyone can use autotune if they’re willing to log bolus & carb data in Nightscout, not just closed loopers, so check that out if you’re interested! All DIY closed loop systems also use dynamic carbohydrate absorption in their respective algorithms, so that if you have slowed digestion for ANY reason, ranging from gastroparesis to getting glutened if you have celiac to merely walking after a meal, the system takes that into account and adjusts accordingly.)

The other things that can help you tough out some turbulence? Setting different modes, like an activity mode for exercise. The two things to know about exercise are:

  1. You don’t want to go into exercise with a bucket of IOB, so set activity mode WELL BEFORE you go out for activity. Depending on how much netIOB you have, that time may vary, but planning ahead with an activity mode makes a big difference for not going low during activity – even with a closed loop.
  2. Your sensitivity may be impacted for hours afterward, into the next day. See above about having a system that can respond to sensitivity changes like that, but also think about having multiple targets you can use temporarily (if your system allows it) so you can give the system a bigger buffer while it sorts out your body’s sensitivity changes.

Preparing for landing and making time between loops more smooth

prepare_for_landing_danamlewisJust like you’ll want to plan to go on the closed loop, you’ll want to plan for how to cycle off and then back on again. Depending on your system, there may be things you can do to smooth things out. One of the things I do is pre-soak a CGM sensor to skip the first day jumpy numbers. That makes a big difference for the first hours back on a “new” looping session. The other thing I do is stagger receiver start times (where I have two receivers that I stop/start at different times, so I’m not stuck for two hours without BG data to loop on).

But even if you can’t do that, you can do some other general planning ahead – like making sure your looping session doesn’t end in the middle of a big meal that’s being digested, or overnight. Those are the times when you’ll want to be looping the most.

Landing and preparing for the next looping session

Landing_danamlewisJust like learning to fly where you take a lot of training flights and review how the flight went, you’ll want to think about how things went and what you might change behavior-wise for your next looping session. Some of the things that may change over time as you learn more about your tech of choice:

  • Timing of meal announcement or boluses
  • Precision (if needed, or otherwise lack thereof) around carb counting
  • Using things like “eating soon” mode to optimize meal-time insulin effectiveness and reduce post-meal spikes
  • Using different activity patterns and targets to get ideal outcomes around exercise
  • Tweaking underlying settings (if you can)

General thoughts on looping

general_looping_reminders_danamlewisSome last thoughts about closed looping in general, regardless of the tech you might choose now or in the future:

  1. Picking one kind of technology does NOT lock you into it forever. If you’re DIYing now, you can choose commercial later. If you start on a commercial system, you can still try a DIY system.
  2. Don’t compare the original iPhone with an iPhone 6. Let’s be blunt: the Dexcom 7plus is a different beast than the Dexcom G4/G5. Similarly, Medtronic’s original “harpoon” sensor is different than their newest sensor tech. The Abbott Navigator is different than their Libre. Don’t be held up by perceptions of the old tech – make sure to check out the new stuff with a somewhat open mind.
  3. (Similarly, hopefully, in the future we’ll get to say the same about first-generation devices and algorithms. These things in commercial systems should change over time in terms of algorithm capabilities, targets, features, and usability. They certainly have in DIY – we’ve gotten smaller pancreases, algorithm improvements, all kinds of interoperability integration, etc.)
  4. All systems (both DIY and commercial) have pros and cons. They also each will have their own learning curves. Some of that learning is generalized, and will translate between systems. But again, iPhone to Android or vice versa – your cheese gets moved and there will be learning to do if you switch systems.
  5. Remember, everyone learns differently – and everyone’s diabetes is different. Figure out what works well for you, and rock it!

 

Unexpected side-effect of closed looping: Body re-calibrations

It’s fascinating how bodies adapt to changing situations.

For those of us with diabetes: do you remember the first time you took insulin after diagnosis? For me, I had been fasting for ~18 hours (because I felt so bad, and hadn’t eaten anything since dinner the night before) and drinking water, and my BG was still somehow 550+ at the endo’s office.

Water did nothing for my unquenchable thirst, but that first shot of insulin first sure did.

I still remember the vivid feeling of it being an internal liquid hydration for my body, and everything feeling SO different when it started kicking in.

In case the BG of 550+, the A1c of 14+ (don’t remember exact number), and me feeling terrible for weeks wasn’t enough, that’s one of the things that really reinforced that I have diabetes and insulin is something my body desperately needs but wasn’t getting.

Over the last ~14+ years, I’ve had a handful of times that reinforced the feeling of being dependent on this life-saving drug, and the drastic difference I feel with and without it. Usually, it’s been times where a pump site ripped out, or I was sick and high and highly resistant, and then finally stopped being as resistant and my blood sugar started responding to insulin finally after hours of being really high, and I started dropping.

But I’ve had different ways to experience this feeling lately, as a result of having live with a DIY closed loop (OpenAPS) for 2+ years – and it hasn’t involved anything drastic as a HIGH BG or equipment failure. It’s a result of my body re-calibrating to the new norm of my body being able to spend more and more time close to 100% in range, in a much tighter and lower range than I ever thought possible (especially now true with some of the flexibility and freedom oref1 now offers).

I originally had a brief fleeting thought about how BGs in the low 200s used to feel like the 300s did. Then, I realized that 180 felt “high”. One day, it was 160.

Then one day, my CGM said flat in 120s and I felt “high”. (I calibrated, and turned out that it was really 140). I’ve had several other days where I’d hit 140s and feel like I used to do in the mid-200s (slightly high, and annoying, but no major high symptoms like 300-400 would cause – just enough to feel it and be annoyed).

That was odd enough as a fleeting thought, but it was really odd to wake up one morning and without even looking at my watch or CGM to see what my BGs had been all night, know that I had been running high.

I further classified “really odd” as “completely crazy” when that “running high” meant floating around the 130-140 range, instead of down in the 90-110 range, which is where I probably spend 95% of my nights nowadays.

Last night is what triggered this blog post, plus a recurring observation that because I have a DIY closed loop that does so well at handling the small, unknown variances that cause disturbances in BG levels without me having to do much work, that as result it is MUCH easier to pinpoint major influences, like my liver dumping glucose (either because of a low or because it’s ‘full up’ and needs to get rid of the excess).

In last night’s case, it was a major liver dump of glucose.

Here’s what happened:

Scott and I went on a long walk, with the plan to stop for dinner on the way home. BG started dropping as I was about half a mile out from the restaurant, but I’m stubborn 😀 and didn’t want to eat a fruit strip when I was about to sit down an eat a burger. So, my BG was dropping low when I actually ate. I expected my BG to flatten on its own, given the pause in activity, so I bolused fairly normally for my burger, and we walked the last .5 miles home.

However, I ended up not rising from the burger like I usually do, and started dropping again. It was quite a drop, and I realize my burger digestion was different because of the previous low, so I ended up eating some fruit to handle the second low. My body was unhappy at two lows, and so my liver decided to save the day by dumping a bunch of glucose to help bring my blood sugar up. Double rebound effect, then, from the liver dump and the fruit I had eaten. Oh well, that’s what a closed loop is for!

Instead of rebounding into the high 300s (which I would have expected pre-closed loop), I maxed out at 220. The closed loop did a good job of bolusing on the way up. However, because of how much glucose my liver dumped, I stayed higher longer. (Again, this probably sounds crazy to anyone not looping, as it would have sounded to me before I began looping). I sat around 180 for the first three hours of the night, and then dropped down to ~160 for most of the rest of the night, and ended up waking up around 130.

And boy, did I know I had been high all night. I felt (and still feel, hours later) like I used to years ago when I would wake up in the 300s (or higher).

Visuals

recalibration_3 hourHmm, 3 hours doesn’t look so bad despite feeling it.

recalibration_6 hour6 hour view shows why I feel it.

recalibration_12 hour12 hours. Sheesh.

recalibration_24 hour24 hours shows you the full view of the double low and why my liver decided I needed some help. Thanks, liver, for still being able to help if I really needed it!

recalibrating_pebble view of renormalizing Settling back to normal below 120, hours later.

There are SO many amazing things about DIY closed looping. Better A1c, better average BG, better time in range, less effort, less work, less worrying, more sleep, more time living your life.

One of the benefits, though, is this bit of double-edged sword: your body also re-calibrates to the new “normal”, and that means the occasional extreme BG excursion (even if not that extreme!) may give you a different range of symptoms than you used to experience.

This. Matters. (Why I continue to work on #OpenAPS, for myself and for others)

If you give a mouse a cookie or give a patient their data, great things will happen.

First, it was louder CGM alarms and predictive alerts (#DIYPS).

Next, it was a basic hybrid closed loop artificial pancreas that we open sourced so other people could build one if they wanted to (#OpenAPS, with the oref0 basic algorithm).

Then, it was all kinds of nifty lessons learned about timing insulin activity optimally (do eating soon mode around an hour before a meal) and how to use things like IFTTT integration to squash even the tiniest (like from 100mg/dL to 140mg/dL) predictable rises.

It was also things like displays, button, widgets on the devices of my choice – ranging from being able to “text” my pancreas, to a swipe and button tap on my phone, to a button press on my watch – not to mention tinier sized pancreases that fit in or clip easily to a pocket.

Then it was autosensitivity that enabled the system to adjust to my changing circumstances (like getting a norovirus), plus autotune to make sure my baseline pump settings were where they needed to be.

And now, it’s oref1 features that enable me to make different choices at every meal depending on the social situation and what I feel like doing, while still getting good outcomes. Actually, not good outcomes. GREAT outcomes.

With oref0 and OpenAPS, I’d been getting good or really good outcomes for 2 years. But it wasn’t perfect – I wasn’t routinely getting 100% time in range with lower end of the range BG for a 24hour average. ~90% time in range was more common. (Note – this time in range is generally calculated with 80-160mg/dL. I could easily “get” higher time in range with an 80-180 mg/dL target, or a lot higher also with a 70-170mg/dL target, but 80-160mg/dL was what I was actually shooting for, so that’s what I calculate for me personally). I was fairly happy with my average BGs, but they could have been slightly better.

I wrote from a general perspective this week about being able to “choose one” thing to give up. And oref1 is a definite game changer for this.

  • It’s being able to put in a carb estimate and do a single, partial bolus, and see your BG go from 90 to peaking out at 130 mg/dL despite a large carb (and pure ballpark estimate) meal. And no later rise or drop, either.
  • It’s now seeing multiple days a week with 24 hour average BGs a full ~10 or so points lower than you’re used to regularly seeing – and multiple days in a week with full 100% time in range (for 80-160mg/dL), and otherwise being really darn close to 100% way more often than I’ve been before.

But I have to tell you – seeing is believing, even more than the numbers show.

I remember in the early days of #DIYPS and #OpenAPS, there were a lot of people saying “well, that’s you”. But it’s not just me. See Tim’s take on “changing the habits of a lifetime“. See Katie’s parent perspective on how much her interactions/interventions have lessened on a daily basis when testing SMB.

See this quote from Matthias, an early tester of oref1:

I was pretty happy with my 5.8% from a couple months of SMB, which has included the 2 worst months of eating habits in years.  It almost feels like a break from diabetes, even though I’m still checking hourly to make sure everything is connected and working etc and periodically glancing to see if I need to do anything.  So much of the burden of tight control has been lifted, and I can’t even do a decent job explaining the feeling to family.

And another note from Katie, who started testing SMB and oref1:

We used to battle 220s at this time of day (showing a picture flat at 109). Four basal rates in morning. Extra bolus while leaving house. Several text messages before second class of day would be over. Crazy amount of work [in the morning]. Now I just have to brush my teeth.

And this, too:

I don’t know if I’ve ever gone 24 hours without ANY mention of something that was because of diabetes to (my child).

Ya’ll. This stuff matters. Diabetes is SO much more than the math – it’s the countless seconds that add up and subtract from our focus on school/work/life. And diabetes is taking away this time not just from a person with diabetes, but from our parents/spouses/siblings/children/loved ones. It’s a burden, it’s stressful…and everything we can do matters for improving quality of life. It brings me to tears every time someone posts about these types of transformative experiences, because it’s yet another reminder that this work makes a real difference in the real lives of real people. (And, it’s helpful for Scott to hear this type of feedback, too – since he doesn’t have diabetes himself, it’s powerful for him to see the impact of how his code contributions and the features we’re designing and building are making a difference not just to BG outcomes.)

Thank you to everyone who keeps paying it forward to help others, and to all of you who share your stories and feedback to help and encourage us to keep making things better for everyone.