Understanding the Difference Between Open Source and DIY in Diabetes

There’s been a lot of excitement (yay!) about the results of the CREATE trial being published in NEJM, followed by the presentation of the continuation results at EASD. This has generated a lot of blog posts, news articles, and discussion about what was studied and what the implications are.

One area that I’ve noticed is frequently misunderstood is how “open source” and “DIY” are different.

Open source means that the source code is openly available to view. There are different licenses with open source; most allow you to also take and reuse and modify the code however you like. Some “copy-left” licenses commercial entities to open-source any software they build using such code. Most companies can and do use open source code, too, although in healthcare most algorithms and other code related to FDA-regulated activity is proprietary. Most open source licenses allow free individual use.

For example, OpenAPS is open source. You can find the core code of the algorithm here, hosted on Github, and read every line of code. You can take it, copy it, use it as-is or modify it however you like, because the MIT license we put on the code says you can!

As an individual, you can choose to use the open source code to “DIY” (do-it-yourself) an automated insulin delivery system. You’re DIY-ing, meaning you’re building it yourself rather than buying it or a service from a company.

In other words, you can DIY with open source. But open source and DIY are not the same thing!

Open source can and is usually is used commercially in most industries. In healthcare and in diabetes specifically, there are only a few examples of this. For OpenAPS, as you can read in our plain language reference design, we wanted companies to use our code as well as individuals (who would DIY with it). There’s at least one commercial company now using ideas from the OpenAPS codebase and our safety design as a safety layer against their ML algorithm, to make sure that the insulin dosing decisions are checked against our safety design. How cool!

However, they’re a company, and they have wrapped up their combination of proprietary software and the open source software they have implemented, gotten a CE mark (European equivalent of FDA approval), and commercialized and sold their AID product to people with diabetes in Europe. So, those customers/users/people with diabetes are benefitting from open source, although they are not DIY-ing their AID.

Outside of healthcare, open source is used far more pervasively. Have you ever used Zoom? Zoom uses open source; you then use Zoom, although not in a DIY way. Same with Firefox, the browser. Ever heard of Adobe? They use open source. Facebook. Google. IBM. Intel. LinkedIn. Microsoft. Netflix. Oracle. Samsung. Twitter. Nearly every product or service you use is built with, depends on, or contains open source components. Often times open source is more commonly used by companies to then provide products to users – but not always.

So, to more easily understand how to talk about open source vs DIY:

  • The CREATE trial used a version of open source software and algorithm (the OpenAPS algorithm inside a modified version of the AndroidAPS application) in the study.
  • The study was NOT on “DIY” automated insulin delivery; the AID system was handed/provided to participants in the study. There was no DIY component in the study, although the same software is used both in the study and in the real world community by those who do DIY it. Instead, the point of the trial was to study the safety and efficacy of this version of open source AID.
  • Open source is not the same as DIY.
  • OpenAPS is open source and can be used by anyone – companies that want to commercialize, or individuals who want to DIY. For more information about our vision for this, check out the OpenAPS plain language reference design.
Venn diagram showing a small overlap between a bigger open source circle and a smaller DIY circle. An arrow points to the overlapping section, along with text of "OpenAPS". Below it text reads: "OpenAPS is open source and can be used DIY. DIY in diabetes often uses open source, but not always. Not all open source is used DIY."

Continuation Results On 48 Weeks of Use Of Open Source Automated Insulin Delivery From the CREATE Trial: Safety And Efficacy Data

In addition to the primary endpoint results from the CREATE trial, which you can read more about in detail here or as published in the New England Journal of Medicine, there was also a continuation phase study of the CREATE trial. This meant that all participants from the CREATE trial, including those who were randomized to the automated insulin delivery (AID) arm and those who were randomized to sensor-augmented insulin pump therapy (SAPT, which means just a pump and CGM, no algorithm), had the option to continue for another 24 weeks using the open source AID system.

These results were presented by Dr. Mercedes J. Burnside at #EASD2022, and I’ve summarized her presentation and the results below on behalf of the CREATE study team.

What is the “continuation phase”?

The CREATE trial was a multi-site, open-labeled, randomized, parallel-group, 24-week superiority trial evaluating the efficacy and safety of an open-source AID system using the OpenAPS algorithm in a modified version of AndroidAPS. Our study found that across children and adults, the percentage of time that the glucose level was in the target range of 3.9-10mmol/L [70-180mg/dL] was 14 percentage points higher among those who used the open-source AID system (95% confidence interval [CI], 9.2 to 18.8; P<0.001) compared to those who used sensor augmented pump therapy; a difference that corresponds to 3 hours 21 minutes more time spent in target range per day. The system did not contribute to any additional hypoglycemia. Glycemic improvements were evident within the first week and were maintained over the 24-week trial. This illustrates that all people with T1D, irrespective of their level of engagement with diabetes self-care and/or previous glycemic outcomes, stand to benefit from AID. This initial study concluded that open-source AID using the OpenAPS algorithm within a modified version of AndroidAPS, a widely used open-source AID solution, is efficacious and safe. These results were from the first 24-week phase when the two groups were randomized into SAPT and AID, accordingly.

The second 24-week phase is known as the “continuation phase” of the study.

There were 52 participants who were randomized into the SAPT group that chose to continue in the study and used AID for the 24 week continuation phase. We refer to those as the “SAPT-AID” group. There were 42 participants initially randomized into AID who continued to use AID for another 24 weeks (the AID-AID group).

One slight change to the continuation phase was that those in the SAPT-AID used a different insulin pump than the one used in the primary phase of the study (and 18/42 AID-AID participants also switched to this different pump during the continuation phase), but it was a similar Bluetooth-enabled pump that was interoperable with the AID system (app/algorithm) and CGM used in the primary outcome phase.

All 42 participants in AID-AID completed the continuation phase; 6 participants (out of 52) in the SAPT-AID group withdrew. One withdrew from infusion site issues; three with pump issues; and two who preferred SAPT.

What are the results from the continuation phase?

In the continuation phase, those in the SAPT-AID group saw a change in time in range (TIR) from 55±16% to 69±11% during the continuation phase when they used AID. In the SAPT-AID group, the percentage of participants who were able to achieve the target goals of TIR > 70% and time below range (TBR) <4% increased from 11% of participants during SAPT use to 49% during the 24 week AID use in the continuation phase. Like in the primary phase for AID-AID participants; the SAPT-AID participants saw the greatest treatment effect overnight with a TIR difference of 20.37% (95% CI, 17.68 to 23.07; p <0.001), and 9.21% during the day (95% CI, 7.44 to 10.98; p <0.001) during the continuation phase with open source AID.

Those in the AID-AID group, meaning those who continued for a second 24 week period using AID, saw similar TIR outcomes. Prior to AID use at the start of the study, TIR for that group was 61±14% and increased to 71±12% at the end of the primary outcome phase; after the next 6 months of the continuation phase, TIR was maintained at 70±12%. In this AID-AID group, the percentage of participants achieving target goals of TIR >70% and TBR <4% was 52% of participants in the first 6 months of AID use and 45% during the continuation phase. Similarly to the primary outcomes phase, in the continuation phase there was also no treatment effect by age interaction (p=0.39).

The TIR outcomes between both groups (SAPT-AID and AID-AID) were very similar after each group had used AID for 24 weeks (SAPT-AID group using AID for 24 weeks during the continuation phase and AID-AID using AID for 24 weeks during the initial RCT phase).. The adjusted difference in TIR between these groups was 1% (95% CI, -4 to 6; p=-0.67). There were no glycemic outcome differences between those using the two different study pumps (n=69, which was the SAPT-AID user group and 18 AID-AID participants who switched for continuation; and n=25, from the AID-AID group who elected to continue on the pump they used in the primary outcomes phase).

In the initial primary results (first 24 weeks of trial comparing the AID group to the SAPT group), there was a 14 percentage point difference between the groups. In the continuation phase, all used AID and the adjusted mean difference in TIR between AID and the initial SAPT results was a similar 12.10 percentage points (95% CI, p<0.001, SD 8.40).

Similar to the primary phase, there was no DKA or severe hypoglycemia. Long-term use (over 48 weeks, representing 69 person-years) did not detect any rare severe adverse events.

CREATE results from the full 48 weeks on open source AID with both SAPT (control) and AID (intervention) groups plotted on the graph.

Conclusion of the continuation study from the CREATE trial

In conclusion, the continuation study from the CREATE trial found that open-source AID using the OpenAPS algorithm within a modified version of AndroidAPS is efficacious and safe with various hardware (pumps), and demonstrates sustained glycaemic improvements without additional safety concerns.

Key points to takeaway:

  • Over 48 weeks total of the study (6 months or 24 weeks in the primary phase; 6 months/24 weeks in the continuation phase), there were 64 person-years of use of open source AID in the study, compared to 59 person-years of use of sensor-augmented pump therapy.
  • A variety of pump hardware options were used in the primary phase of the study among the SAPT group, due to hardware (pump) availability limitations. Different pumps were also used in the SAPT-AID group during the AID continuation phase, compared to the pumps available in the AID-AID group throughout both phases of trial. (Also, 18/42 of AID-AID participants chose to switch to the other pump type during the continuation phase).
  • The similar TIR results (14 percentage points difference in primary and 12 percentage points difference in continuation phase between AID and SAPT groups) shows durability of the open source AID and algorithm used, regardless of pump hardware.
  • The SAPT-AID group achieved similar TIR results at the end of their first 6 months of use of AID when compared to the AID-AID group at both their initial 6 months use and their total 12 months/48 weeks of use at the end of the continuation phase.
  • The safety data showed no DKA or severe hypoglycemia in either the primary phase or the continuation phases.
  • Glycemic improvements from this version of open source AID (the OpenAPS algorithm in a modified version of AndroidAPS) are not only immediate but also sustained, and do not increase safety concerns.
CREATE Trial Continuation Results were presented at #EASD2022 on 48 weeks of use of open source AID

New Research on Glycemic Variability Assessment In Exocrine Pancreatic Insufficiency (EPI) and Type 1 Diabetes

I am very excited to share that a new article I wrote was just published, looking at glycemic variability in data from before and after pancreatic enzyme replacement therapy (PERT) was started in someone with type 1 diabetes with newly discovered exocrine pancreatic insufficiency (EPI or PEI).

If you’re not aware of exocrine pancreatic insufficiency, it occurs when the pancreas no longer produces the amount of enzymes necessary to fully digest food. If that occurs, people need supplementary enzymes, known as pancreatic enzyme replacement therapy (PERT), to help them digest their food. (You can read more about EPI here, and I have also written other posts about EPI that you can find at DIYPS.org/EPI.)

But, like MANY medications, when someone with type 1 diabetes or other types of insulin-requiring diabetes starts taking them, there is little to no guidance about whether these medications will change their insulin sensitivity or otherwise impact their blood glucose levels. No guidance, because there are no studies! In part, this may be because of the limited tools available at the time these medications were tested and approved for their current usage. Also this is likely in part because people with diabetes make up a small fraction of the study participants that most of these medications are tested on. If there are any specific studies on the medications in people with diabetes, these studies likely were done before CGM, so little data is available that is actionable.

As a result, the opportunity came up to review someone’s data who happened to have blood glucose data from a continuous glucose monitor (CGM) as well as a log of what was eaten (carbohydrate entries) prior to commencing pancreatic enzyme replacement therapy. The tracking continued after commencing PERT and was expanded to also include fat and protein entries. As a result, there was a useful dataset to compare the impacts of pancreatic enzyme replacement therapy on blood glucose outcomes and specifically, looking at glycemic variability changes!

(You can read an author copy here of the full paper and also see the supplementary material here, and the DOI for the paper is https://doi.org/10.1177/19322968221108414 . Otherwise, below is my summary of what we did and the results!)

In addition to the above background, it’s worth noting that Type 1 diabetes is known to be associated with EPI. In upwards of 40% of people with Type 1 diabetes, elastase levels are lowered, which in other cases is correlated with EPI. However, in T1D, there is some confusion as to whether this is always the case or not. Based on recent discussions with endocrinologists who treat patients with T1D and EPI (and have patients with lowered elastase that they think don’t have EPI), I don’t think there have been enough studies looking at the right things to assess whether people with T1D and lowered elastase levels would benefit from PERT and thus have EPI. More on this in the future!

Because we now have technology such as AID (automated insulin delivery) and CGM, it’s possible to evaluate things beyond simple metrics of “average blood sugar” or “A1c” in response to taking new medications. In this paper, we looked at some basic metrics like average blood sugar and percent time in range (TIR), but we also did quite a few calculations of variables that tell us more about the level of variability in glucose levels, especially in the time frames after meals.

Methods

This person had tracked carb entries through an open source AID system, and so carb entries and BG data were available from before they started PERT. We call this “pre-PERT”, and selected 4 weeks worth of data to exclude major holidays (as diet is known to vary quite a bit during those times). We then compared this to “post-PERT”, the first 4 weeks after the person started PERT. The post-PERT data not only included BGs and carb entries, but also had fat and protein entries as well as PERT data. Each time frame included 13,975 BG data points.

We used a series of open source tools to get the data (Nightscout -> Nightscout Data Transfer Tool -> Open Humans) and process the data (my favorite Unzip-Zip-CSVify-OpenHumans-data.sh script).

All of our code for this paper is open source, too! Check it out here. We analyzed time in range, TIR 70-180, time out of range, TOR >180, time below range, TBR <70 and <54, the number of hyperglycemic excursions >180. We also calculated total daily dose of insulin, average carbohydrate intake, and average carbohydrate entries per day. Then we calculated a series of variability related metrics such as Low Blood Glucose Index (LBGI), High Blood Glucose Index (HBGI), Coefficient of Variation (CV), Standard Deviation (SD), and J_index (which stresses both the importance of the mean level and variability of glycemic levels).

Results

This person already had an above-goal TIR. Standard of care goal for TIR is >70%; before PERT they had 92.12% TIR and after PERT it was 93.70%. Remember, this person is using an open source AID! TBR <54 did not change significantly, TBR <70 decreased slightly, and TOR >180 also decreased slightly.

More noticeably, the total number of unique excursions above 180 dropped from 40 (in the 4 weeks without PERT) to 26 (in 4 weeks when using PERT).

The paper itself has a few more details about average fat, protein, and carb intake and any changes. Total daily insulin was relatively similar, carb intake decreased slightly post-PERT but was trending back upward by the end of the 4 weeks. This is likely an artifact of being careful to adjust to PERT and dose effectively for PERT. The number of meals decreased but the average carb entry per meal increased, too.

What I find really interesting is the assessment we did on variability, overall and looking at specific meal times. The breakfast meal was identical during both time periods, and this is where you can really SEE visible changes pre- and post-PERT. Figure 2 (displayed below), shows the difference in the rate of change frequency. There’s less of the higher rate of changes (red) post-PERT than there is from pre-PERT (blue).

Figure 2 from GV analysis on EPI, showing lower frequency of high rate of change post-PERT

Similarly, figure 3 from the paper shows all glucose data pre- and post-PERT, and you can see the fewer excursions >180 (blue dotted line) in the post-PERT glucose data.

Figure 3 from GV analysis paper on EPI showing lower number of excursions above 180 mg/dL

Table 1 in the paper has all the raw data, and Figure 1 plots the most relevant graphs side by side so you can see pre- and post-PERT before and after after all meals on the left, versus pre and post-PERT before and after breakfast only. Look at TOR >180 and the reduction in post-breakfast levels after PERT! Similarly, HBGI post-PERT after-breakfast is noticeably different than HBGI pre-PERT after-breakfast.

Here’s a look at the HBGI for breakfast only, I’ve highlighted in purple the comparison after breakfast for pre- and post-PERT:

High Blood Glucose Index (HBGI) pre- and post-PERT for breakfast only, showing reduction in post-PERT after breakfast

Discussion

This is a paper looking at n=1 data, but it’s not really about the n=1 here. (See the awesome limitation section for more detail, where I point out it’s n=1, it’s not a clinical study, the person has ‘moderate’ EPI, there wasn’t fat/protein data from pre-PERT, it may not be representative of all people with diabetes with EPI or EPI in general.)

What this paper is about is illustrating the types of analyses that are possible, if only we would capture and analyze the data. There are gaping holes in the scientific knowledge base: unanswered and even unasked questions about what happens to blood glucose with various medications, and this data can help answer them! This data shows minimal changes to TIR but visible and significant changes to post-meal glycemic variability (especially after breakfast!). Someone who had a lower TIR or wasn’t using an open source AID may have more obvious changes in TIR following PERT commencement.

This paper shows several ways we can more easily detect efficacy of new-onset medications, whether it is enzymes for PERT or other commonly used medications for people with diabetes.

For example, we could do a similar study with metformin, looking at early changes in glycemic variability in people newly prescribed metformin. Wouldn’t it be great, as a person with diabetes, to be able to more quickly resolve the uncertainty of “is this even working?!” and not have to suffer through potential side effects for 3-6 months or longer waiting for an A1c lab test to verify whether the metformin is having the intended effects?

Specifically with regards to EPI, it can be hard for some people to tell if PERT “is working”, because they’re asymptomatic, they are relying on lab data for changes in fat soluble vitamin levels (which may take time to change following PERT commencement), etc. It can also be hard to get the dosing “right”, and there is little guidance around titrating in general, and no studies have looked at titration based on macronutrient intake, which is something else that I’m working on. So, having a method such as these types of GV analysis even for a person without diabetes who has newly discovered EPI might be beneficial: GV changes could be an earlier indicator of PERT efficacy and serve as encouragement for individuals with EPI to continue PERT titration and arrive at optimal dosing.

Conclusion

As I wrote in the paper:

It is possible to use glycemic variability to assess changes in glycemic outcomes in response to new-onset medications, such as pancreatic enzyme replacement therapy (PERT) in people with exocrine pancreatic insufficiency (EPI) and insulin-requiring diabetes. More studies should use AID and CGM data to assess changes in glycemic outcomes and variability to add to the knowledge base of how medications affect glucose levels for people with diabetes. Specifically, this n=1 data analysis demonstrates that glycemic variability can be useful for assessing post-PERT response in someone with suspected or newly diagnosed EPI and provide additional data points regarding the efficacy of PERT titration over time.

I’m super excited to continue this work and use all available datasets to help answer more questions about PERT titration and efficacy, changes to glycemic variability, and anything else we can learn. For this study, I collaborated with the phenomenal Arsalan Shahid, who serves as technology solutions lead at CeADAR (Ireland’s Centre for Applied AI at University College Dublin), who helped make this study and paper possible. We’re looking for additional collaborators, though, so feel free to reach out if you are interested in working on similar efforts or any other research studies related to EPI!

A DIY Fuel Enzyme Macronutrient Tracker for Running Ultras (Ultramarathons)

It takes a lot of energy to run ultramarathons (ultras).

To ensure they have enough fuel to complete the run, people usually want to eat X-Y calories per hour, or A-B carbs per hour, while running ultramarathons. It can be hard to know if you’re staying on top of fueling, especially as the hours drag on and your brain gets tired; plus, you can be throwing away your trash as you go so you may not have a pile of wrappers to tell you what you ate.

During training, it may be useful to have a written record of what you did for each run, so you can establish a baseline and work on improving your fueling if that’s something you want to focus on.

For me specifically, I also find it helpful to record what enzyme dosing I am taking, as I have EPI (exocrine pancreatic insufficiency, which you can read more about here) and if I have symptoms it can help me identify where my dosing might have been off from the previous day. It’s not only the amount of enzymes but also the timing that matters, alongside the timing of carbs and insulin, because I have type 1 diabetes, celiac, and EPI to juggle during runs.

Previously, I’ve relied on carb entries to Nightscout (an open source CGM remote monitoring platform which I use for visualizing diabetes data including OpenAPS data) as a record of what I ate, because I know 15g of carbs tracks to a single serving of chili cheese Fritos that are 10g of fat and 2g of protein, and I take one lipase-only and one pancrelipase (multi-enzyme) pill for that; and 21g of carbs is a Honey Stinger Gluten Free Stroopwaffle that is 6g of fat and 1g of protein, and I typically take one lipase-only. You can see from my most recent ultra (a 50k) where I manually took those carb entries and mapped them on to my blood sugar (CGM) graph to visualize what happened in terms of fuel and blood sugar over the course of my ultra.

However, that was “just” a 50k and I’m working toward bigger runs: a 50 mile, maybe a 100k (62 miles), and/or a 100 mile, which means instead of running for 7-8 hours I’ll be running for 12-14 and 24-30(ish) hours! That’s a lot of fuel to need to eat, and to keep track of, and I know from experience my brain starts to get tired of thinking about and eating food around 7 hours. So, I’ll need something better to help me keep track of fuel, enzymes, and electrolytes over the course of longer runs.

I also am planning on being well supported by my “crew” – my husband Scott, who will e-bike around the course of my ultra or my DIY ultra loops and refill my pack with water and fuel. In some cases, with a DIY ultra, he’ll be bringing food from home that I pre-made and he warms up in the microwave.

One of the strategies I want to test is for him to actually hand me the enzymes for the food he’s bringing me. For example, hand me a baggie of mashed potatoes and also hand me the one multi-enzyme (pancrelipase, OTC) pill I need to go with it. That reduces mental effort for me to look up or remember what enzyme amount I take for mashed potatoes; saves me from digging out my baggie of enzymes and having to get the pill out and swallow it, put the baggie away without dropping it, all while juggling the snack in my hands.

He doesn’t necessarily know the counts of enzymes for each fuel (although he could reproduce it, it’s better if I pre-make a spreadsheet library of my fuel options and that helps me both just pick it off a drop down and have an easy reference for him to glance at. He won’t be running 50-100 miles, but he will be waking up every 2-3 hours overnight and that does a number on his brain, too, so it’s easier all around if he can just reference the math I’ve already done!

So, for my purposes: 1) easy tracking of fuel counts for real-time “am I eating according to plan” and 2) retrospective “how did I do overall and should I do something next time” and 3) for EPI and BG analysis (“what should I do differently if I didn’t get the ideal outcome?”), it’s ideal to have a tracking spreadsheet to log my fuel intake.

Here’s what I did to build my ultimate fuel self-tracking self-populating spreadsheet:

First, I created a tab in my spreadsheet as a “Fuel Library”, where I listed out all of my fuel. This ranges from snacks (chili cheese Fritos; Honey Stinger Gluten Free Stroopwaffle; yogurt-covered pretzels, etc.); to fast-acting carbs (e.g. Airhead Minis, Circus Peanuts) that I take for fixing blood sugars; to other snack/treats like chocolate candy bars or cookies; as well as small meals and warm food, such as tomato soup or part of a ham and cheese quesadilla. (All gluten free, since I have celiac. Everything I ever write about is always gluten free!)

After I input the list of snacks, I made columns to input the sodium, calories, fat, protein, and carb counts. I don’t usually care about calories but a lot of recommendations for ultras are calories/hr and carbs/hr. I tend to be lower on the carb side in my regular daily consumption and higher on fat than most people without T1D, so I’m using the calories for ultrarunning comparison to see overall where I’m landing nutrient-wise without fixating on carbs, since I have T1D and what I personally prefer for BG management is likely different than those without T1D.

I also input the goal amount of enzymes. I have three different types of pills: a prescription pancrelipase (I call PERT, which stands for pancreatic enzyme replacement therapy, and when I say PERT I’m referring to the expensive, prescription pancrelipase that’s been tested and studied for safety and efficacy in EPI); an over-the-counter (OTC) lipase-only pill; and an OTC multi-enzyme pancrelipase pill that contains much smaller amounts of all three enzymes (lipase, protease, amylase) than my PERT but hasn’t been tested for safety and efficacy for EPI. So, I have three enzyme columns: Lipase, OTC Pancrelipase, and PERT. For each fuel I calculate which I need (usually one lipase, or a lipase plus a OTC pancrelipase, because these single servings are usually fairly low fat and protein; but for bigger meal-type foods with more protein I may ‘round up’ and choose to take a full PERT, especially if I eat more of it), and input the number in the appropriate column.

Then, I opened another tab on my spreadsheet. I created a row of headers for what I ate (the fuel); time; and then all the macronutrients again. I moved this down to row 3, because I also want to include at the top of the spreadsheet a total of everything for the day.

Example-DIY-Fuel-Enzyme-Tracker-ByDanaMLewis

In Column A, I selected the first cell (A4) for me, then went to Data > Data Validation and clicked on it. It opens this screen, which I input the following – A4 is the cell I’m in for “cell range”, the criteria is “list from a range”, and then I popped over to the tab with my ‘fuel library’ and highlighted the relevant data that I wanted to be in the menu: Food. So that was C2-C52 for my list of food. Make sure “show dropdown list in cell” is marked, because that’s what creates the dropdown in the cell. Click save.

Use the data validation section to choose to show a dropbox in each cell

You’ll want to drag that down to apply the drop-down to all the cells you want. Mine now looked like this, and you can see clicking the dropdown shows the menu to tap on.

Clicking a dropbox in the cell brings up the "menu" of food options from my Fuel Library tab

After I selected from my menu, I wanted column B to automatically put in the time. This gets obnoxious: google sheets has NOW() to put in the current time, but DO NOT USE THIS as the formula updates with the latest time any time you touch the spreadsheet.

I ended up having to use a google script (go to “Extensions” > Apps Script, here’s a tutorial with more detail) to create a function called onEdit() that I could reference in my spreadsheet. I use the old style legacy script editor in my screenshot below.

Older style app script editor for adding scripts to spreadsheet, showing the onEdit() function (see text below in post for what the script is)

Code I used, if you need to copy/paste:

function onEdit(e) {

var rr = e.range;

var ss = e.range.getSheet();

var headerRows = 2;  // # header rows to ignore

if (rr.getRow() <= headerRows) return;

var row = e.range.getRow();

var col = e.range.getColumn();

if(col == 1){

e.source.getActiveSheet().getRange(row,2).setValue(new Date());

}

}

After saving that script (File > Save), I went back to my spreadsheet and put this formula into the B column cells: =IFERROR(onEdit(),””). It fills in the current date/time (because onEdit tells it to if the A cell has been updated), and otherwise sits with a blank until it’s been changed.

Note: if you test your sheet, you’ll have to go back and paste in the formula to overwrite the date/time that gets updated by the script. I keep the formula without the “=” in a cell in the top right of my spreadsheet so I can copy/paste it when I’m testing and updating my sheet. You can also find it in a cell below and copy/paste from there as well.

Next, I wanted to populate my macronutrients on the tracker spreadsheet. For each cell in row 4, I used a VLOOKUP with the fuel name from A4 to look at the sheet with my library, and then use the column number from the fuel library sheet to reference which data element I want. I actually have things in a different order in my fuel library and my tracking sheet; so if you use my template later on or are recreating your own, pay attention to matching the headers from your tracker sheet and what’s in your library. The formula for this cell ended up being “=IFERROR(VLOOKUP(A4,’Fuel Library’!C:K,4, FALSE),””)”, again designed to leave the column blank if column A didn’t have a value, but if it does have a value, to prefill the number from Column 4 matching the fuel entry into this cell. Columns C-J on my tracker spreadsheet all use that formula, with the updated values to pull from the correctly matching column, to pre-populate my counts in the tracker spreadsheet.

Finally, the last thing I wanted was to track easily when I last ate. I could look at column B, but with a tired brain I want something more obvious that tracks how long it’s been. This also is again to maybe help Scott, who will be tasked with helping me stay on top of things, be able to check if I’m eating regularly and encourage me gently or less gently to be eating more as the hours wear on in my ultras.

I ended up creating a cell in the header that would track the last entry from column B. To do this, the formula I found is “INDEX(B4:B,MATCH(143^143,B4:B))”, which checks for the last number in column B starting in B4 and onward. It correctly pulls in the latest timestamp on the list.

Then, in another cell, I created “=NOW()-B2”, which is a good use for the NOW() formula I warned about, because it’s constantly updating every time the sheet gets touched, so that any time I go to update it’ll tell me how long it’s been since between now and the last time I ate.

But, that only updates every time I update the sheet, so if I want to glance at the sheet, it will be only from the last time I updated it… which is not what I want. To fix it, I need to change the autorefresh calculation settings. Go to File > Settings. Click “Calculations” tab, and the first drop down you want to change to be “On change and every minute”.

Under File > Settings there is a "Calculate" tab with a dropdown menu to choose to update on change plus every minute

Now it does what I want, updating that cell that uses the NOW() formula every minute, so this calculation is up to date even when the sheet hasn’t been changed!

However, I also decided I want to log electrolytes in my same spreadsheet, but not include it in my top “when did I last eat” calculator. So, I created column K and inserted the formula IF(A4=”Electrolytes”,””,B4), which checks to see if the Dropdown menu selection was Electrolytes. If so, it doesn’t do anything. If it’s not electrolytes, it repeats the B4 value, which is my formula to put the date and time. Then, I changed B2 to index and match on column K instead of B. My B2 formula now is INDEX(K4:K,MATCH(143^143,K4:K)), because K now has the food-only list of date and time stamps that I want to be tracking in my “when did I last eat” tracker. (If you don’t log electrolytes or don’t have anything else to exclude, you can keep B2 as indexing and matching on column B. But if you want to exclude anything, you can follow my example of using an additional column (my K) to check for things you do want to include and exclude the ones you don’t want. Also, you can hide columns if you don’t want to see them, so column K (or your ‘check for exclusions’ column wherever it ends up) could be hidden from view so it doesn’t distract your brain.

I also added conditional formatting to my tracker. Anytime A2, the time since eaten cell, is between 0-30 minutes, it’s green: indicating I’m on top of my fueling. 30-45 minutes it turns yellow as a warning that it’s time to eat. After 45 minutes, it’ll turn light red as a strong reminder that I’m off schedule.

I kept adding features, such as totaling my sodium consumption per hour, too, so I could track electrolytes+fuel sodium totals. Column L gets the formula =IF(((ABS((NOW()-B4))*1440)<60),F4,””) to check for the difference between the current time and the fuel entry, multiplying it by 1440 to convert to minutes and checking to see that it’s less than 60 minutes. If it is, then it prints the sodium value, and otherwise leaves it blank. (You could skip the ABS part as I was testing current, past, and future values and wanted it to stop throwing errors for future times that were calculated as negatives in the first argument). I then in C2 calculate the sum of those values for the total sodium for that hour, using =SUM(L4:L)

(I thought about tracking the past sodium per hour values to average and see how I did throughout the run on an hourly basis…but so far on my 3 long runs where I’ve used the spreadsheet, the very fact that I am using the tracker and glancing at the hourly total has kept me well on top of sodium and so I haven’t need that yet. However, if I eventually start to have long enough runs where this is an issue, I’ll probably go back and have it calculate the absolute hour sodium totals for retrospective analysis.)

This works great in the Google Sheets app on my phone, which is how I’ll be updating it during my ultras, although Scott can have it open on a browser tab when he’s at home working at his laptop. Every time I go for a long training run, I duplicate the template tab and label it with the date of the run and use it for logging my fueling.

(PS – if you didn’t know, you can rearrange the order of tabs in your sheet, so you can drag the one you want to be actively using to the left. This is useful in case the app closes on your phone and you’re re-opening the sheet fresh, so you don’t have to scroll to re-find the correct tab you want to be using for that run. In a browser, you can either drag and drop the tabs, or click the arrow next to the tab name and select “move left” or “move right”.)

Clicking the arrow to the right of a tab name in google sheets brings up a menu that includes the option to move the tab left or right

Click here to make a copy of my spreadsheet.

If you click to make a copy of a google spreadsheet, it pops up a link confirming you want to make a copy, and also might bring the app script functionality with it. If so, you can click the button to view the script (earlier in the blog post). If it doesn't include the warning about the script, remember to add the script yourself after you make a copy.

Take a look at my spreadsheet after you make a copy (click here to generate a copy if you didn’t use the previous mentioned link), and you’ll note in the README tab a few reminders to modify the fuel library and make sure you follow the steps to ensure that the script is associated with the sheet and validation is updated.

Obviously, you may not need lipase/pancrelipase/PERT and enzyme counts; if you do, your counts of enzymes needed and types of enzyme and quantity of enzymes will need updating; you may not need or want all of these macronutrients; and you’ll definitely be eating different fuel than I am, so you can update it however you like with what you’re eating and what you want to track.

This spreadsheet and the methods for building it can also be used for other purposes, such as tracking wait times or how long it took you to do something, etc.

(If you do find this blog post and use this spreadsheet concept, let me know – I’d love to hear if this is useful for you!)

Findings from the world’s first RCT on open source AID (the CREATE trial) presented at #ADA2022

September 7, 2022 UPDATEI’m thrilled to share that the paper with the primary outcomes from the CREATE trial is now published. You can find it on the journal site here, or view an author copy here. You can also see a Twitter thread here, if you are interested in sharing the study with your networks.

Example citation:

Burnside, M; Lewis, D; Crocket, H; et al. Open-Source Automated Insulin Delivery in Type 1 Diabetes. N Engl J Med 2022;387:869-81. DOI:10.1056/NEJMoa2203913


(You can also see a previous Twitter thread here summarizing the study results, if you are interested in sharing the study with your networks.)

TLDR: The CREATE Trial was a multi-site, open-labeled, randomized, parallel-group, 24-week superiority trial evaluating the efficacy and safety of an open-source AID system using the OpenAPS algorithm in a modified version of AndroidAPS. Our study found that across children and adults, the percentage of time that the glucose level was in the target range of 3.9-10mmol/L [70-180mg/dL] was 14 percentage points higher among those who used the open-source AID system (95% confidence interval [CI], 9.2 to 18.8; P<0.001) compared to those who used sensor augmented pump therapy; a difference that corresponds to 3 hours 21 minutes more time spent in target range per day. The system did not contribute to any additional hypoglycemia. Glycemic improvements were evident within the first week and were maintained over the 24-week trial. This illustrates that all people with T1D, irrespective of their level of engagement with diabetes self-care and/or previous glycemic outcomes, stand to benefit from AID. This study concluded that open-source AID using the OpenAPS algorithm within a modified version of AndroidAPS, a widely used open-source AID solution, is efficacious and safe.

The backstory on this study

We developed the first open source AID in late 2014 and shared it with the world as OpenAPS in February 2015. It went from n=1 to (n=1)*2 and up from there. Over time, there were requests for data to help answer the question “how do you know it works (for anybody else)?”. This led to the first survey in the OpenAPS community (published here), followed by additional retrospective studies such as this one analyzing data donated by the community,  prospective studies, and even an in silico study of the algorithm. Thousands of users chose open source AID, first because there was no commercial AID, and later because open source AID such as the OpenAPS algorithm was more advanced or had interoperability features or other benefits such as quality of life improvements that they could not find in commercial AID (or because they were still restricted from being able to access or afford commercial AID options). The pile of evidence kept growing, and each study has shown safety and efficacy matching or surpassing commercial AID systems (such as in this study), yet still, there was always the “but there’s no RCT showing safety!” response.

After Martin de Bock saw me present about OpenAPS and open source AID at ADA Scientific Sessions in 2018, we literally spent an evening at the dinner table drawing the OpenAPS algorithm on a napkin at the table to illustrate how OpenAPS works in fine grained detail (as much as one can do on napkin drawings!) and dreamed up the idea of an RCT in New Zealand to study the open source AID system so many were using. We sought and were granted funding by New Zealand’s Health Research Council, published our protocol, and commenced the study.

This is my high level summary of the study and some significant aspects of it.

Study Design:

This study was a 24-week, multi-centre randomized controlled trial in children (7–15 years) and adults (16–70 years) with type 1 diabetes comparing open-source AID (using the OpenAPS algorithm within a version of AndroidAPS implemented in a smartphone with the DANA-i™ insulin pump and Dexcom G6® CGM), to sensor augmented pump therapy. The primary outcome was change in the percent of time in target sensor glucose range (3.9-10mmol/L [70-180mg/dL]) from run-in to the last two weeks of the randomized controlled trial.

  • This is a LONG study, designed to look for rare adverse events.
  • This study used the OpenAPS algorithm within a modified version of AndroidAPS, meaning the learning objectives were adapted for the purpose of the study. Participants spent at least 72 hours in “predictive low glucose suspend mode” (known as PLGM), which corrects for hypoglycemia but not hyperglycemia, before proceeding to the next stage of closed loop which also then corrected for hyperglycemia.
  • The full feature set of OpenAPS and AndroidAPS, including “supermicroboluses” (SMB) were able to be used by participants throughout the study.

Results:

Ninety-seven participants (48 children and 49 adults) were randomized.

Among adults, mean time in range (±SD) at study end was 74.5±11.9% using AID (Δ+ 9.6±11.8% from run-in; P<0.001) with 68% achieving a time in range of >70%.

Among children, mean time in range at study end was 67.5±11.5% (Δ+ 9.9±14.9% from run-in; P<0.001) with 50% achieving a time in range of >70%.

Mean time in range at study end for the control arm was 56.5±14.2% and 52.5±17.5% for adults and children respectively, with no improvement from run-in. No severe hypoglycemic or DKA events occurred in either arm. Two participants (one adult and one child) withdrew from AID due to frustrations with hardware issues.

  • The pump used in the study initially had an issue with the battery, and there were lots of pumps that needed refurbishment at the start of the study.
  • Aside from these pump issues, and standard pump site/cannula issues throughout the study (that are not unique to AID), there were no adverse events reported related to the algorithm or automated insulin delivery.
  • Only two participants withdrew from AID, due to frustration with pump hardware.
  • No severe hypoglycemia or DKA events occurred in either study arm!
  • In fact, use of open source AID improved time in range without causing additional hypoglycemia, which has long been a concern of critics of open source (and all types of) AID.
  • Time spent in ‘level 1’ and ‘level 2’ hyperglycemia was significantly lower in the AID group as well compared to the control group.

In the primary analysis, the mean (±SD) percentage of time that the glucose level was in the target range (3.9 – 10mmol/L [70-180mg/dL]) increased from 61.2±12.3% during run-in to 71.2±12.1% during the final 2-weeks of the trial in the AID group and decreased from 57.7±14.3% to 54±16% in the control group, with a mean adjusted difference (AID minus control at end of study) of 14.0 percentage points (95% confidence interval [CI], 9.2 to 18.8; P<0.001). No age interaction was detected, which suggests that adults and children benefited from AID similarly.

  • The CREATE study found that across children and adults, the percentage of time that the glucose level was in the target range of 3.9-10mmol/L [70-180mg/dL] was 14.0 percentage points higher among those who used the open-source AID system compared to those who used sensor augmented pump therapy.
  • This difference reflects 3 hours 21 minutes more time spent in target range per day!
  • For children AID users, they spent 3 hours 1 minute more time in target range daily (95% CI, 1h 22m to 4h 41m).
  • For adult AID users, they spent 3 hours 41 minutes more time in target range daily (95% CI, 2h 4m to 5h 18m).
  • Glycemic improvements were evident within the first week and were maintained over the 24-week trial. Meaning: things got better quickly and stayed so through the entire 24-week time period of the trial!
  • AID was most effective at night.
Difference between control and AID arms overall, and during day and night separately, of TIR for overall, adults, and kids

One thing I think is worth making note of is that one criticism of previous studies with open source AID is regarding the self-selection effect. There is the theory that people do better with open source AID because of self-selection and self-motivation. However, the CREATE study recruited a diverse cohort of participants, and the study findings (as described above) match all previous reports of safety and efficacy outcomes from previous studies. The CREATE study also found that the greatest improvements in TIR were seen in participants with lowest TIR at baseline. This means one major finding of the CREATE study is that all people with T1D, irrespective of their level of engagement with diabetes self-care and/or previous glycemic outcomes, stand to benefit from AID.

This therefore means there should be NO gatekeeping by healthcare providers or the healthcare system to restrict AID technology from people with insulin-requiring diabetes, regardless of their outcomes or experiences with previous diabetes treatment modalities.

There is also no age effect observed in the trail, meaning that the results of the CREATE Trial demonstrated that open-source AID is safe and effective in children and adults with type 1 diabetes. If someone wants to use open source AID, they would likely benefit, regardless of age or past diabetes experiences. If they don’t want to use open source AID or commercial AID…they don’t have to! But the choice should 100% be theirs.

In summary:

  • The CREATE trial was the first RCT to look at open source AID, after years of interest in such a study to complement the dozens of other studies evaluating open source AID.
  • The conclusion of the CREATE trial is that open-source AID using the OpenAPS algorithm within a version of AndroidAPS, a widely used open-source AID solution, appears safe and effective.
  • The CREATE trial found that across children and adults, the percentage of time that the glucose level was in the target range of 3.9-10mmol/L [70-180mg/dL] was 14.0 percentage points higher among those who used the open-source AID system compared to those who used sensor augmented pump therapy; a difference that reflects 3 hours 21 minutes more time spent in target range per day.
  • The study recruited a diverse cohort, yet still produced glycemic outcomes consistent with existing open-source AID literature, and that compare favorably to commercially available AID systems. Therefore, the CREATE Trial indicates that a range of people with type 1 diabetes might benefit from open-source AID solutions.

Huge thanks to each and every participant and their families for their contributions to this study! And ditto, big thanks to the amazing, multidisciplinary CREATE study team for their work on this study.


September 7, 2022 UPDATE – I’m thrilled to share that the paper with the primary outcomes from the CREATE trial is now published. You can find it on the journal site here, or like all of the research I contribute to, access an author copy on my research paper.

Example citation:

Burnside, M; Lewis, D; Crocket, H; et al. Open-Source Automated Insulin Delivery in Type 1 Diabetes. N Engl J Med 2022;387:869-81. DOI:10.1056/NE/Moa2203913

Note that the continuation phase study results are slated to be presented this fall at another conference!

Findings from the RCT on open source AID, the CREATE Trial, presented at #ADA2022

AID (APS) book now available in French!

Thanks to the dedicated efforts of Olivier Legendre and Dr. Mihaela Muresan, my book “Automated Insulin Delivery: How artificial pancreas “closed loop” systems can aid you in living with diabetes” (available on Amazon in Kindle, paperback, and hardcover formats, or free to read online and download at ArtificialPancreasBook.com) is now available in French!

The French version is also available for free download as a PDF at ArtificialPancreasBook.com or in Kindle (FR), paperback (FR), and hardcover (FR) formats!

 

French version of the AID book is now available, also in hardcover, paperback, and Kindle formats on Amazon

Merci au Dr. Mihaela Muresan et Olivier Legendre pour la traduction de l’intégralité de ce livre !

(Thank you to Dr. Mihaela Muresan and Olivier Legendre for translating this entire book!)

Why it feels harder to dose pancreatic enzyme replacement therapy (PERT) than insulin

In 2002 when I was diagnosed with Type 1 diabetes, I struggled with being handed a vial of insulin and told vaguely to eat X amount of food and take Y amount of insulin. There was no ability to eat more and adjust the dose accordingly. It was frustrating. The only tool I had was a huge (imagine three iPhone 13 or equivalently large smartphones sitting on top of each other) blood glucose meter that took a lot of blood and a long time (a minute or more) to return a single blood glucose data point. The feedback loop wasn’t very useful, even when I tested my blood sugar manually 10-14 times per day.

Thankfully, in the last two decades, diabetes tools have evolved. Meters got smaller, faster, and take less blood. There has also been the devlopment of continuous glucose monitors (CGM) which I can wear and get near real-time readings of glucose data and can see what’s happened in the past. And, paired with an algorithm that also knows about the history of any insulin dosing on my insulin pump, and it can automatically adjust my insulin delivery in real time to predict, prevent, and reduce hypo- and hyperglycemia. (AID is awesome and if you haven’t heard about it, there’s a 4-minute free animated video here that explains it.) Diabetes no longer is quite the headache it was twenty – or even ten – years ago.

But realizing that I have exocrine pancreatic insufficiency (known as EPI or PEI) and learning how to take pancreatic enzyme replacement therapy (known as PERT) is a similar headache to diabetes in 2002.

With insulin, taking too much can cause hypoglycemia (low blood sugar). Taking too little can cause hyperglycemia (high blood sugar). Yet, with diabetes, you can measure blood glucose and see the response to insulin within a minutes-to-hours time frame. You can also use an insulin pump and an automated insulin delivery system to titrate and adjust insulin in real time.

However, for EPI, you need to take enzymes (that your pancreas doesn’t produce enough of) to help you digest your food. Your pancreas makes three types of enzymes: lipase, to help fat digest; protease, to help protein digest; and amylase, to help starches and carbohydrates digest. These are taken by mouth as a pill that you swallow. Together in one pill, it’s called “pancrelipase”, and it’s for pancreatic enzyme replacement therapy (PERT). (I’m personally bad about using pancrelilpase/PERT interchangeably, because PERT is faster to say and type, but it is possible to use standalone enzymes in PERT).

Because they are pills that you have to swallow when you eat, it’s hard to dose. Taking too little means you may have GI-related symptoms in the hours following the meal and feeling bad until the next day or so. Taking too much is expensive, although unlike insulin it’s rare to take “too much” and cause bad side effects (although possible at super high doses). There’s also the “pill burden”, because swallowing a bunch of pills is annoying and sometimes hard, both physically to swallow and to remember to take them throughout your meal.

You also can’t take more hours later if you forgot to take them or realize you didn’t dose enough for that meal. If you underdosed, you underdosed and just get to experience the symptoms that come with it. Sometimes, it’s not clear why you are having symptoms. Because there are three enzymes being replaced, it’s possible that the dosing was off for any one of the three enzymes. But again, there’s no measurement or feedback loop, or a sign that appears saying “you underdosed protease, take more next time”. The best you can do is try different sized meals over time with different doses of PERT, trying to reverse engineer your lipase:fat and protease:protein and amylase:carb ratios and continuously update them as you have new data.

It’s a lot of work, the feedback loop is slow, getting it “wrong” is painful physically and psychologically, and there are no vacations from it. Everything I eat, now that I have EPI, needs enzymes, and given the fact that I have automated insulin delivery to help manage insulin dosing, I am finding PERT to be a lot harder and more annoying (currently).

A comparison of dosing insulin and dosing enzymes. Insulin can cause hypo- or hyperlgycemia but there are tools (CGM and BG meters) and a feedback loop in diabetes. With enzymes, there is no fast feedback loop and underdosing is common. There is no ability to correct an underdose and there are multiple variables that can influence the outcome.

There’s no happy ending to this post, but this is one of the reasons why I am so interested in partnering with researchers to do research on EPI. There are a LOT of improvements that can be made, ranging from improving titration guidance of PERT to testing the efficacy of different over the counter enzymes to finding new technology that might begin to provide a feedback loop into EPI (either for short-term assessment or longer-term use for those who prefer it). If you’re someone interested in this type of research, please don’t hesitate to reach out (Dana@OpenAPS.org).

(PS, if you didn’t see them, I have other posts about EPI at DIYPS.org/EPI)

Looking back at work and accomplishments in 2021

I decided to do a look back at the last year’s worth of work, in part because it was a(nother) weird year in the world and also because, if you’re interested in my work, unless you read every single Tweet, there may have been a few things you missed that are of interest!

In general, I set goals every year that stretch across personal and professional efforts. This includes a daily physical activity streak that coincides with my walking and running lots of miles this year in pursuit of my second marathon and first (50k) ultramarathon. It’s good for my mental and physical health, which is why I post almost daily updates to help keep myself accountable. I also set goals like “do something creative” which could be personal (last year, knitting a new niece a purple baby blanket ticked the box on this goal!) or professional. This year, it was primarily professional creativity that accomplished this goal (more on that below).

Here’s some specifics about goals I accomplished:

RUNNING

  • My initial goal was training ‘consistently and better’ than I did for my first marathon, with 400 miles as my stretch goal if I was successfully training for the marathon. (Otherwise, 200 miles for the year would be the goal without a marathon.) My biggest-ever running year in 2013 with my first marathon was 356 miles, so that was a good big goal for me. I achieved it in June!
  • I completed my second marathon in July, and PR’d by over half an hour.
  • I completed my first-ever ultramarathon, a 50k!
  • I re-set my mileage goal after achieving 400 miles..to 500..600…etc. I ultimately achieved the biggest-ever mileage goal I’ve ever hit and think I ever will hit: I ran 1,000 miles in a single year!
  • I wrote lots of details about my methods of running (primarily, run/walking) and running with diabetes here. If you’re looking for someone to cheer you on as you set a goal for daily activity, like walking, or learning to run, or returning to running…DM or @ me on Twitter (@DanaMLewis). I love to cheer people on as they work toward their activity goals! It helps keep me inspired, too, to keep aiming at my own goals.

CREATIVITY

  • My efforts to be creative were primarily on the professional side this year. The “Convening The Center” project ended up having 2 out of 3 of my things that I categorized as being creative. The first was the design of the digital activities and the experience of CTC overall (more about that here). The second were the items in the physical “kit” we mailed out to participants: we brainstormed and created custom playing cards and physical custom keychains. They were really fun to make, especially in partnership with our excellent project artist, Rebeka Ryvola, who did the actual design work!
  • My third “creative” endeavor was a presentation, but it was unlike the presentations I usually give. I was tasked to create a presentation that was “visually engaging” and would not involve showing my face in the presentation. I’ve linked to the video below in the presentation section, but it was a lot of work to think about how to create a visually and auditory focused presentation and try to make it engaging, and I’m proud of how it turned out!

RESEARCH AND PUBLICATIONS

  • This is where the bulk of my professional work sits right now. I continue to be a PI on the CREATE trial, the world’s first randomized control trial assessing open-source automated insulin delivery technology, including the algorithm Scott and I dreamed up and that I have been using every day for the past 7 years. The first data from the trial itself is forthcoming in 2022. 
  • Convening The Center also was a grant-funded project that we turned into research with a publication that we submitted, assessing more of what patients “do”, which is typically not assessed by researchers and those looking at patient engagement in research or innovation. Hopefully, the publication of the research article we just submitted will become a 2022 milestone! In the meantime, you can read our report from the project here (https://bit.ly/305iQ1W ), as this grant-funded project is now completed.
  • Goal-wise, I aim to generate a few publications every year. I do not work for any organization and I am not an academic. However, I come from a communications background and see the benefit of reaching different audiences where they are, which is why I write blog posts for the patient community and also seek to disseminate knowledge to the research and clinical communities through traditional peer-reviewed literature. You can see past years’ research articulated on my research page (DIYPS.org/research), but here’s a highlight of some of the 2021 publications:
  • Also, although I’m not a traditional academic researcher, I also participate in the peer review process and frequently get asked to peer-review submitted articles to a variety of journals. I skimmed my email and it looks like I completed (at least) 13 peer reviews, most of which included also reviewing subsequent revisions of those submitted articles. So it looks like my rate of peer reviewing (currently) is matching my rate of publishing. I typically get asked to review articles related to open-source or DIY diabetes technology (OpenAPS, AndroidAPS, Loop, Nightscout, and other efforts), citizen science in healthcare, patient-led research or patient engagement in research, digital health, and diabetes data science. If you’re submitting articles on that topic, you’re welcome to recommend me as a potential reviewer.

PRESENTATIONS

  • I continued to give a lot of virtual presentations this year, such as at conferences like the “Insulin100” celebration conference (you can see the copy I recorded of my conference presentation here). I keynoted at the European Patients Forum Congress as well as at ADA’s Precision Diabetes Medicine 2021; an invited talk ADA Scientific Sessions (session coverage here); the 2021 Federal Wearables Summit: (video here); and the BIH Clinician Scientist Symposium (video here), to name a few (but not all).
  • Additionally, as I mentioned, one of the presentations I’m most proud of was created for the Fall 2021 #DData Exchange event:

OTHER STUFF

I did quite a few other small projects that don’t fit neatly into the above categories.

One final thing I’m excited to share is that also in 2021, Amazon came out with a beta program for producing hardcover/hardback books, alongside the ability to print paperback books on demand (and of course Kindle). So, you can now buy a copy of my book about Automated Insulin Delivery: How artificial pancreas “closed loop” systems can aid you in living with diabetes in paperback, hardback, or on Kindle. (You can also, still, read it 100% for free online via your phone or desktop at ArtificialPancreasBook.com, or download a PDF for free to read on your device of choice. Thousands of people have downloaded the PDF!)

Now available in hardcover, the book about Automated Insulin Delivery by Dana M. Lewis

Everything I did wrong (but did anyway) training for a marathon after a broken ankle and marathon running with type 1 diabetes

This is another one of those posts for a niche audience. If you found this post, you’re likely looking for information about:

  • Running after a broken ankle (or are coming from my “tips for returning to weight bearing” and looking for an update from me, two years after my trimalleolar ankle fracture)
  • Running with the “Galloway method”, also known as run-walk or run/walk methods for marathon or similar long distances – but with information about run-walking for slow runners.
  • Running a marathon with type 1 diabetes, or running an ultra with type 1 diabetes
  • Running a marathon and training for a marathon and going without fuel or less fuel
    *Update: also running an ultramarathon with the same methods (less fuel than typical)!

There’s a bit of all of this in the post! (But TLDR – I ran my marathon (finally), successfully, despite having a previously broken ankle. And despite running it with type 1 diabetes, I had no issues managing my blood sugars during even the longest training runs, even with significantly less fuel than is typically used by marathon runners. I also ran a 50k ultra using the same methods!)

running a marathon after a broken ankle and with type 1 diabetes

First up, some context that explains why I chose run-walking as my method of running a marathon (as that also influences fueling choices) and what it is like to be a slow marathon runner (6 hour marathon ish). I broke my ankle in January 2019 and began running very tiny amounts (literally down the block to start) in summer 2019. I progressed, doing a short run interval followed by a walk interval, increasing the total numbers of intervals, and then slowly progressing to extend the length (distance and/or time) of the running intervals. In early fall 2019, I was attempting a couch-to-5k type program where I would extend my running intervals even longer, but I still had subsequent injuries (a very stubborn big toe joint, then intermetatarsal bursitis in TWO spots (argh)) that made this not work well. Eventually, I went back to running 30 seconds and walking 30 seconds, then keeping those “short” intervals and extending my run. I focused on time at first: going from 5 to 10 to 15 to 20 etc minutes, rather than focusing on distance. Once I built up to about 30 minutes of run-walking (30:30, meaning running 30 seconds and walking 30 seconds), I switched to adding a quarter or half mile each time depending on how I was feeling. But doing 30:30 seemed to work really well for me in terms of the physical impact to my feet, even with long miles, and also mentally, so I stuck with it. (You can go read about the Galloway run-walk-run method for more about run-walking; most people build up to running more, say 5 minutes or 8 minutes followed by a minute of walking, or maybe run 1 mile and then walk for a minute, or walk through the aid stations, but I found that 30:30 is what I liked and stuck with it or 60:30 as my longest intervals.)

This worked so well for me that I did not think about my right ankle a single time during or after my marathon! It took days to even remember that I had previously broken my ankle and it could’ve been problematic or weaker than my other ankle during my marathon. It took a long time to get to this point – I never thought I’d be forgetting even for a few days about my broken ankle! But two years later, I did.)

When COVID-19 struck, and as someone who paid attention early (beginning late January 2020), I knew my marathon would not be taking place in July 2020 and would be postponed until 2021. So I focused on keeping my feet healthy and building up a running “base” of trying to stay healthy feet-wise running twice a week into fall 2020, which worked fairly well. At the start of 2021, I bumped up to three runs a week consistently, and eventually began making one run every other a week longer. My schedule looked something like this:

Monday – 3 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – 4 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – 5 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – 6 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – (back to) 3 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – 8 miles  Wednesday – 3 miles   Friday – 3 miles

Monday – (back to) 3  miles  Wednesday – 5 miles   Friday – 4 miles

Monday – 10 miles  Wednesday – 3 miles   Friday – 3 miles

Note that these runs I refer to were all technically run-walks, where I ran 30 seconds and walked 30 seconds (aka 30:30) until I covered the miles. I was running slow and easy, focusing on keeping my heart rate below its maximum and not worrying about speed, so between that and run-walking I was often doing 15m30s miles. Yes, I’m slow. This all enabled me to build up to safely be able to run 3 runs weekly at first, and then eventually progressed to adding a fourth run. When I added a fourth run, I was very conservative and started with only 1 mile for two weeks in a row, then 2 miles, then up to 3 miles. Eventually, later in my training, I had some of my other runs in the week be a bit longer (4-5 miles) in addition to my “long” run.

But, because I’m so slow, this means it takes a lot of time to run my long runs. If you estimate a 15-minute mile for easy math, that means an 8 mile “long” run would take at least 2 hours. With marathon training (and my goal to train up to multiple 22-24 mile runs before the marathon), that took A LOT of time. And, because of my broken ankle and intermetatarsal experiences from 2019, I was very cautious and conservative about taking care of my feet during training. So instead of following the usual progression of long runs increasing 2-3 weeks in a row, followed by a “cutback” long week, after I hit two hours of long running (essentially 8 miles, for me), I started doing long runs every other week. The other week was a “cutback” long run, which was usually 8 miles, 10 miles (for several weeks), up to eventually 12-14. In terms of “time on feet”, this meant 2-3 hours “cutback” long runs, which according to many people is the max you should be running for marathon training. That doesn’t quite work for slow runners such as myself where you might be doing a 6-hour marathon or 7-hour marathon or thereabouts. (The standard advice also maybe doesn’t apply when you are doing run-walking for your marathon training.)

I had ~6 months to build up to my marathon (from January to the end of July), so I had time to do this, which gave me a buffer in my overall training schedule in case of scheduling conflicts (which happened twice) and in case of injury (which thankfully didn’t happen). I ended up scheduling training long runs all the way to full marathon distance (26ish miles), because I wanted to practice my fueling (especially important for type 1 diabetes marathon runners, which I’ll talk about next) as well as get my feet used to that many hours of run-walking. I did my long runs without care for speed, so some of them were closer to 16-minute mile averages, some were around 15-minute mile averages for the entire run, and the day I ran the full marathon course for training I ended up doing 16+ minute miles and felt fabulous at the end.

I ended up doing a few “faster” “shorter” long runs (on my cutback weeks), where I would do a half marathon-ish distance on the actual marathon course (a public trail), and try to go faster than my super slow long run pace. I had several successful runs where I was at or near marathon pace (which for me would be around 13m30s). So yes, you can train slow and run fast for a marathon, even without much speed work, and even if you are doing a run-walk method, and even if you’re as slow as I am. Running ~15-minute miles took forever but kept my feet and body healthy and happy through marathon training, and I was still able to achieve my sub-6 hour marathon goal (running 13:41 average pace for 26.2+ miles) on race day.

Now let’s talk about fueling, and in particular fueling for people with type 1 diabetes and for people wondering if the internet is right about what fueling requirements are for marathon runners.

I previously wrote (for a T1D audience) about running when fasted, because then you don’t have to deal with insulin on board at the start of a run. That’s one approach, and another approach is to have a smaller meal or snack with fewer carbs before the run, and time your run so that you don’t need to bolus or inject for that meal before you start your run. That’s what I chose for most of my marathon training, especially for longer runs.

On a typical non-running day, I would eat breakfast (½ cup pecans, ¼ cup cranberries, and a few sticks of cheese), my OpenAPS rig would take care of insulin dosing (or I could bolus for it myself), and my BGs would be well managed. However, that would mean I had a lot of insulin on board (IOB) if I tried to run within an hour of that. So instead, during marathon training, I ended up experimenting with eating a smaller amount of pecans (¼ cup) and no cranberries, not bolusing or letting OpenAPS bolus, and running an hour later. I had a small BG rise from the protein (e.g. would go from 100 mg/dL flat overnight to 120-130 mg/dL), and then running would balance out the rest of it.

I generally would choose to target my blood sugar to 130 mg/dL at the start of long runs, because I prefer to have a little bit of buffer for if/when my blood sugar began to drop. I also figured out that if I wasn’t having IOB from breakfast, I did not need to reduce my insulin much in advance of the run, but do it during the duration of the run. Therefore, I would set a higher temporary target in my OpenAPS rig, and if I was doing things manually, I would set a temporary basal rate on my insulin pump to about ⅓ of my usual hourly rate for the duration of the run. That worked well because by the time the beginning of my run (30-45 minutes) brought my BG down a little bit from the start with the protein breakfast bump (up to 130 mg/dL or so), that’d also be when the reduced insulin effect would be noticeable, and I would generally stay flat instead of having a drop at the beginning or first hour of my run.

After my first hour or so, I just kept an eye periodically on my blood sugars. My rule of thumb was that if my BG drifted down below 120 mg/dL, I would eat a small amount of carbs. My carb of choice was an individually wrapped peppermint (I stuffed a bunch in my pocket for the run) that was 3-4g of carb. If I kept drifting down or hadn’t come back up to 120 mg/dL 10-15 minutes later, I would do another. Obviously, if I was dropping fast I would do more, but 75% of the time I only needed one peppermint (3-4g of carb) to pause a drift down. If you have a lot of insulin on board, it would take more carbs, but my method of not having IOB at the start of long runs worked well for me. Sometimes, I would run my entire long run with no carbs and no fuel (other than water, and eventually electrolyte pills). Part of this is likely due to the fact that I was run-walking at such low intensity (remember 15-ish minute miles), but part of this is also due to figuring out the right amount of insulin I needed for endurance running and making sure I didn’t have excess insulin on board. On my faster runs (my half marathon distance fast training runs, that were 2+ minutes/mile faster than my slow long runs) and my marathon itself, I ended up needing more carbs than a super slow run – but it ended up being about 30 grams of carbohydrate TOTAL.

Why am I emphasizing this?

Well, the internet says (and most coaches, training plans, etc) that you need 30g of carbs PER HOUR. And that you need to train your stomach to tolerate that many carbs, because your muscles and brain need it. And without that much fuel, you will ‘hit the wall’.

My hypothesis, which may be nuanced by having type 1 diabetes and wearing a CGM and being able to track my data closely and manage it not only by carbs but also titrating insulin levels (which someone without diabetes obviously can’t do), is that you don’t necessarily need that many carbs, even for endurance running or marathon running.

I’m wondering if there’s a correlation between people who max out their long runs around 16-20 miles and who then “hit the wall” around mile 20 of a marathon. Perhaps some of it is muscle fatigue because they haven’t trained for the distance and some of it is psychological of feeling the brain fatigue.

During my marathon, in which I ran 2+ min/mi faster than most of my training runs, I did not ever experience hypoglycemia, and I did not “hit the wall”. Everything hurt, but I didn’t “hit the wall” as most people talk about. Those might be related, or it might be influenced by the fact that I had done a 20, 22, 24, 26, and another 21 mile run as part of my training, so my legs were “used” to the 20+ mile distance?

So again – some of my decreased fueling needs may be because I was already reducing my insulin and balancing my blood sugars (really well), and if my blood sugar was low (hypoglycemia), I would’ve needed more carbs. Or you can argue my lower fueling needs are because I’m so slow (15-16 minute mile training runs, or a 13m40s marathon pace). But in any case, I wanted to point out that if the fueling advice you’re getting or reading online seems like it’s “too much” per hour, there are people who are successful in hitting their time goals and don’t hit the wall on lower fueling amounts, too. You don’t necessarily have to fuel for the sake of fueling.

Note that I am not doing “low carb” or “keto” or anything particular diet-wise (other than eating gluten-free, because I also have celiac disease) outside of my running fuel choices. This was a successful strategy for me, and I eat what might be considered a moderate carb diet outside of running fuel choices.

Ps – if you don’t fuel (carbs or other nutrients) during your runs, don’t forget about your electrolytes. I decided to keep drinking water out of a Camelbak in a running pack, rather than filling it with Gatorade or a similar electrolyte drink, but I’m pretty electrolyte sensitive so I needed to do something to replace them. I got electrolyte pills and would take them every 30 minutes or so on long training runs when it was hotter. Play around with timing on those: if you don’t sweat a lot or aren’t a salty sweater, you may not need as many as often. I ended up doing the bulk of my long runs on hot days, and I sweat a lot, so every 30 minutes was about right for me. On cooler runs, one per hour was sufficient for me. (I tried these chewable tabs in lemon-lime but didn’t like the salt feeling directly in my mouth; I ended up buying these to swallow instead: I didn’t have any digestion issues or side effects from them, and they successfully kept my electrolytes to manageable levels. The package says not to take more than 10 within a 24 hour period, but I ended up taking 12 for my longest training run and the marathon itself and suffered no ill effects. It’s probably set to max 10 because of the amount of salt compared to the typical daily amount needed..but obviously, if you’re doing endurance running you need more than the daily amount of salt you would need on a regular day. But I’m not a doctor and this isn’t medical advice, of course – I’m just telling you what I chose to do).

In terms of training, here’s everything the internet told me to do for marathon training and everything I did “wrong” according to the typical advice:

  • Your long run should be 20-30% of your overall weekly mileageWhat I did: Sometimes my long runs got up to 70% of my weekly mileage, because I was only running 3 and then 4 days a week, and not doing very long mid-week runs.
  • Have longer mid-week runs, and build those up in addition to your true long runWhat I did: I did build up to a few 5-6 mile mid-week runs, but I chose consistency of my 4 runs per week rather than overdoing it with mid-week medium runs
  • Run 5-6 days a weekWhat I did: Only run 4 times a week, because I wanted a rest day after each run, and wanted a rest day prior to my longest run. I ran Monday, Wednesday, Friday, then added Saturday short runs. Monday was my long run (because I have the benefit of a flexible schedule for work).
  • Get high mileage (start from a base of 30-40 miles a week and build up to 50-60 miles!)What I did: I started with a “base” of 10 miles a week with two runs that I was very proud of. I went to three runs a week, and then 4. My biggest running week during training was 40.55 miles, although they were all 20+ mile weeks (long or cutback weeks) after the first two months of training.
  • Do progressively longer long runs for two or three weeks in a row and then do one cutback week, then continue the progressionWhat I did: Because of the time on my feet cost of being a slower runner, I did an every-other-week long-run progression alternating with a shorter cutback week.
  • Long run, tempo run, speed work, etc. plus easy runs! All the things each week!What I did: a long run per week, then the rest of my runs were usually easy runs. I tried a handful of times to do some “speed” work, but I often time was trying to keep my feet from being injured and it felt like running faster caused my feet to be sore or have other niggles in my legs, so I didn’t do much of that, other than doing some “cutback” long runs (around half marathon distance, as well as my last 21-mile run) at close to marathon pace to get a feel for how it felt to run at that pace for longer.

TLDR, again:

I signed up for a marathon in fall 2018 planning to run it in July 2019 but was thwarted by a broken ankle in January 2019 and COVID-19(/20) for 2020, so I ultimately trained for and ran it in July 2021. I am a slow runner, and I was able to achieve my sub-6 hour marathon goal using run-walk and without causing additional injury to my feet. And, because of my “slow” or less intense running, I needed a lot less fuel than is typically recommended for marathoners, and still managed my blood glucose levels within my ideal target ranges despite 5, 6, and even 7 hours run on my feet. Yes, you can run marathons with type 1 diabetes. And yes, you can run any length endurance runs with type 1 diabetes! I also ran a 50k ultramarathon using the same methods.

Understanding Automated Insulin Delivery: A basic book for kids, family, and friends of people living with diabetes

tl;dr – A new book out for kids explaining the basics of automated insulin delivery, using the analogy of scuba diving to explain how the system makes small changes in insulin delivery to manage glucose levels! Watch the narrated video free online, and if you find the analogy useful, it’s available in book form as both a physical, print book as well as on Kindle via Amazon.DanaMLewis_UnderstandingAutomatedInsulinDelivery_KidsBook—-

A few weeks ago I was thinking about what the basic things that I wanted people to know about automated insulin delivery. A good portion of the general public – and even many family members of people with diabetes – thinks that a traditional insulin pump does what an automated insulin delivery system does: adjusting insulin delivery based on continuous glucose monitor (CGM) data. But a traditional pump doesn’t necessarily know about the CGM data and isn’t equipped with the algorithm to make those decisions and changes to insulin delivery, so the person with diabetes is doing a LOT of invisible labor to try to manage glucose levels constantly 24/7/365. That’s why an automated insulin delivery system is so useful, and why I’ve been using a DIY system for more than 5 years. Now, though, we’re (finally) starting to see commercial systems come to market that does the basic functionality similar to what OpenAPS could do five years ago. I want more people to have access to these systems and use them as best as they can be used to give people the best outcomes diabetes-wise and the best quality of life they can possibly have. Helping explain to more people how this technology works is one way I can help do this, and thus an idea was born for another book to explain the basics of automated insulin delivery systems.

Dana's first rough sketch of the scuba diving analogy for explaining automated insulin deliveryI started with a basic sketch of an idea to run it by Scott and a few other people to test the idea. I’m not much for drawing, so it was a *very* rough sketch. But the analogy seemed to resonate, so I moved on to mocking up a basic version on the computer. (I went down a rabbit hole because I thought it would be neat to make an animated video for people to see and share online, to accompany the book. But I don’t know how to illustrate on the computer, let alone animate, so I tried an open source illustration program called Synfig, then several other illustrator programs that were open source to do the basic design to import into Synfig to animate, but then realized what I had in mind was so simple that basic transitions and animations in PowerPoint would suffice for my animated video.) PowerPoint is also how I’ve made my other children’s books for self-publishing, so it was easy to do a widescreen, video design version and then modify a version for the print size book of choice (I chose an 8.5×8.5 to make it easiest to hold and read). 

I went from a paper and pencil sketch on July 18 to mocking up the video animation and designing the print book and requesting printed proofs on July 23. The printed proofs were a bit slow to ship compared to usual (probably something to do with a global pandemic), and arrived on August 4. I reviewed, made a few small changes, and hit ‘publish’ the same day, and Amazon reviewed and approved both the Kindle version and the print version, which are now available today (August 5, 2020) online. It took less than 3 weeks to go from idea to printed book available for shipping worldwide! (I am sharing all these details to hopefully encourage someone else to self-publish if they have an idea for a book they’d like to see available in the world – feel free to reach out if you have any questions about self publishing!)

Print_DanaMLewis_UnderstandingAutomatedInsulinDeliveryKindle_Amazon_DanaMLewis_UnderstandingAutomatedInsulinDeliveryHere is the link to the print book on Amazon.

Here’s the link to the Kindle book version on Amazon – it’s also available as part of Kindle Unlimited and the Kindle Lending Library, so feel free to share it out!

DanaMLewis_UnderstandingAutomatedInsulinDelivery_kidsbook_TheEnd

Also, if you’re looking for something to do with your kids (or have your kids do), I also made some of the scuba diving designs into a coloring sheet – check them out here (downloads as a PDF).

DanaMLewis_freescubacoloringsheets