Missing metrics in diabetes measurement by @DanaMLewis

February 20, 2019 by Dana Lewis

“May I ask what your A1c is?”

This is a polite, and seemingly innocuous question. However, it’s one of my least favorite questions taken at face value. Why?

Well, this question is often a proxy for some of the following questions:

How well are *you* doing with DIY closed loop technology?
How well could *I* possibly do with DIY closed loop technology?
What’s possible to achieve in real-world life with type 1 diabetes?

But if I answered this question directly with “X.x%”, it leaves out so much crucial information. Such as:

What my BG targets are
- Because with DIY closed loop tech like OpenAPS, you can choose and set your own target.
- (That’s also one of the reasons why the 2018 OpenAPS Outcomes Study is fascinating to me, because people usually set high, conservative targets to start and then gradually lower them as they get comfortable. However, we didn’t have a way to retrospectively sleuth out targets, so those are results are even with the amalgamation of people’s targets being at any point they wanted at any time.)
What type of lifestyle I live
- I don’t consider myself to eat particularly “high” or “low” carb. (And don’t start at me about why you choose to eat X amount of carbs – you do you! and YDMV) Someone who *is* eating a lot higher or lower carb diet compared to mine, though, may have a different experience than me.
- Someone who is not doing exercise or activity may also have a different experience then me with variability in BGs. Sometimes I’m super active, climbing mountains (and falling off of them..more detail about that here) and running marathons and swimming or scuba diving, and sometimes I’m not. That activity is not so much about “being healthy”, but a point about how exercise and activity can actually make it a lot harder to manage BGs, both due to the volatility of the activity on insulin sensitivity etc.; but also because of the factor of going on/off of insulin for a period of time (because my pump is not waterproof).
What settings I have enabled in OpenAPS
- I use most of the advanced settings, such as “superMicroBoluses” (aka SMB – read more about how it works here); with a higher than default “maxSMBBasalMinutes”; and I also use all of the advanced exercise settings so that targets also nudge sensitivity in addition to autosensitivity picking up any changes after exercise and other sensitivity-change-inducing activities or events. I also get Pushover alerts to tell me if I need any carbs (and how many), if I’m dropping faster and expected to go below my target, even with zero temping all the way down.
What my behavioral choices are
- Timing of insulin matters. As I learned almost 5 years ago (wow), the impact of insulin timing compared to food *really* matters. Some people still are able to do and manage well with “pre-bolusing”. I don’t (as explained there in the previous link). But “eating soon” mode does help a lot for managing post-meal spikes (see here a quick and easy visual for how to do “eating soon”). However, I don’t do “eating soon” regularly like I used to. In part, because I’m now on a slightly-faster insulin that peaks in 45 minutes. I still get better outcomes when I do an eating-soon, sure, but behaviorally it’s less necessary.
- The other reason is because I’ve also switched to not bolusing for meals.
  - (The exceptions being if I’m not looping for some reason, such as I’m in the middle of switching CGM sensors and don’t have CGM data to loop off of.)

These settings and choices are all crucial information to understanding the X.x% of A1c.

Diabetes isn’t just the average blood glucose value. It’s not just the standard deviation or coefficient of variation or % time in range or how much BG fluctuates.

Diabetes impacts so much of our daily life and requires so much cognitive burden for us, and our loved ones. That’s part of the reasons I appreciate so much Sulka & his family being candid about how their A1C didn’t change, but the amount of work required to achieve it did (way fewer manual corrections). And ditto for Jason & the Wittmer family for sharing about the change in the number of school nurse visits before/after using OpenAPS. (See both of their stories in this post)

For me, my quality of life metric has always been first about sleep: can I sleep safely and with peace of mind at night? Yes. Then – how long can I safely sleep? (The answer: a lot. Yay!) But over time, my metrics have also evolved to consider how I can cut down (like Sulka) on the amount of work it takes to achieve my ideal outcomes, and find a happy balance there.

As I mentioned in this podcast recently, other than changing my pump site (here’s how I change mine) and soaking and swapping my CGM sensors (psst – soak your sensor!), I usually only take a few diabetes-related actions a day. They’re usually on my watch, pressing a button to either enable a temp target or entering carbs when I sit down to eat.

That’s a huge reduction in physical work, as well as amount of time spent thinking/planning/doing diabetes-related things. And when life happens – because I get the flu or the norovirus or I fall off a mountain and break my ankle – I don’t worry about diabetes any more.

So when I’m asked about A1c, my answer is not a simple “X.x%”. (And not just for the reason I’m annoyed by how much judging and shaming goes on around A1c, although that influences it, too.) I usually remind people that I first started with an “open loop” for a year, and that dropped my A1c by X%. And then I closed the loop, which reduced my A1c further. And we made OpenAPS even better over the last four years, which reduced it further. And then I completely stopped bolusing! And got less lows…and kept the same A1c.

And then I ask them what they’d really like to know. If it’s a fellow person with diabetes or a loved one, we talk about what problems they might be having or what areas they’d like to improve or what behaviors they’d like to change, if any. That’s usually way more effective than hearing “X.x%” of an A1c, and them wondering silently how to get there or what to do differently if someone wants to change things. (Or for clinicians who ask me, it turns into a discussion about choices and behaviors and tradeoffs that patients may choose to make.)

Remember, your diabetes may (and will) vary (aka, YDMV). Your lifestyle, the phase of life you’re in, your priorities, your body and health, and your choices will ALL be different than mine. That’s not bad in any way: that’s just the way it is. The behaviors I choose and the work I’m willing to do (or not do) to achieve *my* goals (and what my goals are), will be different than what you choose for yours.

And that’s therefore why A1c is not “enough” to me as a metric and something that we should compare people on, even though A1c is the “same” for everyone: because the work, time spent, behavioral tradeoffs, and goals related to it will all vary.

Presentations and poster content from @DanaMLewis at #2018ADA

June 23, 2018December 22, 2022 by Dana Lewis

As 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!

You 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.

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.

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.

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.

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

One 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).
Many 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.

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.

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.
There are also multiple other posters about DIY outcomes here at #2018ADA:
- See 983-P on learning curves in DIY AP (Crocket);
- 964-P on real-world outcomes from Korea (Choi et al);
- and 993-P on #OpenAPS outcomes in Italy (Tonolo et al).
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.
I’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.

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.

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.

As 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.

For 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).

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.

Conclusion: 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.

Not bolusing for meals (Fiasp, 0.6.0 algorithm in oref0 dev branch, and more)

September 29, 2017December 20, 2022 by Dana Lewis

I tweeted last week+, “I just realized I’ve now gone about 3 weeks without meal bolusing.” That means just a meal announcement (i.e. carb entry estimate, a la 30 carbs or 60 carbs or whatever, based on my IFTTT buttons). No manual bolus.

Highlighting 3 weeks without meal bolusing, and just doing a carb announcement, with good outcomes thanks to OpenAPS

I kind of keep waiting for the other shoe to drop, because it sounds to good to be true. I’m sure you’re skeptical reading this.

I bet she’s doing SOME bolus.

Well, she must not be eating any carbs.

She must be having worse outcomes, bad post-meal BGs, etc.

Nope, nope, and nope.

While I started testing this new set of features with partial boluses and worked my way down (see more below on the testing topic), I’m now literally doing no manual meal bolus. I start eating, and press one button on my watch for a carb estimate entry (that via IFTTT goes to Nightscout and my rig).
I eat carbs. I’ve eaten 120 grams of carbs of gluten free biscuits and gravy; 60-90 grams of pasta; dinner followed by a few gluten free cookies, etc.
More nuanced details below, but:
- My 70-180 time in range has stayed the same (93+%) compared to the versions I was testing before with manual meal boluses.
- My 70-150 and 80-160 time in ranges have decreased slightly compared to manual meal boluses, but…
- My average blood sugar has actually dropped down (as has my a1c to match).
- (So this means I’m having a few more spikes above 160, usually topping off in 160-170 whereas before my manual meal boluses would have me top off around 150, when all was well.)

Also note – no eating soon required. No early bolus or pre-bolus. Just single button press as I stick food in my mouth.

Wow.

(See where I said, waiting for the other shoe to drop?)

That’s why I waited a while to even tweet about it. Maybe it’s a fluke. Maybe it won’t work for other people. Maybe, maybe, maybe. Who knows. It’s still fairly early to tell, but as other people are beginning to test the current dev branch of oref0 with 0.6.0-related features, other people are starting to see improvements as well. (And that could be some of the many other features we are adding to 0.6.0, ranging from exponential curves for insulin activity, to allowing SMBs to do more, to carb-ratio-tuned-autosensitivity, to huge autotune improvements, etc.)

So while I don’t want to over-hype – and never do, what works for me will not work for everyone – I do want to share my cautious excitement over continuing to be able to push the envelope on algorithms and what might be possible outcome-wise for this kind of technology.

Suggesting no meal bolus means we can quit arguing about the name "artificial pancreas"

Here’s what is enabling me to be in the no-bolus zone for now well over a month, with still (to me) great outcomes worth the tradeoffs described above:

Faster insulin. Thanks to our lovely looping friends in Germany/Austria, we came back from Europe with a few vials of Fiasp to try. I was HIGHLY skeptical about this. Some of our European friends saw great results right away, others didn’t. I didn’t get great results on it at first. Some of that may be due to natural changes between insulin types and not knowing exactly how to adjust my manual bolus strategy to the faster insulin action, but until we did some code changes to allow SMB‘s to do more and added some other features to what’s now 0.6.0, I wasn’t thrilled and in fact after about two weeks of it was about to switch off of it. So that brings me to #2.
More improvements to the algorithm, which is now what will become the 0.6.0 release of oref0. There’s a whole lot of stuff packed in there. Exponential curves. Different carb absorption decay calculations. Allowing SMB to do more. Additional safety guards since we ramped SMB up.

How we started testing no-bolus approach:

I have always known that about 6u of insulin (thanks to testing dating back to my early DIYPS days, many many many moons ago) is about as much as I should bolus at any time. So, even if I ate 120 carbs, I usually did about a 6u bolus up front, and let the rig pick up the rest as needed over more hours. I started doing ~75% or something like that of boluses, based on wherever I felt like rounding to with my easy bolus buttons.
Whether I did 75% or 100%, I didn’t see a ton of difference at first…
..so I took a leap and tried no-bolus with some SMB adjustments to allow it to ramp up faster with carb entry. Behaviorally, I find it a lot easier to do nothing 😀 vs. figure out the right amount of up front bolus. And outcomes wise (see above) it was very similar.

It definitely was an interesting approach to test. Between the Fiasp and the no-bolus up front, in some meals it matched really well and I had practically no rise. Due to incoming netIOB, food type, etc, sometimes I did have a rise – but while it spiked slightly higher (160-170 usually vs my earlier 150s with manual bolus), it was only up there for 2-3 data points and then came sharply down, leveling out smoothly in my preferred post-meal range. So an important lesson I learned was not to over-react to just the BG curve going up, without looking at the predictions to see where I was going to come just back down. (And as I had more than one meal where the spike and drop back to normal happened, it was very easy to adjust to the BG graph and not get that emotional tug to “do more” with a quick short rise like that).

Obviously, starting BG makes a difference. I’m usually starting <130 mg/dL when I see these spikes cap out at 170 or lower. I’ve started higher, and seen higher rises, too. They’re not all perfect: with occasional pump site issues, carb underestimates, unplanned carb stacking, and all the randomness of diabetes and a non-structured lifestyle (including live-testing bleeding edge algorithm changes), I’ve spent 12% of the last month >160 mg/dL, which is about the same as the 3 months before that. But in most cases (I’d say 95%), the no-bolus approach has actually yielded better outcomes than I expected AND has avoided post-meal lows better than I would have achieved with a manual bolus.

This is huge when you think about the QOL aspect of not having to do as much math at a meal; and when you think about all the complicating factors related to food – timing (do you bolus when you order, or when the food arrives, or earlier than that?), and the gluten factor. I have celiac disease, so if I’m eating out (which we do a lot, and especially since I travel frequently), bolusing prior to setting eyes on the food (knowing they didn’t plate it with bread, causing them to have to go back and start all over again) just isn’t smart. That’s why eating soon historically worked so well for me vs. traditional pre-boluses, because I could set the target entering the restaurant, bolus when I laid eyes on my hopefully safe food, and get reasonable (150 topping out) meal outcomes.

It also worked really well in the case where a restaurant cooked my gluten free pasta in the same pasta cooker and water as regular pasta, but didn’t inform me until after I found stray gluten noodles in the bottom of my pasta dish and started asking how that was possible since they (used to) do gluten free well. (Now, I pick up heaps of pasta, and sort pasta noodles one by one to make sure they all match before ever eating gluten free pasta. It makes waiters look at you very worriedly as you wave pasta around in the air, but better safe than glutened (again).) So, I was majorly glutened, and my digestion system was all out of sorts (isn’t that a nice polite way to describe getting glutened?) for many days, which of course impacted BG and insulin right then and for the days afterward. But because I had done carb entry and no-bolus, I was able to edit the carb entry down, and I didn’t have that much insulin stacked, and didn’t end up low after glutening, which is usually what happens.

Is that a super regular situation for most people? No. But it was super nice. And also helped me face pasta again last night, so I could put in a (very low in case of gluten) carb estimate, match my noodles, eat pasta, and let the SMBs ramp up to match absorption. It works very well for me.

Example BG graph from only announcing, not bolusing for, a meal with OpenAPS

Whether you have celiac or not, for many reasons (insert yours here), it’s nice to not to have to commit to the bolus up front. It’s closer to approaching what I think non-PWDs do at mealtimes: just eat.

(I haven’t done much testing (yet? TBD) for no-carb-entry and no-meal-bolus scenario, I expect I would have higher spikes but would be interesting to see if it would still come down reasonably fast. Probably wouldn’t be my go-to strategy because I don’t mind a general meal size estimate one button push, but would be nice to know what that curve shape would look like. If I test that, it’ll start with small snacks and ramp my way up.)

The questions I always get:

Q: HOW DO I GET THIS?
A: Caution: like all things OpenAPS but especially always true for the development branch, 0.6.0 is NOT released yet to master and is still highly experimental. I wouldn’t install dev unless you want to pay lots of close attention to it, and are willing to update multiple times over the course of the week, because Scott and I are merging features and tweaks almost daily to it.

Got the disclaimers down? Ok. It’s in the dev branch of oref0. You should read this PR with notes on some more detail of what’s included, but you should also review the code diff to see all that’s changed, because it’s not all documented yet. Also, follow the instructions at the bottom to be able to install it without git. Hop into Gitter if you have questions about it!

(Big huge thanks to folks like Tim and Matthias for early testing of 0.6.0; and to Tim for writing up about the initial rounds of 0.6.0-dev here (note that we’ve made further changes since this post), and others who’ve been testing & providing feedback and input into the dev branch!)
Q: When will this get “released” to master?
A: It depends. This is still a highly active dev branch, and we’re making a lot of changes and tweaking and testing things. The more people who test now and provide feedback will enable us to get to the final “prepare for release” testing stage. Lots and lots of testing, and things depend on how much existing needs tweaked, and what else we decide should go with this release. So, there’s never any specific release date.
Q: What is Fiasp?
A: Faster acting insulin that was only approved in Europe and Canada…until today. Convenient timing. I asked a PR person who messaged me about it, and they said it’s estimated to be available in U.S. pharmacies by late December/earlier Q1. As previously stated, available elsewhere in other parts of the world.

Fiasp peaks sooner (say, ~45 minutes) with the same tail as everything else. It’s not instantaneous. For your million and one questions about whether it’s approved for your use in a tree, on a plane, at the zoo, and all other extrapolations – please ask Google/your doctor/the manufacturer, and not me. I don’t know.
Q: Will any of this work for people NOT on Fiasp?
A: Nothing is guaranteed (even for other people on Fiasp), but the folks who’ve started testing 0.6.0 even without Fiasp (on Humalog or Novolog/Novorapid, etc.) have been happier on it vs. earlier versions, too.

I don’t expect Fiasp to work super well forever for me, given what I’ve heard from other people with months of experience on it…and given my first two weeks of Fiasp not being spectacular, I want people to not expect miracles. (Sorry, this blog post does not promise miracles, so sorry if you got super excited at the above. No miracles! This is not a cure! We still have diabetes!) Like all things artificial pancreas, I think it’s better to be cautiously hopeful with realistic expectations that things *might* be a little bit better than before, but as always, YDMV (your diabetes may/will always vary), your body will vary, and life happens, etc. so who knows.

Just 4 months ago, we published a blog post pointing out that the new features had allowed us to achieve 4 out of 5 of: no bolus; not counting carbs, medium/high carb meals, 80%+ time in range; and no hypoglycemia. With Fiasp and 0.6.0 (currently what’s in the dev branch), we’ve now achieved all 5 simultaneously: I can eat large high-carb meals, enter very vague guesstimates of 60 or 90 carbs (no need for actual carb counting, just general size-based meal announcement), and still achieve 80%+ time in range 70-150 mg/dL without ever going <55 mg/dL. Does that mean that OpenAPS with Fiasp finally meets the definition of a “real” Artificial Pancreas (step 5 on JDRF’s 6-step AP development pathway)? We think it does.

So, tl;dr (because long post is long): with Fiasp and 0.6.0-dev branch, I’m able to not bolus for meals, and just enter a very generally sized meal estimate. It’s working well for me, and like all things, we’re working to make it available to other people via OpenAPS for others who want to try similar features/approaches. It may not work well for everyone. If it helps one other person, though, like everything else it’ll be worth it. Big thanks to Scott for LOTS of development in 0.6.0 and partnership in design of these features; too many people to name for testing and providing feedback and helping iterate on these features; and to the entire community for being awesome and helping us to continue to push the envelope on what might be possible for those of us with type 1 diabetes.

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

May 11, 2017 by Dana Lewis

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.

Choose One: What would you give up if you could? (With #OpenAPS, maybe you can – oref1 includes unannounced meals or “UAM”)

May 8, 2017 by Dana Lewis

What do you have to do today (related to daily insulin dosing for diabetes) that you’d like to give up if you could? Counting carbs? Bolusing? Or what about outcomes – what if you could give up going low after a meal? Or reduce the amount that you spike?

How many of these 5 things do you think are possible to achieve together?

No need to bolus
No need to count carbs
Medium/high carb meals
80%+ time in range
no hypoglycemia

How many can you manage with your current therapy and tools of choice? How many do you think will be possible with hybrid closed loop systems? Please think about (and maybe even write down) your answers before reading further to get our perspective.

—

With just pump and CGM, it’s possible to get good time in range with proper boluses, counting carbs, and eating relatively low-carb (or getting lucky/spending a lot of time learning how to time your insulin with regular meals). Even with all that, some people still go low/have hypoglycemia. So, let’s call that a 2 (out of 5) that can be achieved simultaneously.

With a first-generation hybrid closed loop system like the original OpenAPS oref0 algorithm, it’s possible to get good time in range overnight, but achieve that for meal times would still require bolusing properly and counting carbs. But with the perfect night-time BGs, it’s possible to achieve no-hypoglycemia and 80% time in range with medium carb meals (and high-carb meals with Eating Soon mode etc.). So, let’s call that a 3 (out of 5).

With some of the advanced features we added to OpenAPS with oref0 (like advanced meal assist or “AMA” as we call it), it became a lot easier to achieve a 3 with less bolusing and less need to precisely count carbs. It also deals better with high-carb meals, and gives the user even more flexibility. So, let’s call that a 3.5.

A few months ago, when we began discussing how to further improve daily outcomes, we also began to discuss the idea of how to better deal with unannounced meals. This means when someone eats and boluses, but doesn’t enter carbs. (Or in some cases: eats, doesn’t enter carbs, and doesn’t even bolus). How do we design to better help in that safety, all while sticking to our safety principles and dosing safely?

I came up with this idea of “floating carbs” as a way to design a solution for this behavior. Essentially, we’ve learned that if BG spikes at a certain rate, it’s often related to carbs. We observed that AMA can appropriately respond to such a rise, while not dosing extra insulin if BG is not rising. Which prompted the question: what if we had a “floating” amount of carbs hanging out there, and it could be decayed and dosed upon with AMA if that rise in BG was detected? That led us to build in support for unannounced meals, or “UAM”. (But you’ll probably see us still talk about “floating carbs” some, too, because that was the original way we were thinking about solving the UAM problem.) This is where the suite of tools that make up oref1 came from. In addition to UAM, we also introduced supermicroboluses, or SMB for short. (For more background info about oref1 and SMB, read here.)

So with OpenAPS oref1 with SMB and floating carbs for UAM, we are finally at the point to achieve a solid 4 out of 5. And not just a single set of 4, but any 4 of the 5 (except we’d prefer you don’t choose hypoglycemia, of course):

With a low-carb meal, no-hypoglycemia and 80+% time in range is achievable without bolusing or counting carbs (with just an Eating Soon mode that triggers SMB).
With a regular meal, the user can either bolus for it (triggering floating carb UAM with SMB) or enter a rough carb count / meal announcement (triggering Eating Now SMB) and achieve 80% time in range.
If the user chooses to eat a regular meal and not bolus or enter a carb count (just an Eating Soon mode), the BG results won’t be as good, but oref1 will still handle it gracefully and bring BG back down without causing any hypoglycemia or extended hyperglycemia.

That is huge progress, of course. And we think that might be about as good as it’s possible to do with current-generation insulin-only pump therapy. To do better, we’d either need an APS that can dose glucagon and be configured for tight targets, or much faster insulin. The dual-hormone systems currently in development are targeting an average BG of 140, or an A1c of 6.5, which likely means >20% of time spent > 160mg/dL. And to achieve that, they do require meal announcements of the small/medium/large variety, similar to what oref1 needs. Fiasp is promising on the faster-insulin front, and might allow us to develop a future version of oref1 that could deal with completely unannounced and un-bolused meals, but it’s probably not fast enough to achieve 80% time in range on a high-carb diet without some sort of meal announcement or boluses.

But 4 out of 5 isn’t bad, especially when you get to pick which 4, and can pick differently for every meal.

Does that make OpenAPS a “real” artificial pancreas? Is it a hybrid closed loop artificial insulin delivery system? Do we care what it’s called? For Scott and me; the answer is no: instead of focusing on what it’s called, let’s focus on how different tools and techniques work, and what we can do to continue to improve them.

Picture this: How to do “eating soon” mode

July 11, 2016July 11, 2016 by Dana Lewis

How do you prevent or limit meal spikes? It doesn’t take a closed loop artificial pancreas; it takes an understanding of insulin timing and the impact on your body.

I’ve written before about why getting insulin going in your body before meal carbs kick in is so important. You can read that really long post here. And I’ve written a slightly shorter post explaining how to do “eating soon mode” to achieve insulin activity peaking when you eat, without causing lows. But recently, I quickly scratched together an illustration to show the difference in the timing and outcomes between the “eating soon mode” approach compared to a traditional “pre-bolus” approach, and after receiving feedback that these images were helpful, decided to post them here.

(Again, for more context, read this post on how to calculate your eating soon amount; and this post for more of the science behind it and how we discovered this method 2+ (!) years ago. And as always, your diabetes may vary; I’m not a doctor; etc. but this is something that when applied consistently smooths out meal spikes, even when eating high fat or high protein or high carb or any kind of meal.)

What often happens with a pre-bolus of the meal insulin 15 minutes before a meal

The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with "eating soon" mode approach — The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with “eating soon” mode approach.

*Note – the calculation of (TargetBG-80)/ISF is assuming that you have already corrected to your normal target, i.e. 100 or 120.

The power of visualizing your data, your way

November 6, 2015December 20, 2022 by Dana Lewis

Sometimes, it’s the little things that make a big difference – even little glimpses of data, or little improvements to ways that you can control the way you access and view your data (and generate alarms).

For example, I recently had a conversation with a few people in the #WeAreNotWaiting community about the different watch faces that exist for displaying CGM data; and about how much I like my #DIYPS watch face. A few reasons why:

It’s a little more discreet than some watch faces showing BG data, so the average person won’t glance at my watch and see a large number.
It pulls from the #DIYPS interface, so I can see what I’m predicted to be, and any current recommendations (such as carbs, temp basal, or bolus needed).

DIYPS watchface showing Dana M. Lewis's OpenAPS data

It’s data-heavy, but I like having all this information without having to pull my CGM out and run calculations in my head; or pull out my phone and pull up a web page to #DIYPS; etc.

One of the many cool things about the #WeAreNotWaiting community is how together we have learned and created so many new ways to visualize our data, on various devices (tablets, phones, smart watches) and various size screens. And so when I hear that someone’s not wanting a smart watch, or isn’t using it for diabetes related things, sometimes I think it’s a matter of them finding the right tools to build their own display that works for them. Several times a week I hear about various people working on new, interesting DIY diabetes projects, and it’s awesome that we have tech to improve the tools we have – and excellent social media channels to communicate about these projects.

Related to that, I wanted to share an update – recently Milos, Jason, and others have done some really amazing work to visualize basal rates in Nightscout. (If you use Nightscout, you can get this in the 0.8.2 release – see here for more details.) This means it also can pull in temporary basal rates that are used in #OpenAPS, so you can get a nice visual showing the adjusted basal rate compared to normal scheduled basal rates – and see why it might be needed – on top of display of BG data and everything else that Nightscout offers.

Showing a fake drop in CGM glucose data that is a compression drop

In this example, it also shows how OpenAPS deals with compression drops, or how it might react to other flukey data. Remember, we designed OpenAPS to only enact 30 minute temporary basal rates in a way that is the safest possible thing to do, even if it loses communication. But if it keeps communication, and the system sees a drop and a return to the normal pattern from before (see visual), it can counteract a low temp with higher temp, or vice versa.

The visualization of temp basals in Nightscout (another example here) is an excellent improvement over how I previously used to check and see what OpenAPS had been doing. I have a watchface (similar to the above #DIYPS one) that shows me what the loop is doing currently, but when I wake up in the morning, I was mostly using a basic screen like the below to see the positive, negative, and net temp basal rates on an hourly basis and comparing that to my CGM graph to get an understanding of what happened.

Less insulin needed and OpenAPS reduced accordingly

Visualizing basal rates in Nightscout is a seemingly minor change, but every time we make a change like this that allows me to contextualize all of my data in one place (on a single glanceable watchface; or on the Nightscout screen); it saves a few seconds or minutes that add up to a lot of time saved every day, week, month, and additional year that I’m dealing with diabetes – a big win.

How to do “eating soon” mode – #DIYPS lessons learned

March 26, 2015December 22, 2022 by Dana Lewis

“Do you prebolus for meals with #DIYPS?”

The answer to this question is complicated for me. I don’t “prebolus” like most people do (meaning “take some or all of your meal insulin about 15 minutes before you eat”).

I do take insulin before a meal. In fact, I do it up to an hour before the meal starts, by setting my correction target BG from it’s usual range (usually 100-120) to 80. This usually means I’m usually doing anywhere from .5-1u or more of insulin prior to a meal. But the amount of insulin has no direct relationship with the total amount of carbs I’ll end up eating during the meal.

Does it work? Yes. Do I go low? No, because it is unlikely that I would get anywhere near 80 by the time my carbs kick in for a meal (15 minutes after I eat), and therefore the initial carbs are handled by that initial amount of insulin from the eating soon-bolus. (Last year, I wrote a post about “eating soon mode” under the guise of lessons learned about meal time with #DIYPS – if you want to read the reason behind WHY eating soon mode is key in more detail, you can definitely read the longer version of the post. It also links another key concept I’ve learned about called carbohydrate absorption rate.)

So, how can you manually do “eating soon” mode?

1. If you know you’re going to eat anywhere in the next hour, manually calculate a correction bolus with a target BG of 80. (Example – if your correction ratio is 1:40, and you are currently 120, that means you would give yourself 1u of insulin.) An hour, 45 minutes, 30 minutes – whatever you make work is better than not doing it!

2. Eat your meal and bolus normally, but use your IOB as part of your meal calculation so you don’t forget about that insulin you already have going. (Helpful if your pump tracks IOB and you use a bolus calculator feature, but if you take injections, keep in mind about the insulin you’ve already given for the meal – just subtract that amount (1u in above example) from what you’d otherwise inject for the meal.

Note: if you use eating soon mode, you might want to delay the last unit or two of your meal insulin until after you see BGs rise, since sometimes you need less total insulin for the meal if you get insulin active early. (Often, we PWDs may overcompensate with more insulin than we need because it’s not timed correctly compared to the carb absorption rate.)

Example:

5pm – You’re planning to eat around 5:30 or 6pm. Your BG is 120 and your correction ratio is 1:40. Setting your correction target to 80, that means you take 1u of insulin.

6pm – You sit down to eat. Looking at your meal, you see 45 carbs and decide, with a carb ratio of 1:10, that you would take 4.5 units for the meal. Keeping in mind your earlier bolus of 1u, you end up taking 3.5 units for the meal. (4.5 total – 1u prebolus = 3.5 more units needed to cover the meal, see above note about considering delaying a unit or two of that bolus until you see your BGs impacted by carbs).

Result? You should have less of a spike from your carbs kicking in 15 minutes after you eat. It won’t always completely eliminate a spike, but it will provide a flattening effect. This is part of how I’m able to eat large (like 120g of gluten free pizza) meals and have flat or mostly flat BGs, and this is also one of the reasons I think using #DIYPS has dramatically improved my eAG and a1cs.

—

(See another post, with illustrations, about doing eating soon mode here.)

“Letting go of things we can’t control” + remembering that sleep matters (#DIYPS)

July 25, 2014October 20, 2016 by Dana Lewis

Sleep + so many factors out of our control impacts BGs. (#DIYPS lessons learned from @danamlewis after #RagnarNWP): http://bit.ly/1AgTN4M

—

It’s been over a month since our last #DIYPS update. We haven’t made any significant changes in the system, and have been continuing to use it to successfully manage my BGs to (mostly) my satisfaction.

That is, until this past weekend.

There was a team of 12 people with diabetes that got together (thanks @ConnecT1D and @IN_events for sponsoring!) to run “Ragnar Northwest Passage”, which is a 196 mile long relay race from near the Canadian border (Blaine, Washington) to Langley, Washington.

Guess who was lucky runner #1 and woke up at 3am on Friday to run 6.3 miles at 6:15 am?

Here’s how the relay works: you have two vans, each with 6 runners, that take turns on the course. Each runner runs three different times, for a total of 13-19 miles. Van 1 starts and the 6 runners hand off to each other; then Van 2 meets up as the 6th runner finishes, and runners 7-12 commence running. Meet up again and handoff back to Van 1. (I’d say “rinse and repeat”, except for there weren’t always showers involved after every single run). The race started for our team on Friday at 6:15 am (see note about 3am wakeup and running first), and continued until Saturday at 4pm-ish.

Why this became a #DIYPS post

I slept ~4 hours on Thursday night before the 3am wake up and early race start. During the actual race, I got about 3.5 hours of sleep overnight in Van 1 while Van 2 was out on the course. Normally I would have 16-20 hours of sleep under my belt for a half-marathon or longer race.

I also didn’t have #DIYPS running at full capacity during the race – my Moto G phone has taken some hard knocks and the cord that connects to my CGM was wonky. So, I pretty much went “old school” and just used my CGMs as-is.

During the race, even without #DIYPS running normally, my BGs were pretty good. I was great during my first run and only had a few lows in the afternoon after that (more from lack of protein/real food than anything else, which I fixed with a big lunch). During my 2nd run, I started my temp basal too soon, miscalculating when the runner before me was coming in, and was between 180-200 during my run. Not *that* big of a deal, but since my average BG is usually <120, I can feel it and it feels different to run. I managed to get it down after my run and in the overnight, and was fine during my 3rd run, and after that. All in all, I was very happy with my BGs during the race. (Oh – and my first run (6.3 miles) and my last run (3.1 miles) were both PRs, personal records, for me! So, yay for good running and good BGs at the same time.)

(Scott & I after the race! We look great on so little sleep and so many miles, right?)

However, once I finished the race and Scott and I headed out for dinner (real food!), despite the usual #DIYPS prebolus strategies, my BGs rocketed up pretty fast. I chalked it up to something related to my liver absorbing or dumping glucose or whatever, didn’t worry about it too much, and focused more on getting 12 hours of sleep that night. (Luckily I was running higher and not lower, so sleeping through a few alarms was ok for the night).

On Sunday, the same thing happened when I ate lunch. A few carbs and my BGs took off high. Same thing Sunday for dinner, and Monday after a breakfast that included carbs.

By Monday evening, I was puzzled and annoyed, because I had #DIYPS running but my body was not cooperating! I was also still feeling tired, above and beyond what Scott (who ran Ragnar on another team that had 12 members with functioning pancreases ) seemed to be feeling.

Remembering that sleep matters A LOT to your body, and the same goes for managing BGs

Overnight, my BGs settled down and were flat after 6am and all morning, including after a breakfast with lots of carbs (I ate a gluten-free cookie, it was delicious). My BGs had a slight uptick..and flattened out. Like they used to do last week and all the weeks prior with #DIYPS. I took a picture to send to Scott, and had the sudden realization that my body had probably caught up on sleep to it’s minimum levels, and that’s probably why it was handling things like “normal” again*.

This (knowing that sleep impacts your body’s function) is a lesson I’ve learned many times before, and has less to do with #DIYPS….except it helped remind me that there are SO many factors out of our control in dealing with diabetes. (Stressed? Excited? Sick? Sleep deprived? Are you a girl? Are you growing? Are you in puberty? Is the moon out? Is there a universal Diet Coke shortage?)

#DIYPS is great at helping you deal with BGs if you don’t know the exact carb count in a meal, or dealing with the chaos of running more than a half marathon over three legs in a 36 hour time period on less than 8 hours of sleep. Like I mentioned before, it also helps me keep perspective – this time to help me let the few days of higher than normal post-race BGs go and not beat myself up about it.

Final note

It’s probably a good idea to not try this kind of sleep deprivation at home (seriously – sleep is awesome, you should do as much of it as possible), and be aware that running Ragnar or another relay race** may throw off your BGs more so from lack of sleep than the actual exercise part.

—
*Yes, it’s normal to eat a gluten-free cookie for breakfast! The non-normal part is having to do math and bolus and watch BGs. Having diabetes is not normal!
**Scott and I are running on a Hood to Coast team in August. Gulp. Maybe I’ll manage more sleep this time around in the vans?

#DIYPS findings can help people with type 1 diabetes, regardless of tech, better manage post-meal blood glucose

May 14, 2014July 21, 2016 by Scott Leibrand

Over the past few months, while developing #DIYPS, we have discovered a few things about mealtime blood glucose (BG) levels that we thought would be worth sharing more broadly. Using the insights, tips, and techniques below, it should be possible for many people with type 1 diabetes to more effectively keep their post-meal (post-prandial) BG levels in range. Here’s what we’ve learned…

After an initial carb absorption delay…

When carbohydrates are consumed, as part of a meal or snack, or to correct a low-blood-glucose (BG) situation, it causes BG to rise, but that rise is both delayed and gradual. In developing #DIYPS’s model, we discovered that for n=1, there is a delay of approximately 15 minutes between carb consumption and when BG starts to rise (as measured by a Dexcom G4 CGM, which actually measures subcutaneous interstitial-fluid glucose levels).

Subsequent carb absorption rate is constant…

In addition, we discovered that the rate at which BG rises after carb consumption is fairly constant, both across food types and over time. For n=1, we observed that carbohydrates are digested and absorbed at a rate of approximately 30g/hour (0.5g/minute), and that this rate is relatively constant beginning after the initial 15-minute lag, and lasting until the last of the carbs are absorbed (up to 4 hours later, in the case of a large 120-carb meal).

Regardless of glycemic index…

We also observed that, for real-world meals, glycemic index (GI) doesn’t matter much for carb absorption rate. Our initial testing was performed on high-GI foods used to correct low BG (juice and Mountain Dew) and a milkshake consumed without corrective insulin while participating in an unrelated clinical trial (to try to detect any endogenous insulin production, which was not present). However, in subsequent real-world use of #DIYPS, we’ve observed the same for almost all meal types. It seems that for meals containing at least some sugar, starch, or other highly accessible form of carbohydrates, the body seems to begin digesting and absorbing the most accessible carbs immediately, and is able to break down low-glycemic-index carbohydrates by the time the higher-GI foods are absorbed.

Additionally, insulin activity at mealtime matters a lot…

While developing and testing #DIYPS (and working to bring A1c down a full percentage point), we also observed that the level of insulin activity at the start of a meal matters a great deal in determining whether BG rises significantly as the meal carbs are absorbed by the body.

Pre-boluses can help…

One fairly common technique for dealing with this, among people with type 1 diabetes, is the pre-bolus. This generally means estimating insulin requirements for an upcoming meal, and bolusing or injecting fast-acting insulin approximately 15 minutes before the meal. Such pre-boluses do help somewhat in preventing large spikes in BG immediately after meals, but in our experience an 80-point BG rise (from 80mg/dl to 160mg/dl, for example) is still common for meals consumed “on an empty stomach” with little or no extra insulin on board (IOB) prior to the pre-bolus.

But pre-bolusing can sometimes be dangerous…

Also, pre-bolusing can contribute to dangerously low BG (hypoglycemia) if a meal is delayed or if you end up eating fewer carbs than expected.

And what really matters is not IOB, but insulin activity…

Based on observing the differences in post-meal (post-prandial) BG between empty-stomach meals and those where insulin was already on board and at full activity from small snacks or correction boluses 1-2h prior to the meal[1], it appears that what actually makes the most difference for post-meal BG is not how much insulin is on board (IOB) at the start of meal time, but rather how much insulin has already been absorbed into the bloodstream and is at full activity.

Because the liver needs insulin when the carbs first hit…

When carbohydrates are initially absorbed by the small intestine, they are directed into the portal vein and pass through the liver before reaching the rest of the body’s circulatory system. The liver is designed to absorb any excess glucose out of the blood at that point, storing it for later release. The mechanism by which the liver does so is dependent on two factors: the presence of higher glucose levels in the portal vein than in general circulation (indicative of ongoing carb absorption), and the presence of sufficient active insulin. If enough insulin is fully active, the liver can absorb ingested carbs just as fast as they can be absorbed from the intestine. If not, then the glucose passes through the liver into general circulation, and cannot be subsequently absorbed by this mechanism, but must be absorbed later by peripheral tissues once insulin levels get high enough.

And a 15m pre-bolus doesn’t get insulin active fast enough…

Even fast-acting insulin does not reach peak activity for 60-90 minutes after injection, since it must be absorbed through subcutaneous tissue into the bloodstream. This means that, if no insulin is on board from previous boluses, the pre-bolus insulin doesn’t really kick in for 30 minutes or more after the start of the meal. In the time it takes pre-bolus insulin to kick in, the body might absorb 15-20g of carbohydrates, resulting in a 60-80 mg/dl rise in BG.

So, some insulin is needed sooner…

So we need to get enough insulin active at mealtime to allow the liver to do its job, but not so much as to cause low BG before or after the meal. The best way we’ve found to do this is to do a small early pre-bolus about an hour prior to a meal. We calculate the size of the early pre-bolus based on the current BG, by determining how much insulin we can safely add and still stay above 80 mg/dl for 1-2 hours. In our case, that means assuming that up to 75% of the insulin activity will occur before the meal carbs kick in. So for a BG of 110 mg/dl an hour prior to the meal, and a correction ratio of 40 mg/dl per unit of insulin, it would be safe to bolus 1 unit of insulin. That 1 U then ramps up to peak activity right at mealtime, and largely prevents any substantial rise in BG immediately after the meal.

Finally, we can time mealtime insulin based on carb absorption…

Once we’re almost ready to eat and it’s time for a normal pre-bolus, it’s important not to over-bolus for all our carbs all at once. Doing so (particularly after a successful early pre-bolus for a large meal) risks causing post-meal low BG, as insulin activity can peak before all the meal carbs can be absorbed. For example, a large meal with 90g of carbohydrates would take 3 hours to absorb, but insulin activity often peaks after 60-90 minutes. So what we have developed and incorporated into #DIYPS is a relatively simple meal-bolus algorithm that dramatically reduces high- and low-BG situations after meals. The most important feature of this algorithm can be implemented manually without #DIYPS, either via multiple boluses or via a combo/dual/“square wave” bolus. The key idea is to bolus only for those carbs that will be absorbed by the time the insulin hits peak activity. So if you have a large meal, you might decide to bolus at mealtime for only the first 30g of carbs initially (minus any prebolus), since those will be absorbed over the first 60 minutes. If the meal totals 60g of carbs, you will then want to bolus for the next 30g of carbs over the next hour, possibly via a continual delayed (“square wave”) bolus, or by doing one or more manual bolus(es) after the meal is over. (The latter strategy is similar to what #DIYPS does, in 0.5U increments, as it allows you to react if you eat more or fewer carbs than expected, or if BG rises or falls unexpectedly in the interim.)

Resulting in almost flat BG, even after large meals…

By combining all these strategies, and providing real-time feedback and alerts when boluses, temp basals, or carbs are necessary, #DIYPS has allowed us to largely eliminate post-meal hyperglycemia, while minimizing risk of hypoglycemia. As detailed previously, this has helped reduce A1c by a full percentage point, reduce BG standard deviation, and increase time in range. While such impressive results are hard to achieve without assistance, it definitely should be possible for many people with diabetes to improve their own ability to manage post-meal BG levels by adopting some of the same techniques into their own self-care.

Note: there have been some updated posts since this original post about how to easily do the “eating soon” mode approach. Take a look at these illustrations for more details on it!

Footnote

[1] A few weeks ago, we were enjoying a weekend down in Portland. Normally, Dana eats a fairly low-carb breakfast, small snacks throughout the day as needed, and ends up with a fair bit of insulin activity at lunch and dinner time. That weekend, however, we had two very large spikes in postprandial blood glucose, after a late brunch, and then again after dinner, following a hike at Multnomah Falls. The next day, we saw a much smaller post-meal rise after brunch, as she had corrected a morning low with juice, and then bolused to prevent a rebound, so that insulin was near full activity at brunch time. Subsequently, we have incorporated these insights into #DIYPS’s “eating soon” mode, and have been able to much more consistently prevent large BG spikes immediately after meals.

DIYPS.org

#WeAreNotWaiting to make the world a better place

prebolus