Functional Self-Tracking is The Only Self-Tracking I Do

“I could never do that,” you say.

And I’ve heard it before.

Eating gluten free for the rest of your life, because you were diagnosed with celiac disease? Heard that response (I could never do that) for going on 14 years.

Inject yourself with insulin or fingerstick test your blood glucose 14 times a day? Wear an insulin pump on your body 24/7/365? Wear a CGM on your body 24/7/365?

Yeah, I’ve heard you can’t do that, either. (For 20 years and counting.) Which means I and the other people living with the situations that necessitate these behaviors are…doing this for fun?

We’re not.

More recently, I’ve heard this type of comment come up about tracking what I’m eating, and in particular, tracking what I’m eating when I’m running. I definitely don’t do that for fun.

I have a 20+ year strong history of hating tracking things, actually. When I was diagnosed with type 1 diabetes, I was given a physical log book and asked to write down my blood glucose numbers.

“Why?” I asked. They’re stored in the meter.

The answer was because supposedly the medical team was going to review them.

And they did.

And it was useless.

“Why were you high on February 22, 2003?”

Whether we were asking this question in March of 2003 or January of 2023 (almost 20 years later), the answer would be the same: I have no idea.

BG data, by itself, is like a single data point for a pilot. It’s useless without the contextual stream of data as well as other metrics (in the diabetes case, things like what was eaten, what activity happened, what my schedule was before this point, and all insulin dosed potentially in the last 12-24h).

So you wouldn’t be surprised to find out that I stopped tracking. I didn’t stop testing my blood glucose levels – in fact, I tested upwards of 14 times a day when I was in high school, because the real-time information was helpful. Retrospectively? Nope.

I didn’t start “tracking” things again (for diabetes) until late 2013, when we realized that I could get my CGM data off the device and into the laptop beside my bed, dragging the CGM data into a CSV file in Dropbox and sending it to the cloud so an app called “Pushover” would make a louder and different alarm on my phone to wake me up to overnight hypoglycemia. The only reason I added any manual “tracking” to this system was because we realized we could create an algorithm to USE the information I gave it (about what I was eating and the insulin I was taking) combined with the real-time CGM data to usefully predict glucose levels in the future. Predictions meant we could make *predictive* alarms, instead of solely having *reactive* alarms, which is what the status quo in diabetes has been for decades.

So sure, I started tracking what I was eating and dosing, but not really. I was hitting buttons to enter this information into the system because it was useful, again, in real time. I didn’t bother doing much with the data retrospectively. I did occasional do things like reflect on my changes in sensitivity after I got the norovirus, for example, but again this was mostly looking in awe at how the real-time functionality of autosensitivity, an algorithm feature we designed to adjust to real-time changes in sensitivity to insulin, dealt throughout the course of being sick.

At the beginning of 2020, my life changed. Not because of the pandemic (although also because of that), but because I began to have serious, very bothersome GI symptoms that dragged on throughout 2020 and 2021. I’ve written here about my experiences in eventually self-diagnosing (and confirming) that I have exocrine pancreatic insufficiency, and began taking pancreatic enzyme replacement therapy in January 2022.

What I haven’t yet done, though, is explain all my failed attempts at tracking things in 2020 and 2021. Or, not failed attempts, but where I started and stopped and why those tracking attempts weren’t useful.

Once I realized I had GI symptoms that weren’t going away, I tried writing down everything I ate. I tried writing in a list on my phone in spring of 2020. I couldn’t see any patterns. So I stopped.

A few months later, in summer of 2020, I tried again, this time using a digital spreadsheet so I could enter data from my phone or my computer. Again, after a few days, I still couldn’t see any patterns. So I stopped.

I made a third attempt to try to look at ingredients, rather than categories of food or individual food items. I came up with a short list of potential contenders, but repeated testing of consuming those ingredients didn’t do me any good. I stopped, again.

When I first went to the GI doctor in fall of 2020, one of the questions he asked was whether there was any pattern between my symptoms and what I was eating. “No,” I breathed out in a frustrated sigh. “I can’t find any patterns in what I’m eating and the symptoms.”

So we didn’t go down that rabbit hole.

At the start of 2021, though, I was sick and tired (of being sick and tired with GI symptoms for going on a year) and tried again. I decided that some of my “worst” symptoms happened after I consumed onions, so I tried removing obvious sources of onion from my diet. That evolved to onion and garlic, but I realized almost everything I ate also had onion powder or garlic powder, so I tried avoiding those. It helped, some. That then led me to research more, learn about the categorization of FODMAPs, and try a low-FODMAP diet in mid/fall 2021. That helped some.

Then I found out I actually had exocrine pancreatic insufficiency and it all made sense: what my symptoms were, why they were happening, and why the numerous previous tracking attempts were not successful.

You wouldn’t think I’d start tracking again, but I did. Although this time, finally, was different.

When I realized I had EPI, I learned that my body was no longer producing enough digestive enzymes to help my body digest fat, protein, and carbs. Because I’m a person with type 1 diabetes and have been correlating my insulin doses to my carbohydrate consumption for 20+ years, it seemed logical to me to track the amount of fat and protein in what I was eating, track my enzyme (PERT) dosing, and see if there were any correlations that indicated my doses needed to be more or less.

My spreadsheet involved recording the outcome of the previous day’s symptoms, and I had a section for entering multiple things that I ate throughout the day and the number of enzymes. I wrote a short description of my meal (“butter chicken” or “frozen pizza” or “chicken nuggets and veggies”), the estimate of fat and protein counts for the meal, and the number of enzymes I took for that meal. I had columns on the left that added up the total amount of fat and protein for the day, and the total number of enzymes.

It became very apparent to me – within two days – that the dose of the enzymes relative to the quantity of fat and protein I was eating mattered. I used this information to titrate (adjust) my enzyme dose and better match the enzymes to the amount of fat or protein I was eating. It was successful.

I kept writing down what I was eating, though.

In part, because it became a quick reference library to find the “counts” of a previous meal that I was duplicating, without having to re-do the burdensome math of adding up all the ingredients and counting them out for a typical portion size.

It also helped me see that within the first month, I was definitely improving, but not all the way – in terms of fully reducing and eliminating all of my symptoms. So I continued to use it to titrate my enzyme doses.

Then it helped me carefully work my way through re-adding food items and ingredients that I had been avoiding (like onions, apples, and pears) and proving to my brain that those were the result of enzyme insufficiency, not food intolerances. Once I had a working system for determining how to dose enzymes, it became a lot easier to see when I had slight symptoms from slightly getting my dosing wrong or majorly mis-estimating the fat and protein in what I was eating.

It provided me with a feedback loop that doesn’t really exist in EPI and GI conditions, and it was a daily, informative, real-time feedback loop.

As I reached the end of my first year of dosing with PERT, though, I was still using my spreadsheet. It surprised me, actually. Did I need to be using it? Not all the time. But the biggest reason I kept using it relates to how I often eat. I often look at an ‘entree’ for protein and then ‘build’ the rest of my meal around that, to help make sure I’m getting enough protein to fuel my ultrarunning endeavors. So I pick my entree/main thing I’m eating and put it in my spreadsheet under the fat and protein columns (=17 g of fat, =20 g of protein), for example, then decide what I’m going to eat to go with it. Say I add a bag of cheddar popcorn, so that becomes (=17+9 g of fat) and (=20+2 g of protein), and when I hit enter, those cells now tell me it’s 26 g of fat and 22 g of protein for the meal, which tells my brain (and I also tell the spreadsheet) that I’ll take 1 PERT pill for that. So I use the spreadsheet functionally to “build” what I’m eating and calculate the total grams of protein and fat; which helps me ‘calculate’ how much PERT to take (based on my previous titration efforts I know I can do up to 30g of fat and protein each in one PERT pill of the size of my prescription)

Example in my spreadsheet showing a meal and the in-progress data entry of entering the formula to add up two meal items' worth of fat and protein

Essentially, this has become a real-time calculator to add up the numbers every time I eat. Sure, I could do this in my head, but I’m usually multitasking and deciding what I want to eat and writing it down, doing something else, doing yet something else, then going to make my food and eat it. This helps me remember, between the time I decided – sometimes minutes, sometimes hours in advance of when I start eating and need to actually take the enzymes – what the counts are and what the PERT dosing needs to be.

I have done some neat retrospective analysis, of course – last year I had estimated that I took thousands of PERT pills (more on that here). I was able to do that not because it’s “fun” to track every pill that I swallow, but because I had, as a result of functional self-tracking of what I was eating to determine my PERT dosing for everything I ate, had a record of 99% of the enzyme pills that I took last year.

I do have some things that I’m no longer entering in my spreadsheet, which is why it’s only 99% of what I eat. There are some things like a quick snack where I grab it and the OTC enzymes to match without thought, and swallow the pills and eat the snack and don’t write it down. That maybe happens once a week. Generally, though, if I’m eating multiple things (like for a meal), then it’s incredibly useful in that moment to use my spreadsheet to add up all the counts to get my dosing right. If I don’t do that, my dosing is often off, and even a little bit “off” can cause uncomfortable and annoying symptoms the rest of the day, overnight, and into the next morning.

So, I have quite the incentive to use this spreadsheet to make sure that I get my dosing right. It’s functional: not for the perceived “fun” of writing things down.

It’s the same thing that happens when I run long runs. I need to fuel my runs, and fuel (food) means enzymes. Figuring out how many enzymes to dose as I’m running 6, 9, or 25 hours into a run gets increasingly harder. I found that what works for me is having a pre-built list of the fuel options; and a spreadsheet where I quickly on my phone open it and tap a drop down list to mark what I’m eating, and it pulls in the counts from the library and tells me how many enzymes to take for that fuel (which I’ve already pre-calculated).

It’s useful in real-time for helping me dose the right amount of enzymes for the fuel that I need and am taking every 30 minutes throughout my run. It’s also useful for helping me stay on top of my goal amounts of calories and sodium to make sure I’m fueling enough of the right things (for running in general), which is something that can be hard to do the longer I run. (More about this method and a template for anyone who wants to track similarly here.)

The TL;DR point of this is: I don’t track things for fun. I track things if and when they’re functionally useful, and primarily that is in real-time medical decision making.

These methods may not make sense to you, and don’t have to.

It may not be a method that works for you, or you may not have the situation that I’m in (T1D, Graves, celiac, and EPI – fun!) that necessitates these, or you may not have the goals that I have (ultrarunning). That’s ok!

But don’t say that you “couldn’t” do something. You ‘couldn’t’ track what you consumed when you ran or you ‘couldn’t’ write down what you were eating or you ‘couldn’t’ take that many pills or you ‘couldn’t’ inject insulin or…

You could, if you needed to, and if you decided it was the way that you could and would be able to achieve your goals.

Looking Back Through 2022 (What You May Have Missed)

I ended up writing a post last year recapping 2021, in part because I felt like I did hardly anything – which wasn’t true. In part, that was based on my body having a number of things going on that I didn’t know at the time. I figured those out in 2022 which made 2022 hard and also provided me with a sense of accomplishment as I tackled some of these new challenges.

For 2022, I have a very different feeling looking back on the entire year, which makes me so happy because it was night and day (different) compared to this time last year.

One major example? Exocrine Pancreatic Insufficiency.

I started taking enzymes (pancreatic enzyme replacement therapy, known as PERT) in early January. And they clearly worked, hooray!

I quickly realized that like insulin, PERT dosing needed to be based on the contents of my meals. I figured out how to effectively titrate for each meal and within a month or two was reliably dosing effectively with everything I was eating and drinking. And, I was writing and sharing my knowledge with others – you can see many of the posts I wrote collected at DIYPS.org/EPI.

I also designed and built an open source web calculator to help others figure out their ratios of lipase and fat and protease and protein to help them improve their dosing.

I even published a peer-reviewed journal article about EPI – submitted within 4 months of confirming that I had it! You can read that paper here with an analysis of glucose data from both before and after starting PERT. It’s a really neat example that I hope will pave the way for answering many questions we all have about how particular medications possibly affect glucose levels (instead of simply being warned that they “may cause hypoglycemia or hyperglycemia” which is vague and unhelpful.)

I also had my eyes opened to having another chronic disease that has very, very expensive medication with no generic medication option available (and OTCs may or may not work well). Here’s some of the math I did on the cost of living with EPI and diabetes (and celiac and Graves) for a year, in case you missed it.

Another other challenge+success was running (again), but with a 6 week forced break (ha) because I massively broke a toe in July 2022.

That was physically painful and frustrating for delaying my ultramarathon training.

I had been successfully figuring out how to run and fuel with enzymes for EPI; I even built a DIY macronutrient tracker and shared a template so others can use it. I ran a 50k with a river crossing in early June and was on track to target my 100 mile run in early fall.

However with the broken toe, I took the time off needed and carefully built back up, put a lot of planning into it, and made my attempt in late October instead.

I succeeded in running ~82 miles in ~25 hours, all in one go!

I am immensely proud of that run for so many reasons, some of which are general pride at the accomplishment and others are specific, including:

  • Doing something I didn’t think I could do which is running all day and all night without stopping
  • Doing this as a solo or “DIY” self-organized ultra
  • Eating every 30 minutes like clockwork, consuming enzymes (more than 92 pills!), which means 50 snacks consumed. No GI issues, either, which is remarkable even for an ultrarunner without EPI!
  • Generally figuring out all the plans and logistics needed to be able to handle such a run, especially when dealing with type 1 diabetes, celiac, EPI, and Graves
  • Not causing any injuries, and in fact recovering remarkably fast which shows how effective my training and ‘race’ strategy were.

On top of this all, I achieved my biggest-ever running year, with more than 1,333 miles run this year. This is 300+ more than my previous best from last year which was the first time I crossed 1,000 miles in a year.

Professionally, I did quite a lot of miscellaneous writing, research, and other activities.

I spent a lot of time doing research. I also peer reviewed more than 24 papers for academic journals. I was asked to join an editorial board for a journal. I served on 2 grant review committees/programs.

I also wrote a lot.

*by ton, I mean way more than the past couple of years combined. Some of that has been due to getting some energy back once I’ve fixed missing enzyme and mis-adjusted hormone levels in my body! I’m up to 40+ blog posts this year.

And personally, the punches felt like they kept coming, because this year we also found out that I have Graves’ disease, taking my chronic disease count up to 4. Argh. (T1D, celiac, EPI, and now Graves’, for those curious about my list.)

My experience with Graves’ has included symptoms of subclinical hyperthyroidism (although my T3 and T4 are in range), and I have chosen to try thyroid medication in order to manage the really bothersome Graves’-related eye symptoms. That’s been an ongoing process and the symptoms of this have been up and down a number of times as I went on medication, reduced medication levels, etc.

What I’ve learned from my experience with both EPI and Graves’ in the same year is that there are some huge gaps in medical knowledge around how these things actually work and how to use real-world data (whether patient-recorded data or wearable-tracked data) to help with diagnosis, treatment (including medication titration), etc. So the upside to this is I have quite a few new projects and articles coming to fruition to help tackle some of the gaps that I fell into or spotted this year.

And that’s why I’m feeling optimistic, and like I accomplished quite a bit more in 2022 than in 2021. Some of it is the satisfaction of knowing the core two reasons why the previous year felt so physically bad; hopefully no more unsolved mysteries or additional chronic diseases will pop up in the next few years. Yet some of it is also the satisfaction of solving problems and creating solutions that I’m uniquely poised, due to my past experiences and skillsets, to solve. That feels good, and it feels good as always to get to channel my experiences and expertise to try to create solutions with words or code or research to help other people.

More Tools To Help Diabetes Researchers and Other Researchers

A few years ago I made a big deal about a tool I had created, converting someone’s web tool into a command line tool to be able to take complex json data and convert it to csv. Years later, I (and thousands of others, it’s been downloaded 1600+ times!) am still using this tool because there’s nothing better that I’ve found when you have data that you don’t know the data structure for or the data structure varies across files.

I ended up creating a repository on Github to store it with details on running it, and have expanded it over the last (almost) six years as I and others have added additional tools. For example, it’s where Arsalan, one of my frequent collaborators, and I store open source code from some of our recent papers.

Recently, I added two more small scripts. This was motivated to help researchers who have been successfully using the OpenAPS Data Commons and want to update their dataset with a later version of the data. Chances are, they have cleaned and worked with a previous version of the dataset, and instead of having to re-clean all of the data all over again, this set of scripts should help narrow down what the “new” data is that needs to be pulled out, cleaned, and appended to a previously cleaned dataset.

You can check out the full tool repository here (it has several other scripts in addition to the ones mentioned above). The latest are two python scripts that checks the content of an existing folder and lists out the memberID and filenames for each. This is useful to run on an existing, already-cleaned dataset to see what you currently have. It can also be run on the latest/newest/bigger dataset available. Then, the second script can be run to compare the memberIDs and file names in the newer/biggest/larger dataset against the previously cleaned/smaller/older dataset. Those that “match” already exist in the version of the dataset they have; they don’t need to be pulled again. The others don’t exist in the current dataset, and can be popped into a script to pull out just those data files to then be cleaned and appended to the existing dataset.

As a heads up specifically for those working with the OpenAPS Data Commons, it is best practice to name/describe the version of the dataset via the size. For example, you might be working with the n=88 or n=122 version of the dataset. If you used the above method, you would then describe it along the lines of taking and cleaning the n=122 version; selecting new files available from the n=183 version and appending them to the n=122 version; and the resulting dataset is n=(122+number of new files used).

Folks who access the n=183 version of the dataset and haven’t previously used a smaller version of the dataset can reference using the n=183 and clarifying how many files they ended up using, e.g. describing that they followed X method to clean the data starting from the n=183 version and their resulting dataset is n=166, for example.

It is important to clarify which version and size of the dataset is being used.

PS – this method works on other data file types, too! You’d change the variable/column header names in the script to update this for other cases.

We Have Changed the Standards of Care for People With Diabetes

We’ve helped change the standard of care for people with diabetes, with open source automated insulin delivery.

I get citation alerts sometimes when my previous research papers or articles are cited. For the last few years, I get notifications when new consensus guidelines or research comes out that reference or include mention of open source automated insulin delivery (AID). At this time of year, the ADA Standards of Care is released for the following year, and I find out usually via these citation alerts.

Why?

This year, in 2023, there’s a section on open source automated insulin delivery!

A screenshot of the 2023 ADA Standards of Care section under Diabetes Technology (7) that lists DIY closed looping, meaning open source automated insulin delivery

But did you know, that’s not really new? Here’s what the 2022 version said:

A screenshot of the 2022 ADA Standards of Care section under Diabetes Technology (7) that lists DIY closed looping, meaning open source automated insulin delivery

And 2021 also included…

A screenshot of the 2021 ADA Standards of Care section under Diabetes Technology (7) that lists DIY closed looping, meaning open source automated insulin delivery

And 2020? Yup, it was there, too.

A screenshot of the 2020 ADA Standards of Care section under Diabetes Technology (7) that lists DIY closed looping, meaning open source automated insulin delivery

All the way back to 2019!

A screenshot of the 2019 ADA Standards of Care under Diabetes Technology (7) that lists DIY closed looping, meaning open source automated insulin delivery

If you read them in chronological order, you can see quite a shift.

In 2019, it was a single sentence noting their existence under a sub-heading of “Future Systems” under AID. In 2020, the content graduated to a full paragraph at the end of the AID section (that year just called “sensor-augmented pumps”). In 2021, it was the same paragraph under the AID section heading. 2022 was the year it graduated to having its own heading calling it out, with a specific evidence based recommendation! 2023 is basically the same as 2022.

So what does it say?

It points out patients are using open source AID (which they highlight as do-it-yourself closed loop systems). It sort of incorrectly suggests healthcare professionals can’t prescribe these systems (they can, actually – providers can prescribe all kinds of things that are off-label – there’s just not much point of a “prescription” unless it’s needed for a person’s elementary school (or similar) who has a policy to only support “prescribed” devices).

And then, most importantly, it points out that regardless, healthcare providers should assist in diabetes management and support patient choice to ensure the safety of people with diabetes. YAY!

“…it is crucial to keep people with diabetes safe if they are using these methods for automated insulin delivery. Part of this entails ensuring people have a backup plan in case of pump failure. Additionally, in most DIY systems, insulin doses are adjusted based on the pump settings for basal rates, carbohydrate ratios, correction doses, and insulin activity. Therefore, these settings can be evaluated and modified based on the individual’s insulin requirements.”

You’ll notice they call out having a backup plan in case of pump failure.

Well, yeah.

That should be true of *any* AID system or standalone insulin pump. This highlights that the needs of people using open source AID in terms of healthcare support are not that different from people choosing other types of diabetes therapies and technologies.

It is really meaningful that they are specifically calling out supporting people living with diabetes. Regardless of technology choices, people with diabetes should be supported by their healthcare providers. Full stop. This is highlighted and increasingly emphasized, thanks to the movement of individuals using open source automated insulin delivery. But the benefits of this is not limited to those of us using open source automated insulin delivery; this spills over and expands to people using different types of BG meters, CGM, insulin pumps, insulin pens, syringes, etc.

No matter their choice of tools or technologies, people with diabetes SHOULD be supported in THEIR choices. Not choices limited by healthcare providers, who might only suggest specific tools that they (healthcare providers) have been trained on or are familiar with – but the choices of the patient.

In future years, I expect the ADA Standard of Care for 2024 and beyond to evolve, in respect to the section on open source automated insulin delivery.

The evidence grading should increase from “E” (which stands for “Expert consensus or clinical experience”), because there is now a full randomized control trial in the New England Journal of Medicine on open source automated insulin delivery, in addition to the continuation results (24 weeks following the RCT; 48 full weeks of data) accepted for publication (presented at EASD 2022), and a myriad of other studies ranging from retrospective to prospective trials. The evidence is out there, so I expect that this evidence grading and the text of the recommendation text will evolve accordingly to catch up to the evidence that exists. (The standards of care are based on literature available up to the middle of the previous year; much of the things I’ve cited above came out in later 2022, so it matches the methodology to not be included until the following year; these newest articles should be scooped up by searches up to July 2023 for the 2024 edition.)

In the meantime, I wish more people with diabetes were aware of the Standards of Care and could use them in discussion with providers who may not be as happy with their choices. (That’s part of the reason I wrote this post!)

I also wish we patients didn’t have to be aware of this and don’t have to argue our cases for support of our choices from healthcare providers.

But hopefully over time, this paradigm of supporting patient choice will continue to grow in the culture of healthcare providers and truly become the standard of care for everyone, without any personal advocacy required.

Did you know? We helped change the standards of care for people living with diabetes. By Dana M. Lewis from DIYPS.org

New Chapter: Personalizing Research: Involving, Inviting, and Engaging Patient Researchers

TLDR: A new chapter I wrote, invited for a book on Personal Health Informatics, is out! You can read a summary below describing my chapter. You can also find a link to a full pre-print (a copy of my submitted, unedited version) of the article (as well as author copies of all of my articles) on my research page.

In November 2020 I was invited to submit a proposal for a chapter for a pending book on personal health informatics. Like journal articles, you can be invited to submit for a book chapter as part of a larger book topic.

Knowing that book chapters take a long time to come out, I carefully thought about the topic of my article and whether I could write something that would be relevant approximately a year after I wrote it.

The context of the book was:

“high-quality scholarly work that seeks to provide clarity, consistency, and reproducibility, with a shared view of the status-quo of consumer and pervasive health informatics and its relevance to precision medicine and healthcare applications and system design. The book will offer a snapshot of this emerging field, supported by the methodological, practical, and ethical perspectives from researchers and practitioners in the field. In addition to being a research reader, this book will provide pragmatic insights for practitioners in designing, implementing, and evaluating personal health informatics in the healthcare settings.”

They also wanted to include patient perspectives, which is part of the reason I was invited to submit a proposal for a chapter, and asked if I could write about citizen science from the patient perspective.

I decided to write more broadly about patient perspectives in research, and since the audience of this book is likely to be academic researchers and practitioners already in the field, seek to provide some ideas and input as to how they could think about practically inviting and engaging patient partners in research, as well as supporting the burgeoning field of patient researchers who lead their own research.

I submitted my draft article in April 2021; received feedback and submitted the revision in August 2021; and the book was due to be published in “spring 2022”.

::crickets::

The book is now out in November 2022, hooray! It is called Personal Health Informatics and you can find it online here.

Abstract from my chapter:

There are many benefits to engaging and involving patients in traditional, researcher-led research, ranging from improved recruitment and increased enrollment to accelerating and facilitating the implementation of research outcomes. Researchers, however, may not be aware of when and where they can involve patients (people with lived healthcare experience) in research or what the benefits may be of improving patient engagement in the research process or of expanding patient involvement to other research stages. This chapter seeks to highlight the benefits and opportunities of engaging patients in traditional research and provide practical suggestions for inviting or recruiting patients for participation in research, whether or not there is an established patient and public involvement (PPI) program. This includes tips for developing a productive working relationship and culture between researchers and the patients involved in research. There are also many patients themselves conducting research, and often without the benefits, resources, and opportunities made available to traditional researchers. Traditional researchers should identify and recognize researchers who have emerged from non-traditional paths who are driving and engaging in their own research, and provide support and resources where appropriate to foster further patient-driven research. This investment can lead to collaboration opportunities for additional highly relevant and effective research studies with traditional researchers in the future. This chapter provides examples of patient researchers and offers tools to support traditional researchers who want to support patient-led research efforts and improve their ability to successfully engage patient stakeholders in their own research.

Here are some of the highlights and recommendations from my chapter:

  • Invite patients to participate in research, and do it early.
  • Ask patients how they’d like to be involved in research.
  • Relationship building and culture setting is important. Address the power dynamics within your project and team.
  • Set expectations for everyone involved on the team.
  • Consider training and skill-building opportunities for patients who are partnering in research.
  • If you’re looking to support a patient who is already initiating or performing research, first ask: “How can I help?”. This article includes a list of suggestions of how you can help them.

This article also highlights many exceptional researchers who are patients and their work, including:

Note the chapter discusses explicitly how not everyone has a PhD or an MD; this is not a requisite to doing high-quality research!

The chapter concludes with “clinical pearls’’, which are four suggested tips to use in daily practice, and includes some suggested resources like the Opening Pathways Readiness Quiz. It also includes a suggestion of making a “To Don’t” list in collaboration with patient research partners.

The chapter also contains two review questions:

  1. Imagine that you have a research project where you would like to apply for funding, and the funder mandates that you have a patient involved in your research project. At what stage do you involve a patient in your project, and how do you do so?
  2. You are at a scientific conference and observe a patient giving a presentation about their own research or project. They’re not a traditional researcher – they don’t have a PhD or have a day job as a researcher. You want to approach them and offer your help with their research. What do you offer when you approach them?

To see the answers to these review questions, check out the article in full! :)

TLDR: A new chapter I wrote, invited for a book on Personal Health Informatics, is out! You can find a link to a full pre-print (a copy of my submitted, unedited version) of the article (as well as author copies of all of my articles) on my research page.

If you’d like to cite this in one of your articles, note that the DOI for the article is https://doi.org/10.1007/978-3-031-07696-1_17 and an example citation is:

Lewis, D. (2022). Personalizing Research: Involving, Inviting, and Engaging Patient Researchers. In: Hsueh, PY.S., Wetter, T., Zhu, X. (eds) Personal Health Informatics. Cognitive Informatics in Biomedicine and Healthcare. Springer, Cham. https://doi.org/10.1007/978-3-031-07696-1_17

Excerpted tips from the book chapter "Personalizing Research: Involving, Inviting, and Engaging Patient Researchers" by Dana Lewis

Regulatory Approval Is A Red Herring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What is the “continuation phase”?

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

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

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

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

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

What are the results from the continuation phase?

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

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

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

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

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

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

Conclusion of the continuation study from the CREATE trial

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

Key points to takeaway:

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

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

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

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!