OpenAPS

Regulatory Approval Is A Red Herring

by Dana Lewis

One of the most common questions I have been asked over the last 8 years is whether or not we are submitting OpenAPS to the FDA for regulatory approval.

This question is a big red herring.

Regulatory approval is often seen and discussed as the one path for authenticating and validating safety and efficacy.

It’s not the only way.

It’s only one way.

—

As background, you need to understand what OpenAPS is. We took an already-approved insulin pump that I already had, a continuous glucose monitor (CGM) that I already had, and found a way to read data from those devices and also to use the already-built commands in the pump to send back instructions to automate insulin delivery via the decision-making algorithm that we created. The OpenAPS algorithm was the core innovation, along with the realization that this already-approved pump had those capabilities built in. We used various off the shelf hardware (mini-computers and radio communication boards) to interoperate with my already approved medical devices. There was novelty in how we put all the pieces together, though the innovation was the algorithm itself.

The caveat, though, is that although the pump I was using was regulatory-approved and on the market, which is how I already had it, it had later been recalled after researchers, the manufacturer, and the FDA realized that you could use the already-built commands in the pump’s infrastructure. So these pumps, while not causing harm to anyone and no cases of harm have ever been recorded, were no longer being sold. It wasn’t a big deal to the company; it was a voluntary recall, and people like me often chose to keep our pumps if we were not concerned about this potential risk.

We had figured out how to interoperate with these other devices. We could have taken our system to the FDA. But because we were using already-off-the-market pumps, there was no way the FDA would approve it. And at the time (circa 2014), there was no vision or pathway for interoperable devices, so they didn’t have the infrastructure to approve “just” an automated insulin delivery algorithm. (That changed many years later and they now have infrastructure for reviewing interoperable pumps, CGM, and algorithms which they call controllers).

The other relevant fact is that the FDA has jurisdiction based on the commerce clause in the US Constitution: Congress used its authority to authorize the FDA to regulate interstate commerce in food, drugs, and medical devices. So if you’re intending to be a commercial entity and sell products, you must submit for regulatory approval.

But if you’re not going to sell products…

This is the other aspect that many people don’t seem to understand. All roads do not lead to regulatory approval because not everyone wants to create a company and spend 5+ years dedicating all their time to it. That’s what we would have had to do in order to have a company to try to pursue regulatory approval.

And the key point is: given such a strict regulatory environment, we (speaking for Dana and Scott) did not want to commercialize anything. Therefore there was no point in submitting for regulatory approval. Regardless of whether or not the FDA was likely to approve given the situation at the time, we did not want to create a company, spend years of our life dealing with regulatory and compliance issues full time, and maybe eventually get permission to sell a thing (that we didn’t care about selling).

The aspect of regulatory approval is a red herring in the story of the understanding of OpenAPS and the impact it is having and could have.

Yes, we could have created a company. But then we would not have been able to spend the thousands of hours that we spent improving the system we made open source and helping thousands of individuals who were able to use the algorithm and subsequent systems with a variety of pumps, CGMs, and mobile devices as an open source automated insulin delivery system. We intentionally chose this path to not commercialize and thus not to pursue regulatory approval.

—

As a result of our work (and others from the community), the ecosystem has now changed.

Time has also passed: it’s been 8 years since I first automated insulin delivery for myself!

The commercial players have brought multiple commercial AIDs to market now, too.

We created OpenAPS when there was NO commercial option at the time. Now there are a few commercial options.

But it is also an important note that I, and many thousands of other people, are still choosing to use open source AID systems.

Why?

This is another aspect of the red herring of regulatory approval.

Just because something is approved does not mean it’s available to order.

If it’s available to order (and not all countries have approved AID systems!), it doesn’t mean it’s accessible or affordable.

Insurance companies are still fighting against covering pumps and CGMs as standalone devices. New commercial AID systems are even more expensive, and the insurance companies are fighting against coverage for them, too. So just because someone wants an AID and has one approved in their country doesn’t mean that they will be able to access and/or afford it. Many people with diabetes struggle with the cost of insulin, or the cost of CGM and/or their insulin pump.

Sometimes providers refuse to prescribe devices, based on preconceived notions (and biases) about who might do “well” with new therapies based on past outcomes with different therapies.

For some, open source AID is still the most accessible and affordable option.

And in some places, it is still the ONLY option available to automate insulin delivery.

(And in most places, open source AID is still the most advanced, flexible, and customizable option.)

—

Understanding the many reasons why someone might choose to use open source automated insulin delivery folds back into the understanding of how someone chooses to use open source automated insulin delivery.

It is tied to the understanding that manual insulin delivery – where someone makes all the decisions themselves and injects or presses buttons manually to deliver insulin – is inherently risky.

Automated insulin delivery reduces risk compared to manual insulin delivery. While some new risk is introduced (as is true of any additional devices), the net risk reduction overall is significantly large compared to manual insulin delivery.

This net risk reduction is important to contextualize.

Without automated insulin delivery, people overdose or underdose on insulin multiple times a day, causing adverse effects and bad outcomes and decreasing their quality of life. Even when they’re doing everything right, this is inevitable because the timing of insulin is so challenging to manage alongside dozens of other variables that at every decision point play a role in influencing the glucose outcomes.

With open source automated insulin delivery, it is not a single point-in-time decision to use the system.

Every moment, every day, people are actively choosing to use their open source automated insulin delivery system because it is better than the alternative of managing diabetes manually without automated insulin delivery.

It is a conscious choice that people make every single day. They could otherwise choose to not use the automated components and “fall back” to manual diabetes care at any moment of the day or night if they so choose. But most don’t, because it is safer and the outcomes are better with automated insulin delivery.

Each individual’s actions to use open source AID on an ongoing basis are data points on the increased safety and efficacy.

—

However, this paradigm of patient-generated data and patient choice as data contributing toward safety and efficacy is new. There are not many, if any, other examples of patient-developed technology that does not go down the commercial path, so there are not a lot of comparisons for open source AID systems.

As a result, when there were questions about the safety and efficacy of the system (e.g., “how do you know it works for someone else other than you, Dana?”), we began to research as a community to address the questions. We published data at the world’s biggest scientific conference and were peer-reviewed by scientists and accepted to present a poster. We did so. We were cited in a piece in Nature as a result. We then were invited to submit a letter to the editor of a traditional diabetes journal to summarize our findings; we did so and were published.

I then waited for the rest of the research community to pick up this lead and build on the work…but they didn’t. I picked it up again and began facilitating research directly with the community, coordinating efforts to make anonymized pools of data for individuals with open source AID to submit their data to and for years have facilitated access to dozens of researchers to use this data for additional research. This has led to dozens of publications further documenting the efficacy of these solutions.

Yet still, there was concern around safety because the healthcare world didn’t know how to assess these patient-generated data points of choice to use this system because it was better than the alternative every single day.

So finally, as a direct result of presenting this community-based research again at the world’s largest diabetes scientific conference, we were able to collaborate and design a grant proposal that received grant funding from New Zealand’s Health Research Council (the equivalent of the NIH in the US) for a randomized control trial of the OpenAPS algorithm in an open source AID system.

An RCT is often seen as the gold standard in science, so the fact that we received funding for such a study alone was a big milestone.

And this year, in 2022, the RCT was completed and our findings were published in one of the world’s largest medical journals, the New England Journal of Medicine, establishing that the use of the OpenAPS algorithm in an open source AID was found to be safe and effective in children and adults.

No surprises here, though. I’ve been using this system for more than 8 years, and seeing thousands of others choose the OpenAPS algorithm on an ongoing, daily basis for similar reasons.

—

So today, it is possible that someone could take an open source AID system using the OpenAPS algorithm to the FDA for regulatory approval. It won’t likely be me, though.

Why not? The same reasons apply from 8 years ago: I am not a company, I don’t want to create a company to be able to sell things to end users. The path to regulatory approval primarily matters for those who want to sell commercial products to end users.

Also, regulatory approval (if someone got the OpenAPS algorithm in an open source AID or a different algorithm in an open source AID) does not mean it will be commercially available, even if it will be approved.

It requires a company that has pumps and CGMs it can sell alongside the AID system OR commercial partnerships ready to go that are able to sell all of the interoperable, approved components to interoperate with the AID system.

So regulatory approval of an AID system (algorithm/mobile controller design) without a commercial partnership plan ready to go is not very meaningful to people with diabetes in and of itself. It sounds cool, but will it actually do anything? In and of itself, no.

Thus, the red herring.

Might it be meaningful eventually? Yes, possibly, especially if we collectively have insurers to get over themselves and provide coverage for AID systems given that AID systems all massively improve short-term and long-term outcomes for people with diabetes.

But as I said earlier, regulatory approval does necessitate access nor affordability, so an approved system that’s not available and affordable to people is not a system that can be used by many.

We have a long way to go before commercial AID systems are widely accessible and affordable, let alone available in every single country for people with diabetes worldwide.

Therefore, regulatory approval is only one piece of this puzzle.

And it is not the only way to assess safety and efficacy.

—

The bigger picture this has shown me over the years is that while systems are created to reduce harm toward people – and this is valid and good – there have been tendencies to convert to the assumption that therefore the systems are the only way to achieve the goal of harm reduction or to assess safety and efficacy.

They aren’t the only way.

As explained above, FDA approval is one method of creating a rubber stamp as a shorthand for “is this considered to be safe and effective”.

That’s also legally necessary for companies to use if they want to sell products. For situations that aren’t selling products, it’s not the only way to assess safety and efficacy, which we have shown with OpenAPS.

With open source automated insulin delivery systems, individuals have access to every line of code and can test and choose for themselves, not just once, but every single day, whether they consider it to be safer and more effective for them than manual insulin dosing. Instead of blindly trusting a company, they get the choice to evaluate what they’re using in a different way – if they so choose.

—

So any questions around seeking regulatory approval are red herrings.

A different question might be: What’s the future of the OpenAPS algorithm?

The answer is written in our OpenAPS plain language reference design that we posted in February of 2015. We detailed our vision for individuals like us, researchers, and companies to be able to use it in the future.

And that’s how it’s being used today, by 1) people like me; and 2)  in research, to improve what we can learn about diabetes itself and improve AID; and 3) by companies, one of whom has already incorporated parts of our safety design as part of a safety layer in their ML-based AID system and has CE mark approval and is being sold and used by thousands of people in Europe.

It’s possible that someone will take it for regulatory approval; but that’s not necessary for the thousands of people already using it. That may or may not make it more available for thousands more (see earlier caveats about needing commercial partnerships to be able to interoperate with pumps and CGMs).

And regardless, it is still being used to change the world for thousands of people and help us learn and understand new things about the physiology of diabetes because of the way it was designed.

That’s how it’s been used and that’s the future of how it will continue to be used.

No rubber stamps required.

Regulatory Approval: A Red Herring

Understanding the Difference Between Open Source and DIY in Diabetes

by Dana Lewis

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

by Dana Lewis

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

NEJM Publishes RCT On Open Source Automated Insulin Delivery (OpenAPS Algorithm in AndroidAPS in the CREATE TRIAL)

by Dana Lewis

First page of NEJM article on Open Source AID in T1D, which contains the text of the abstract. I’m thrilled to share that the results of the first RCT on open source automated insulin delivery (AID) is now published in a peer-reviewed medical journal (New England Journal of Medicine, known as NEJM). You can find it at NEJM here, or view an author copy here. You can also see a Twitter post here, if you are interested in sharing the study with your networks.

(I previously wrote a plain language summary of the study results after they were presented at ADA Scientific Sessions in June. You can read the plain language summary here, if you haven’t already seen it.)

I wanted to highlight a key few takeaway messages from the study:

  • 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!
  • The CREATE study also found that the greatest improvements in time in range (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. 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.

I’d also like to highlight some meta aspects of this trial and the significance of these results being published in NEJM.

The algorithm (open source, from OpenAPS) used in the trial, as well as the open source app (AndroidAPS) used to automate insulin delivery, were built by people with diabetes and their loved ones. The algorithm/initial AID work was made open source so other people with diabetes could use it if they chose to, but also so that researchers and clinicians could research it, learn from it, use it, etc. Speaking on behalf of Scott (Leibrand) who worked with me endlessly to iterate upon the algorithm and then also Ben West whose work was critical in communicating with insulin pumps and putting the pieces together into the first open source “closed loop” automated insulin delivery system: we all wanted this to be open source for many reasons. You’ll see some of those reasons listed at the bottom of the plain language OpenAPS “reference design” we shared with the world in February 2015. And it is exceptionally thrilling to see it go from n=1 (me, as the first user) to thousands worldwide using it and other open source AID systems over the years, and be studied further in the “gold standard” setting of an RCT to validate the real-world outcomes that people with diabetes have experienced with open source AID.

But these results are not new to those of us using these systems. These results every day are WHY we use and continue to choose each day to use these systems. This study highlights just a fraction of the benefits people with diabetes experience with AID. Over the years, I’ve heard any of the following reasons why people have chosen to use open source AID:

  • It’s peaceful and safer sleep with less fear of dying.
  • It’s the ability to imagine a future where they live to see their children grow up.
  • It’s the ability to manage glucose levels more effectively so they can more easily plan for or manage the process of having children.
  • It’s less time spent doing physical diabetes tasks throughout the days, weeks, and years.
  • It’s less time spent thinking about diabetes, diabetes-related short-term tasks, and the long-term aspects of living with diabetes.

All of this would not be possible without hundreds of volunteer contributors and developers who iterated upon the algorithm; adapted the concept into different formats (e.g. Milos Kozak’s work to develop AndroidAPS using the OpenAPS algorithm); wrote documentation; troubleshot and tested with different pumps, CGMs, hardware, phones, software, timezones, etc; helped others interested in using these systems; etc. There are many unsung heroes among this community of people with diabetes (and you can hear more of their stories and other milestones in the open source diabetes community in a previous presentation I gave here).

There are thousands of hours of work behind this open source technology which led to the trial which led to these results and this publication. Both the results and the fact of its publication in the NEJM are meaningful. This is technology developed by people with diabetes (and their loved ones) for people with diabetes, which more people will now learn is an option; it will fuel additional conversations with healthcare providers who support people with diabetes; and it will likely spur additional research and energy in the ongoing development of diabetes technologies.

From developers, to community contributors and community members, to the study team and staff who made this trial happen, to the participants in the trial, and to the peer reviewers and editor(s) who reviewed and recommended accepting the now-published article in the New England Journal of Medicine:

Thank you.

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

by Dana Lewis

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)

by Dana Lewis

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

AID (APS) book now available in French!

by Dana Lewis

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

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

by Dana Lewis

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

by Dana Lewis

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

Poster and presentation content from @DanaMLewis at #ADA2020 and #DData20

by Dana Lewis

In previous years (see 2019 and 2018), I mentioned sharing content from ADA Scientific Sessions (this year it’s #ADA2020) with those not physically present at the conference. This year, NO ONE is present at the event, and we’re all virtual! Even more reason to share content from the conference. 🙂

I contributed to and co-authored two different posters at Scientific Sessions this year:

  • “Multi-Timescale Interactions of Glucose and Insulin in Type 1 Diabetes Reveal Benefits of Hybrid Closed Loop Systems“ (poster 99-LB) along with Azure Grant and Lance Kriegsfeld, PhD.
  • “Do-It-Yourself Artificial Pancreas Systems for Type 1 Diabetes Reduce Hyperglycemia Without Increasing Hypoglycemia” (poster 988-P in category 12-D Clinical Therapeutics/New Technology—Insulin Delivery Systems), alongside Jennifer Zabinsky, MD MEng, Haley Howell, MSHI, Alireza Ghezavati, MD, Andrew Nguyen, PhD, and Jenise Wong, MD PhD.

And, while not a poster at ADA, I also presented the “AID-IRL” study funded by DiabetesMine at #DData20, held in conjunction with Scientific Sessions. A summary of the study is also included in this post.

—

First up, the biological rhythms poster, “Multi-Timescale Interactions of Glucose and Insulin in Type 1 Diabetes Reveal Benefits of Hybrid Closed Loop Systems” (poster 99-LB). (Twitter thread summary of this poster here.)

Building off our work as detailed last year, Azure, Lance, and I have been exploring the biological rhythms in individuals living with type 1 diabetes. Why? It’s not been done before, and we now have the capabilities thanks to technology (pumps, CGM, and closed loops) to better understand how glucose and insulin dynamics may be similar or different than those without diabetes.

Background:

Mejean et al., 1988Blood glucose and insulin exhibit coupled biological rhythms at multiple timescales, including hours (ultradian, UR) and the day (circadian, CR) in individuals without diabetes. The presence and stability of these rhythms are associated with healthy glucose control in individuals without diabetes. (See right, adapted from Mejean et al., 1988).

However, biological rhythms in longitudinal (e.g., months to years) data sets of glucose and insulin outputs have not been mapped in a wide population of people with Type 1 Diabetes (PWT1D). It is not known how glucose and insulin rhythms compare between T1D and non-T1D individuals. It is also unknown if rhythms in T1D are affected by type of therapy, such as Sensor Augmented Pump (SAP) vs. Hybrid Closed Loop (HCL). As HCL systems permit feedback from a CGM to automatically adjust insulin delivery, we hypothesized that rhythmicity and glycemia would exhibit improvements in HCL users compared to SAP users. We describe longitudinal temporal structure in glucose and insulin delivery rate of individuals with T1D using SAP or HCL systems in comparison to glucose levels from a subset of individuals without diabetes.

Data collection and analysis:

We assessed stability and amplitude of normalized continuous glucose and insulin rate oscillations using the continuous wavelet transformation and wavelet coherence. Data came from 16 non-T1D individuals (CGM only, >2 weeks per individual) from the Quantified Self CGM dataset and 200 (n = 100 HCL, n = 100 SAP; >3 months per individual) individuals from the Tidepool Big Data Donation Project. Morlet wavelets were used for all analyses. Data were analyzed and plotted using Matlab 2020a and Python 3 in conjunction with in-house code for wavelet decomposition modified from the “Jlab” toolbox, from code developed by Dr. Tanya Leise (Leise 2013), and from the Wavelet Coherence toolkit by Dr. Xu Cui. Linear regression was used to generate correlations, and paired t-tests were used to compare AUC for wavelet and wavelet coherences by group (df=100). Stats used 1 point per individual per day.

Wavelets Assess Glucose and Insulin Rhythms and Interactions

Wavelet Coherence flow for glucose and insulin

Morlet wavelets (A) estimate rhythmic strength in glucose or insulin data at each minute in time (a combination of signal amplitude and oscillation stability) by assessing the fit of a wavelet stretched in window and in the x and y dimensions to a signal (B). The output (C) is a matrix of wavelet power, periodicity, and time (days). Transform of example HCL data illustrate the presence of predominantly circadian power in glucose, and predominantly 1-6 h ultradian power in insulin. Color map indicates wavelet power (synonymous with Y axis height). Wavelet coherence (D) enables assessment of rhythmic interactions between glucose and insulin; here, glucose and insulin rhythms are highly correlated at the 3-6 (ultradian) and 24 (circadian) hour timescales.

Results:

Hybrid Closed Loop Systems Reduce Hyperglycemia

Glucose distribution of SAP, HCL, and nonT1D
  • A) Proportional counts* of glucose distributions of all individuals with T1D using SAP (n=100) and HCL (n=100) systems. SAP system users exhibit a broader, right shifted distribution in comparison to individuals using HCL systems, indicating greater hyperglycemia (>7.8 mmol/L). Hypoglycemic events (<4mmol/L) comprised <5% of all data points for either T1D dataset.
  • B) Proportional counts* of non-T1D glucose distributions. Although limited in number, our dataset from people without diabetes exhibits a tighter blood glucose distribution, with the vast majority of values falling in euglycemic range (n=16 non-T1D individuals).
  • C) Median distributions for each dataset.
  • *Counts are scaled such that each individual contributes the same proportion of total data per bin.

HCL Improves Correlation of Glucose-Insulin Level & Rhythm

Glucose and Insulin rhythms in SAP and HCL

SAP users exhibit uncorrelated glucose and insulin levels (A) (r2 =3.3*10-5; p=0.341) and uncorrelated URs of glucose and insulin (B) (r2 =1.17*10-3; p=0.165). Glucose and its rhythms take a wide spectrum of values for each of the standard doses of insulin rates provided by the pump, leading to the striped appearance (B). By contrast, Hybrid Closed Loop users exhibit correlated glucose and insulin levels (C) (r2 =0.02; p=7.63*10-16), and correlated ultradian rhythms of glucose and insulin (D) (r2 =-0.13; p=5.22*10-38). Overlays (E,F).

HCL Results in Greater Coherence than SAP

Non-T1D individuals have highly coherent glucose and insulin at the circadian and ultradian timescales (see Mejean et al., 1988, Kern et al., 1996, Simon and Brandenberger 2002, Brandenberger et al., 1987), but these relationships had not previously been assessed long-term in T1D.

coherence between glucose and insulin in HCL and SAP, and glucose swings between SAP, HCL, and non-T1DA) Circadian (blue) and 3-6 hour ultradian (maroon) coherence of glucose and insulin in HCL (solid) and SAP (dotted) users. Transparent shading indicates standard deviation. Although both HCL and SAP individuals have lower coherence than would be expected in a non-T1D individual,  HCL CR and UR coherence are significantly greater than SAP CR and UR coherence (paired t-test p= 1.51*10-7 t=-5.77 and p= 5.01*10-14 t=-9.19, respectively). This brings HCL users’ glucose and insulin closer to the canonical non-T1D phenotype than SAP users’.

B) Additionally, the amplitude of HCL users’ glucose CRs and URs (solid) is closer (smaller) to that of non-T1D (dashed) individuals than are SAP glucose rhythms (dotted). SAP CR and UR amplitude is significantly higher than that of HCL or non-T1D (T-test,1,98, p= 47*10-17 and p= 5.95*10-20, respectively), but HCL CR amplitude is not significantly different from non-T1D CR amplitude (p=0.61).

Together, HCL users are more similar than SAP users to the canonical Non-T1D phenotype in A) rhythmic interaction between glucose and insulin and B) glucose rhythmic amplitude.

Conclusions and Future Directions

T1D and non-T1D individuals exhibit different relative stabilities of within-a-day rhythms and daily rhythms in blood glucose, and T1D glucose and insulin delivery rhythmic patterns differ by insulin delivery system.

Hybrid Closed Looping is Associated With:

  • Lower incidence of hyperglycemia
  • Greater correlation between glucose level and insulin delivery rate
  • Greater correlation between ultradian glucose and ultradian insulin delivery rhythms
  • Greater degree of circadian and ultradian coherence between glucose and insulin delivery rate than in SAP system use
  • Lower amplitude swings at the circadian and ultradian timescale

These preliminary results suggest that HCL recapitulates non-diabetes glucose-insulin dynamics to a greater degree than SAP. However, pump model, bolusing data, looping algorithms and insulin type likely all affect rhythmic structure and will need to be further differentiated. Future work will determine if stability of rhythmic structure is associated with greater time in range, which will help determine if bolstering of within-a-day and daily rhythmic structure is truly beneficial to PWT1D.
Acknowledgements:

Thanks to all of the individuals who donated their data as part of the Tidepool Big Data Donation Project, as well as the OpenAPS Data Commons, from which data is also being used in other areas of this study. This study is supported by JDRF (1-SRA-2019-821-S-B).

(You can download a full PDF copy of the poster here.)

—

Next is “Do-It-Yourself Artificial Pancreas Systems for Type 1 Diabetes Reduce Hyperglycemia Without Increasing Hypoglycemia” (poster 988-P in category 12-D Clinical Therapeutics/New Technology—Insulin Delivery Systems), which I co-authored alongside Jennifer Zabinsky, MD MEng, Haley Howell, MSHI, Alireza Ghezavati, MD, Andrew Nguyen, PhD, and Jenise Wong, MD PhD. There is a Twitter thread summarizing this poster here.

This was a retrospective double cohort study that evaluated data from the OpenAPS Data Commons (data ranged from 2017-2019) and compared it to conventional sensor-augmented pump (SAP) therapy from the Tidepool Big Data Donation Project.

Methods:

  • From the OpenAPS Data Commons, one month of CGM data (with more than 70% of the month spent using CGM), as long as they were >1 year of living with T1D, was used. People could be using any type of DIYAPS (OpenAPS, Loop, or AndroidAPS) and there were no age restrictions.
  • A random age-matched sample from the Tidepool Big Data Donation Project of people with type 1 diabetes with SAP was selected.
  • The primary outcome assessed was percent of CGM data <70 mg/dL.
  • The secondary outcomes assessed were # of hypoglycemic events per month (15 minutes or more <70 mg/dL); percent of time in range (70-180mg/dL); percent of time above range (>180mg/dL), mean CGM values, and coefficient of variation.
Methods_DIYAPSvsSAP_ADA2020_DanaMLewis

Demographics:

  • From Table 1, this shows the age of participants was not statistically different between the DIYAPS and SAP cohorts. Similarly, the age at T1D diagnosis or time since T1D diagnosis did not differ.
  • Table 2 shows the additional characteristics of the DIYAPS cohort, which included data shared by a parent/caregiver for their child with T1D. DIYAPS use was an average of 7 months, at the time of the month of CGM used for the study. The self-reported HbA1c in DIYAPS was 6.4%.
Demographics_DIYAPSvsSAP_ADA2020_DanaMLewis DIYAPS_Characteristics_DIYAPSvsSAP_ADA2020_DanaMLewis

Results:

  • Figure 1 shows the comparison in outcomes based on CGM data between the two groups. Asterisks (*) indicate statistical significance.
  • There was no statistically significant difference in % of CGM values below 70mg/dL between the groups in this data set sampled.
  • DIYAPS users had higher percent in target range and lower percent in hyperglycemic range, compared to the SAP users.
  • Table 3 shows the secondary outcomes.
  • There was no statistically significant difference in the average number of hypoglycemic events per month between the 2 groups.
  • The mean CGM glucose value was lower for the DIYAPS group, but the coefficient of variation did not differ between groups.
CGM_Comparison_DIYAPSvsSAP_ADA2020_DanaMLewis SecondaryOutcomes_DIYAPSvsSAP_ADA2020_DanaMLewis

Conclusions:

    • Users of DIYAPS (from this month of sampled data) had a comparable amount of hypoglycemia to those using SAP.
    • Mean CGM glucose and frequency of hyperglycemia were lower in the DIYAPS group.
    • Percent of CGM values in target range (70-180mg/dL) was significantly greater for DIYAPS users.
    • This shows a benefit in DIYAPS in reducing hyperglycemia without compromising a low occurrence of hypoglycemia. 
Conclusions_DIYAPSvsSAP_ADA2020_DanaMLewis

(You can download a PDF of the e-poster here.)

—

Finally, my presentation at this year’s D-Data conference (#DData20). The study I presented, called AID-IRL, was funded by Diabetes Mine. You can see a Twitter thread summarizing my AID-IRL presentation here.

AID-IRL-Aim-Methods_DanaMLewis

I did semi-structured phone interviews with 7 users of commercial AID systems in the last few months. The study was funded by DiabetesMine – both for my time in conducting the study, as well as funding for study participants. Study participants received $50 for their participation. I sought a mix of longer-time and newer AID users, using a mix of systems. Control-IQ (4) and 670G (2) users were interviewed; as well as (1) a CamAPS FX user since it was approved in the UK during the time of the study.

Based on the interviews, I coded their feedback for each of the different themes of the study depending on whether they saw improvements (or did not have issues); had no changes but were satisfied, or neutral experiences; or saw negative impact/experience. For each participant, I reviewed their experience and what they were happy with or frustrated by.

Here are some of the details for each participant.

AID-IRL-Participant1-DanaMLewisAID-IRL-Participant1-cont_DanaMLewis1 – A parent of a child using Control-IQ (off-label), with 30% increase in TIR with no increased hypoglycemia. They spend less time correcting than before; less time thinking about diabetes; and “get solid uninterrupted sleep for the first time since diagnosis”. They wish they had remote bolusing, more system information available in remote monitoring on phones. They miss using the system during the 2 hour CGM warmup, and found the system dealt well with growth spurt hormones but not as well with underestimated meals.

AID-IRL-Participant2-DanaMLewis AID-IRL-Participant2-cont-DanaMLewis2 – An adult male with T1D who previously used DIYAPS saw 5-10% decrease in TIR (but it’s on par with other participants’ TIR) with Control-IQ, and is very pleased by the all-in-one convenience of his commercial system.He misses autosensitivity (a short-term learning feature of how insulin needs may very from base settings) from DIYAPS and has stopped eating breakfast, since he found it couldn’t manage that well. He is doing more manual corrections than he was before.

AID-IRL-Participant5-DanaMLewis AID-IRL-Participant5-cont_DanaMLewis5 – An adult female with LADA started, stopped, and started using Control-IQ, getting the same TIR that she had before on Basal-IQ. It took artificially inflating settings to achieve these similar results. She likes peace of mind to sleep while the system prevents hypoglycemia. She is frustrated by ‘too high’ target; not having low prevention if she disables Control-IQ; and how much she had to inflate settings to achieve her outcomes. It’s hard to know how much insulin the system gives each hour (she still produces some of own insulin).

AID-IRL-Participant7-DanaMLewis AID-IRL-Participant7-cont-DanaMLewis7 – An adult female with T1D who frequently has to take steroids for other reasons, causing increased BGs. With Control-IQ, she sees 70% increase in TIR overall and increased TIR overnight, and found it does a ‘decent job keeping up’ with steroid-induced highs. She also wants to run ‘tighter’ and have an adjustable target, and does not ever run in sleep mode so that she can always get the bolus corrections that are more likely to bring her closer to target.

AID-IRL-Participant3-DanaMLewis AID-IRL-Participant3-cont-DanaMLewis3 – An adult male with T1D using 670G for 3 years didn’t observe any changes to A1c or TIR, but is pleased with his outcomes, especially with the ability to handle his activity levels by using the higher activity target.  He is frustrated by the CGM and is woken up 1-2x a week to calibrate overnight. He wishes he could still have low glucose suspend even if he’s kicked out of automode due to calibration issues. He also commented on post-meal highs and more manual interventions.

AID-IRL-Participant6-DanaMLewis AID-IRL-Participant6-contDanaMLewis6 – Another adult male user with 670G was originally diagnosed with T2 (now considered T1) with a very high total daily insulin use that was able to decrease significantly when switching to AID. He’s happy with increased TIR and less hypo, plus decreased TDD. Due to #COVID19, he did virtually training but would have preferred in-person. He has 4-5 alerts/day and is woken up every other night due to BG alarms or calibration. He does not like the time it takes to charge CGM transmitter, in addition to sensor warmup.

AID-IRL-Participant4-DanaMLewis AID-IRL-Participant4-contDanaMLewis4 – The last participant is an adult male with T1 who previously used DIYAPS but was able to test-drive the CamAPS FX. He saw no TIR change to DIYAPS (which pleased him) and thought the learning curve was easy – but he had to learn the system and let it learn him. He experienced ‘too much’ hypoglycemia (~7% <70mg/dL, 2x his previous), and found it challenging to not have visibility of IOB. He also found the in-app CGM alarms annoying. He noted the system may work better for people with regular routines.

You can see a summary of the participants’ experiences via this chart. Overall, most cited increased or same TIR. Some individuals saw reduced hypos, but a few saw increases. Post-meal highs were commonly mentioned.

AID-IRL-UniversalThemes2-DanaMLewis AID-IRL-UniversalThemes-DanaMLewis

Those newer to CGM have a noticeable learning curve and were more likely to comment on number of alarms and system alerts they saw. The 670G users were more likely to describe connection/troubleshooting issues and CGM calibration issues, both of which impacted sleep.

This view highlights those who more recently adopted AID systems. One noted their learning experience was ‘eased’ by “lurking” in the DIY community, and previously participating in an AID study. One felt the learning curve was high. Another struggled with CGM.

AID-IRL-NewAIDUsers-DanaMLewis

Both previous DIYAPS users who were using commercial AID systems referenced the convenience factor of commercial systems. One DIYAPS saw decreased TIR, and has also altered his behaviors accordingly, while the other saw no change to TIR but had increased hypo’s.

AID-IRL-PreviousDIYUsers-DanaMLewis

Companies building AID systems for PWDs should consider that the onboarding and learning curve may vary for individuals, especially those newer to CGM. Many want better displays of IOB and the ability to adjust targets. Remote bolusing and remote monitoring is highly desired by all, regardless of age. Post-prandial was frequently mentioned as the weak point in glycemic control of commercial AID systems. Even with ‘ideal’ TIR, many commercial users still are doing frequent manual corrections outside of mealtimes. This is an area of improvement for commercial AID to further reduce the burden of managing diabetes.

AID-IRL-FeedbackForCompanies-DanaMLewis

Note – all studies have their limitations. This was a small deep-dive study that is not necessarily representative, due to the design and small sample size. Timing of system availability influenced the ability to have new/longer time users.

AID-IRL-Limitations-DanaMLewis

Thank you to all of the participants of the study for sharing their feedback about their experiences with AID-IRL!

(You can download a PDF of my slides from the AID-IRL study here.)

—

Have questions about any of my posters or presentations? You can always reach me via email at Dana@OpenAPS.org.