Regulatory Approval Is A Red Herring

November 15, 2022 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.

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

September 22, 2022 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

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

July 5, 2022December 22, 2022 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!

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

June 6, 2022September 22, 2022 by Dana Lewis

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

Example citation:

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

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

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

—

The backstory on this study

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

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

—

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

Study Design:

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

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

Results:

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

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

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

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

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

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

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

Difference between control and AID arms overall, and during day and night separately, of TIR for overall, adults, and kids

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

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

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

In summary:

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

—

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

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

Example citation:

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

—

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

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

Missing metrics in diabetes measurement by @DanaMLewis

February 20, 2019 by Dana Lewis

“May I ask what your A1c is?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Broken bones (trimalleolar ankle fracture), type 1 diabetes, and #OpenAPS

February 12, 2019 by Dana Lewis

In January, Scott and I planned and went on a three day hiking trip in New Zealand. NZ is famous for “tramping” and “trekking”, and since we were in the country for a conference (you can see my talk at LinuxConfAU here!), we decided to give it a try. This was my first true “backpacking” type trip where you carry all your stuff on your back; and the first multi-day hiking experience. You could either rent a cot in a hut and carry all your food and cooking utensils and bedding on your back; or you could pay to hike with a company who has a lodge you can stay at (with hot showers and amazing food) and also has guides who hike with your pack. They had me at “gluten free food” and “hot showers”, so I convinced Scott that was the way we should do our Routeburn Track hike!

I planned ahead well for the hike; they gave us a packing list of recommended things to carry and bring. I learned from a friend in NZ, Martin, who had gone trekking a few weeks prior: his pack went over a cliff and was lost – yikes! Therefore, I planned one set of supplies in baggies and put them in both Scott & my pack just in case something happened to one of our packs, we’d still be completely covered.

Day 1 of the hike was awesome – it was overcast and felt like hiking in Seattle, but the scenery and wildlife were still great to experience. Since it was raining off and on, the waterfalls were spectacular.

Day 2 also started awesome – it was a breathtakingly clear morning with blue skies and sunshine as we hiked up above the tree line and over a mountain ridge, along the valley, and onward toward the lunch spot. I was feeling great and enjoying my hike – this was one of my all-time favorite places to hike in terms of the view of the valley and lake that we hiked from; and the mountain views on the other side of the ridge once we topped the mountain and crossed over.

However, about 30 min from the lunch shelter (and about 300 feet of elevation to go), I noticed the lady hiking in front of us decided to sit and slide down a particularly large and angled rock on the trail. I approached the rock planning to stop and assess my plan before continuing on. Before I even decided what to do, I somehow slipped and vaulted (for lack of a better word) left and off the trail…and down the slope. I flipped over multiple times and knew I had to grab something to stop my flight and be able to save myself from going all the way off the mountain slope. I amazingly only ended up about 10 feet off the trail, clinging to a giant bush/fern-like plant.

I had to be pulled back up to the trail by Scott and another hiker who came running after hearing my yell for help as I went down the mountain. (Scott came down off the trail few feet, and had to hold onto the hand of another hiker with one hand while pulling me up with the other, just like in the movies. It’s not a lot of fun to be at the end of the human chain, though!) At that point, I knew I had injured my right ankle and could only use my left foot/leg and right knee to try to climb back up to the trail while they pulled on my backpack. We got me back on to the trail and over to a rock to rest. We waited a few minutes for the back-of-the-pack guides who showed up and taped around my ankle and boot to see if I could walk on it – they thought it was sprained. I could flex, but couldn’t really put weight on it without excruciatingly sharp pain on the right side. I’d never sprained my foot before or broken any bones in my life, so I was frustrated by how painful the ‘sprain’ was. I had an overwhelming wave of nausea that I knew was in response to the pain, too, so at one point I had to sit there and lean back with my eyes closed while everyone else talked around me.

The guides wanted to see if we could get to a nearby river to ice my leg in. I used my poles as pseudo-crutches in front of me, with my arms bent at 90 degree angles, and with Scott behind me to check my balance, would crutch and hop on one leg. It wasn’t like regular crutching, though, where you can press your weight down on your arms and hands. It was really an act of placing the poles slightly forward for balance and then hopping up and forward, pressing off my left leg. My left leg was quickly exhausted and cramping from the effort of hopping forward with my entire body weight. It was also complicated by the rain making things more slippery; and of course; this is a mountain trail with rocks and boulders of different sizes. What I didn’t even notice walking normally on two feet became incredibly frustrating for figuring out when and how to jump up onto a small rock; or around to the side; etc.

“Lucky” for me (eye roll), we happened to be in an ascending section of the trail with quite a few large rocky sections, and there was no way I could hop up the uneven rocks on foot. So instead, I chose to crawl up and over those sections on my hands and knees. Then I would get up at the top and hop again through the “flatter” gravel and rock sections, then crawl again. It was slow and exhausting, and painful when I would get up one one leg again and start hopping again. I was in the most physical pain I’d ever been in my life.

After about a very slow and painful quarter of a mile, and as rain was dripping down more steadily, the guides decided I wouldn’t make it the remaining 300ft of elevation/30 minute (normal) hike to the lunch spot. They radioed for a medevac helicopter to come pick me up. I was incredibly upset and disappointed that I had ruined our hike… but also knew I absolutely wouldn’t even make it to the lunch shelter. I remember saying “I feel so stupid!” to Scott.

The helicopter came in a surprisingly quick amount of time, and they let out one of the EMT’s nearby and then flew over to a hill across from the trail. The EMT saw that I was decently clothed and covered (I had 3/4 length running pants on; a rain jacket and hood; and had a second rain jacket to cover my legs against the rain and wind) and did a verbal status check to confirm I was decent enough for them to lift me off the mountain. They weren’t able to land safely anywhere nearby on the trail because it was so steep and narrow; so they put me in a “sack” that went around my back and looped over my arms and between my legs, and was hooked on to the EMT’s harness. Scott and the guide stood back, while the helicopter came back and lowered the winch. I was winched up from there. However, the EMT had told me once we got up to the helicopter that the team inside would pull me straight back. And that didn’t happen, which was slightly more terrifying because we started flying away from the mountain while still *outside* the helicopter. It turns out the helicopter had unloaded a stretcher and supplies on the nearby hill, and so we were lowered down – with me and the EMT still perched outside the skids – to the hillside there, so the team could then gather the supplies & then load me in so I could sit on the stretcher.

The other terrifying factor about being evacuated off the mountain was that due to the weather that was blowing in hours ahead of schedule, and the “we have to winch you off the mountain” aspect: they couldn’t take Scott with us. So I had to start making plans & preparing myself for going to the hospital by myself in a foreign country. I was terrified about my BGs & diabetes & how I know hospitals don’t always know what to do with people with T1D, let alone someone on a (DIY) closed loop. I tried to tamp down on my worries & make some plans while we waited for the helicopter, so Scott would know I was okay-ish and worry slightly less about me. But at that point, we knew he would have to finish the day’s hike (another 3-4 hours); spend the night; and hike down the next day as planned in order to meet up with me at the hospital.

As we lifted off in the helicopter, I handed the EMT my phone, where I had made a note with my name, age, medical information (T1D & celiac), and the situation about my ankle. He loved it, because he could just write down my information on the accident forms without yelling over the headset. Once he gave me my phone back, a few minutes later we passed back into an area with signal, and I was able to send text messages for the first time in 2 days.

I sent one to my mom, as carefully worded as I could possibly do:

“Slipped off the trail. Hurt ankle. BGs ok. In a helicopter to the hospital in Queenstown. Just got signal in helicopter. Don’t freak out. Will text or call later. Love you”

It had all the key information – something happened; here’s where I’m heading; BGs are fine; pleeeeeeeease don’t freak out.

I also sent a text to Scott’s dad, Howard, who’s an ER doc, with a tad different description:

“Slipped and flipped off the trail. Possible ankle fracture or serious sprain. Being medevac’d off in a helicopter. BGs are fine. But please stand by for any calls in case I need medical advice. Just got signal in the chopper. Scott is still on the trail until tomorrow so I am solo.”

I was quite nervous when we arrived at the hospital. I haven’t been in an ER since high school (when I was dehydrated from a virus). I’ve heard horror stories about T1D & hospitals. However, most of my fears related to T1D were completely unfounded. When I arrived, the EMT did some more paperwork, I talked briefly to a nurse, and then was left alone for quite a while (maybe an hour). Other than mentioning T1D (and that my BGs were fine) and celiac to the nurse, no one ever asked about my BGs throughout the rest of the time in the ER. Which was fine with me. What my BGs had actually done was rise steadily from about 120 up to 160, then stayed there flat. That’s a bit high, but given I was trying to manage pain and sort out my situation, I was comfortable being slightly elevated in case I crashed/dropped later when the adrenaline came down. I just let OpenAPS keep plugging away.

The first thing that was done in the ER about an hour after I arrived was wheeling me to go get an x-ray. It was quick and not too painful. I remember vividly that the radiologist came back out and and said “yes, your ankle is definitely broken. In two places.” I started at her and thought an expletive or two. But for some reason, that made me feel a lot better: my pain and the experience I had on the mountain was not totally disproportionate to the injury. I relaxed a lot then, and could feel a lot of the stress ebbing away. My BGs started a slow sloping drop down almost immediately, and ended up going from 160 down to 90 where I leveled out nicely and stayed for the next few hours.

After I was wheeled back to my area of the ER, the ER doc showed up. He started asking, “So I heard you hopped and climbed off the mountain?” and then followed up by saying yes, my ankle was broken…in three places.

Me: “WHAT? Did you say ::three::?”

The ER doc said he had already consulted ortho who confirmed I would need surgery. However, it didn’t have to be that night (halleluljah), and they usually waited ’til swelling went down to operate, so I had a choice of doing it in NZ or going home and doing it there. He asked when I was planning to leave: this was Sunday evening now; and we planned to fly out Wednesday morning. I asked if there were any downsides to waiting to do surgery at home; any risk to my long-term health? He said no, because they usually wait ~10 days for the swelling to go down to operate. So I could wait in NZ (me: uhhh, no) or fly home and see someone locally. I was absolutely thrilled I wouldn’t need to operate then and there, and without Scott. I asked for more details so I could get my FIL’s opinion (he concurred, coming home was reasonable), and then confirmed that I liked the plan to cast me; send me on my way; and let me get surgery at home.

It took them another 2 hours to get me to the procedure room and start my cast. This was a small, 6-bed ER. When they finally started my cast, the ER doc had his hands on my ankle holding it up…and another nurse rushed in warning that a critical patient was in route, 5 minutes out. The ER doc and the other nurse looked at each other, said “we can do this by then”, and literally casted me in 2 minutes and were wheeling me out in the third minute! It was a tad amusing. I was taken back to x-ray where they confirmed that the cast was done with my ankle in a good position. After that, I just needed my cast to be split so I could accommodate swelling for the long plane rides home; get my prescriptions for pain med; get crutches; and go home.

All that sounds fast, but due to the critical patient that had come in, it took another two hours. They finally came and split my cast (which is done by using the cast cutter to cut a line, then another line, then pull out the strip in between), sold me my crutches, and wrote my prescriptions. The ER doc handed me my script, and I asked if the first rx had acetaminophen (because it would mess up my G4). He said it did, so he scribbled that out and prescribed ibuprofen instead. The nurse then got & apologized for “having to sell me” crutches. New Zealand has a public health policy where they cover everything in an accident for foreigners: I didn’t have to pay for the medevac (!!), the ER visit (!!), the x-rays (!!), the cast …nothing. Just the crutches (which they normally lend for free to NZ but obviously I was taking these home). Then I was on my way.

Thankfully, the company we hiked with had of course radioed into Queenstown, and the operations manager had called the ER and left a message to give to me with his phone number. A few hours prior, when I found out I’d be casted & released that night, I had been texting my mom & had her call the hotel Scott & I were staying at the next (Monday) night to see if they had a room that (Sunday) night that I could check into. The hiking company guy offered to drive me wherever, so he came to pick me up. I had texted him to keep him posted on my progress/timeline of release (nice and vague and unhelpful for the most part). But I also asked as soon as we got in contact if he could radio a message to the lodge & tell Scott that: a) my ankle was broken; b) I was ok; c) I’d be at the hotel when he got in the next day and not to rush, I was ok. The guy said he could do me one better: when he came to pick me up, he’d bring the phone so I could ::call: and talk to Scott directly. (I almost cried with relief, there, at the idea of getting to talk to Scott so he wouldn’t be beside himself worrying for 22 hours). I did get to talk to Scott for about a minute and tell him everything directly, and convince him not to hike out himself in the morning, but stick with the group and the normal transport method back to Queenstown, and just come meet me at the hotel when he got back around 4pm the next day. He agreed.

(What I didn’t find out until later is that Scott had considered doing the rest of the hike completely that night. Two things ended up dissuading him: one was the fact that a guide would have had to go with him and then hike all the way back to the lodge that night. The other was the fact that he talked to me and I would be out of the hospital by the time he arrived; so since I said I was fine alone at the hotel, he’d wait until the next day.)

So, I was taken to the hotel and got help getting up to the hotel room and had ice delivered along with extra pillows to prop up, and our bags brought in. Thankfully, on the mountain, the EMT had agreed to winch my backpack up with me. This was huge, because I noted earlier, I had a full set of supplies in my backpack, and all we had to do on the mountain was grab an extra international adapter and my charger cords out of Scott’s bag and toss it into mine. That made it easy to just pull what I needed that night (my rig; charger cords & adapter; a snack) out of the top of my bag from my perch on the bed. I plugged in my rig; made sure I was looping, took my pain meds, and went to sleep.

$Broken_bones_type_1_diabetes_trimalleolar_fracture_OpenAPS_DanaMLewis$ Amazingly, although you’re probably not any more surprised than I am at this point, my BGs stayed perfectly in range all night. Seriously: after that lowering from 160 once I relaxed and let some of the stress go? No lows. No highs. Perfectly in range. The pain/inflammation and my lack of eating didn’t throw me out of range at all. The day of the fall, all I ate was breakfast (8am); didn’t eat lunch and didn’t bother doing anything until 11pm when I had a beef jerky stick for some protein and half a granola bar (10g carbs). For the next two and a half weeks now, I’ve had no lows, and very few highs.

The one other high BG I really had was on Sunday after we got home (we got back on Wednesday). It happened after my crutch hit the door coming back to my bedroom from the bathroom, and I did such a good job hopping on my left foot and protecting my casted right foot, that I managed to break the smallest toe on my left foot. I pretty immediately knew that it was broken based on the pain; then my BG slowly rose from 110 up to 160; and then I started to have the same “shadow” bruising spread around my foot from the base of the toe. Scott wasn’t sure; when I had fallen off the trail I had yelled “help!” and “I think I broke my foot!”. I didn’t say it out loud this time; just thought it. Again, after some ibuprofen and icing and resting, within an hour my BG started coming back down slowly to below 100 mg/dL.

On Tuesday, I went to the orthopedic surgeon and confirmed: my left toe is definitely broken. My right ankle is definitely broken: the trimalleolar fracture diagnosis from NZ was confirmed. However, given that none of the ligaments were damaged, and the ankle was in a decent position, the ortho said there’s a good chance I can avoid surgery and heal in place inside a cast. The plan was to take off my split, plaster-based cast they did in NZ and give me a proper cast. We’d follow up in 10 days and confirm via x-ray that everything was going well. I asked how likely surgery would still be with this plan; and he said 20%. Well, given that I was assuming 100% before, that was huge progress! He also told me I shouldn’t travel within 4 weeks of the injury, which unfortunately means I had to cancel my trip to Berlin for ATTD later in February. It may or may not mean I have to cancel another trip; I’ll have to wait and see after the next follow up appointment, depending on whether or not I need surgery.

Up until this point, I had been fairly quiet (for me) on social media. I hadn’t posted the pictures of our hike; I didn’t talk about my fall or the trip home. One friend had texted and said “I wondered if you fell off the face of the earth!” to which I responded “uhhh…well…about that…I ::only:: fell off a mountain! Not earth!” Ha. Part of the reason was not knowing whether or not I would be able to travel as planned, and wanting to be courteous to informing the conferences who invited me to speak about the situation & what it meant for me being able to attend/not. Once I had done that, I was able to start posting & sharing with everyone what had happened.

For those who follow my airport travels and wondered just how long I was in NZ…I’m actually home now, and have been home for almost a week. I skipped on the last airport reporting.

— Dana M. Lewis | #OpenAPS 🤖 (@danamlewis) February 5, 2019

To be perfectly honest, it’s one thing to have a broken limb and a cast and have to use crutches. It’s an entirely other ball of wax to have a broken toe on the foot that’s supposed to be your source of strength & balance. The ortho gave me a post-op surgical shoe to wear on my left foot to try to help, but it hurt so bad that I can’t use my knee scooter to move easily without my left foot burning from the pain. Thankfully, Scott’s parents’ neighbor also had a motorized sit-scooter that we borrowed. However, due to the snowpocalypse that hit Seattle, I’ve not been able to leave the house since Thursday. We haven’t been able to drive anywhere, or walk/scooter anywhere, in days. I’m not quite stir crazy yet; but; I’ll be really looking forward to the sidewalks being snow-free and hopefully lake-free (from all the melting snow) later in the week so I can get out again. I also picked up a cold somewhere, so I for the most part have been stationary in bed for the last week, propping up my feet and using endless boxes of Kleenex.

▪️Trimalleolar fracture in the right ankle.
▪️Fracture of the smallest toe on my left foot.
▪️And now a cold is kicking in. 🤧

At least my BGs are behaving (even if the rest of my body is not), thanks to #OpenAPS! pic.twitter.com/QGEBZO9CNk

— Dana M. Lewis | #OpenAPS 🤖 (@danamlewis) February 6, 2019

OpenAPS, as you can see, has done an excellent job responding to the changes in my insulin needs from being 100% sedentary. (Really – think trips to the bathroom and that’s it.) In addition to the increased resistance from my cold and being sedentary, there’s one other new factor I’ve been dealing with. I asked my ortho about nutrition, and he wants me to get 1g of protein per kg of body weight, plus 1000mg/day of calcium. He suggested getting the extra protein via a powder, instead of calories (e.g. eating extra food). I found a zero-carb, gluten free powder that’s 25g of protein per scoop, and have been trying it with chocolate milk (which is 13g of carb and 10g of protein).

(I'm mixing it with lactose-free chocolate milk that's lower carb (13g carbs per 1 cup) than regular; and the vanilla flavor I got is a tad on the sweet side 😑..it's tolerable now that it mixes in by shaking, but looking forward to trying the unflavored version in a few days).

— Dana M. Lewis | #OpenAPS 🤖 (@danamlewis) February 9, 2019

I’ve been drinking that 2x a day. Interestingly, previous to my injury, unless I was eating a 100% no carb meal (such as eggs and bacon for breakfast), I didn’t need to bolus/account for protein. However, even though I’m entering carbs for chocolate milk (15), I was seeing a spike up to 150 mg/dL after drinking it. I tried entering 30g for the next time (13g of milk; plus about 50% for the 25+10g worth of protein), and that worked better and only resulted in a 10 mg/dL rise in response to it. But even a handful of nuts’ worth of protein, especially on days where I’m hardly eating anything, have a much stronger effect on my BGs. This could be because my body is adjusting to me eating a lot less (I don’t have much appetite); adjusting to the much-higher-protein diet overall; and/or responding to the 100% sedentary pattern of my body now.

Thankfully, it’s not been a big deal, and OpenAPS does such a good job tamping down on the other noise-based factors: it’s nice that my biggest problems are brief rises to 160 or 170 mg/dL (that then come back down on their own). My 7-day and 30-day BG averages have stayed the same; and my % time in range for 80-160 has stayed the same, even with what feels like a few extra protein-related blips, and even when some days I eat hardly anything and some days I manage 2-3 meals.

So to summarize a ridiculously long post:

When I break bones, my BGs rise up (due to inflammation and/or the stress/other hormonal reaction) up to 160 mg/dL until I relax, when they’ll come back down. Otherwise, broken bones don’t really phase OpenAPS.
Ditto for lack of movement and changes in activity patterns not phasing OpenAPS.
The biggest “challenge” has been adjusting to the 3x amount of protein I’m getting as a dietary change.
I have a trimalleolar fracture; and that’s about 7% of ankle fractures. I read a lot of blog posts about people needing surgery & the recovery from it taking a long time. I’m not sure I won’t need surgery; but I’m hoping I won’t need it. If so, here’s one data point for a trimalleolar fracture being non-surgical – I’ll update more later with full recovery timelines & details. Also, here is a Twitter thread where I’m tracking some of the most helpful things for life with crutches.
Don’t break your littlest toe – it can hurt more than larger fractures if you have to walk on it!

A huge thank you goes to my parents and Scott’s parents; our siblings on both sides for being incredibly supportive and helpful as well; and Scott himself who has been waiting on me (literally hand and foot) and taking most excellent care of me.

Current status:

Broken ankle: ✅✅🔲🔲🔲🔲 (2 weeks down in the hard casts!)

Broken toe: ✅🔲🔲🔲 (1 week down) @scottleibrand: ✅ has not fled house ✅still being amazingly kind and helpful and thoughtful ✅ still an absolute keeper! 💜

— Dana M. Lewis | #OpenAPS 🤖 (@danamlewis) February 9, 2019

And thank you as well to anyone who read this & for everyone who’s been sending positive thoughts and love and support. Thank you!

4 years DIY closed looping with #OpenAPS – what changed and what hasn’t

December 2, 2018December 20, 2022 by Dana Lewis

It’s hard to express the magnitude of how much closed looping can improve a person with diabetes’ life, especially to someone who doesn’t have diabetes or live closely with someone that does. There are so many benefits – and so many way beyond the typically studied “A1c improvement” and “increased time in range”. Sure, those happen (and in case you haven’t seen it, see some of the outcomes from various international studies looking at DIY closed loop outcomes). But everything else…it’s hard to explain all of the magic that happens in real life, that’s made so much richer by having technology that for the most part keeps diabetes out of the way, and more importantly: off the top of your mind.

Personally, my first and most obvious benefit, and the whole reason I started DIYing in the first place, was to have the peace of mind to sleep safely at night. Objective achieved, immediately. Then over time, I got the improvements in A1c and time in range, plus reduction in time spent doing diabetes ‘stuff’ and time spent thinking about my own diabetes. The artificial pancreas ‘rigs’ got smaller. We improved the algorithm, to the point where it can handle the chaos that is everything from menstrual cycle to having the flu or norovirus.

More recently, in the past ~17 months, I’ve achieved an ultimate level of not doing much diabetes work that I never thought was possible: with the help of faster insulin and things like SMB’s (improved algorithm enhancements in OpenAPS), I’ve been able do a simple meal announcement by pressing a button on my watch or phone..and not having to bolus. Not worrying about precise carb counts. Not worrying about specific timing of insulin activity. Not worrying about post-meal lows. Not worrying about lots of exercise. And the results are pretty incredible to me:

We should be measuring and reducing user burden with AID in addition to improving TIR and A1c

But I remember early on when we had announced that we had figured out how to close the loop. We got a lot of push back saying, well, that’s good for you – but will it work for anyone else? And I remember thinking about how if it helped one other person sleep safely at night..it would be worth the amount of work it would take to open source it. Even if we didn’t know how well it would work for other people, we had a feeling it might work for some people. And that for even a few people who it might work for, it was worth doing. Would DIY end up working for everyone, or being something that everyone would want to do? Maybe not, and definitely not. We wouldn’t necessarily change the world for everyone by open sourcing an APS, but that could help change the world for someone else, and we thought that was (and still is) worth doing. After all, the ripple effect may help ultimately change the world for everyone else in ways we couldn’t predict or expect.

This has become true in more ways than one.

That ‘one other person’ turned into a few..then dozen..hundreds..and now probably thousand(s) around the world using various DIY closed loop systems.

And in addition to more people being able to choose to access different DIY systems with more pumps of choice, CGMs of choice, and algorithm of choice, we’ve also seen the ripple effect in the way the world works, too. There is now, thankfully, at least one company who is evaluating open source code; running simulations with it; and where it is out-performing their original algorithm or code components, utilizing that knowledge to improve their system. They’re also giving back to the open source diabetes community, too. Hopefully more companies will take this approach & bring better products more quickly to the market. When they are ready to submit said products, we know at least U.S. regulators at the FDA are ready to quickly review and work with companies to get better tools on the market. That’s a huge change from years ago, when there was a lot of finger pointing and what felt like a lot of delay preventing newer technology from reaching the market. The other change I’m seeing is in diabetes research, where researchers are increasingly working directly with patients from the start and designing better studies around the things that actually matter to people with diabetes, including analyzing the impact and outcomes of open source technology.

After five years of open source diabetes work, and specifically four years of DIY closed looping, it finally feels like the ripples are ultimately helping achieve the vision we had at the start of OpenAPS, articulated in the conclusion of the OpenAPS Reference Design:

Is there still more work to do? Absolutely.

Even as more commercial APS roll out, it takes too long for these to reach many countries. And in most parts of the world, it’s still insanely hard and/or expensive to get insulin (which is one of the reasons Scott and I support Life For A Child to help get insulin, supplies, and education to as many children as possible in countries where otherwise they wouldn’t be able to access it – more on that here.). And even when APS are “approved” commercially, that doesn’t mean they’ll be affordable or accessible, even with health insurance. So I expect our work to continue, not only to support ongoing improvements with DIY systems directly; but also with encouraging and running studies to generalize knowledge from DIY systems; hopefully seeing DIY systems approved to work with existing interoperable devices; helping any company that will listen to improve their systems, both in terms of algorithms but also in terms of usability; helping regulators to see both what’s possible as well as what’s needed to successfully using these types of system in the real world. I don’t see this work ending for years to come – not until the day where every person with diabetes in every country has access to basic diabetes supplies, and the ability to choose to use – or not – the best technology that we know is possible.

But even so, after four years of DIY closed looping, I’m incredibly thankful for the quality of life that has been made possible by OpenAPS and the community around it. And I’m thankful for the community for sharing their stories of what they’ve accomplished or done while using DIY closed loop systems. It’s incredible to see people sharing stories of how they are achieving their best outcomes after 45 years of diabetes; or people posting from Antartica; or after running marathons; or after a successful and healthy pregnancy where they used their DIY closed loop throughout; or after they’ve seen the swelling in their eyes go done; etc.

The stories of the real-life impacts of this type of technology are some of the best ripple effects that I never want to forget.

Vitamin D and insulin sensitivity

February 9, 2018 by Dana Lewis

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

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

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

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

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

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

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

—

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

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

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

September 29, 2017December 20, 2022 by Dana Lewis

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

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

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

I bet she’s doing SOME bolus.

Well, she must not be eating any carbs.

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

Nope, nope, and nope.

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

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

Wow.

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

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

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

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

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

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

How we started testing no-bolus approach:

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

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

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

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

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

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

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

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

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

The questions I always get:

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

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

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

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

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

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

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

Why a non-academic (patient) publishes in academic journals

September 18, 2017 by Dana Lewis

Today I was able to share that my Letter to the Editor was published in the Journal of Diabetes Science and Technology. It’s on why we need to set expectations to help patients successfully adopt hybrid closed loop/artificial pancreas/automated insulin delivery system technology. (You can read it via image copies in the first link.)

I’ve published a few times in academic journals. Last year, Scott and I published another Letter to the Editor in JDST with the OpenAPS outcomes study we had presented at the 2016 ADA Scientific Sessions conference.

But, I’m sure people are wondering why I choose to do so – especially as I am 1) a patient and 2) a non-academic. (Although in case you missed it – I’m now the Principal Investigator on a grant-funded study!)

While there are many healthcare providers, researchers, industry employees, FDA staff, etc. who read blogs like this and are up to speed on the bleeding edge of diabetes technology… there are easily 10x the number that do not.

This means most healthcare providers don’t know anything about “eating soon” mode as a strategy for optimizing meal-time insulin activity in the liver to create better post-meal outcomes without risking additional hypoglycemia from pre-bolus. (This works for DIY closed loopers as well as non-loopers who can do this manually.)
This means many also don’t know about the DIY solutions available to patients – whether that be DIY tools like xDrip(+); Nightscout for remote monitoring; DIY closed looping; DIY open looping tools; or DIY tools for automatic basal rate and other ratio adjustments.

And if they don’t know about the existence of this world, they won’t know about the valuable lessons we’re learning and won’t be able to share those lessons and knowledge with other healthcare providers and the patients that they treat.

So, in my pursuit to find more ways to share knowledge from our community with the rest of the diabetes community, this is why we submit abstracts for posters and presentations to conferences like ADA’s Scientific Sessions. Our abstracts are evaluated just like the abstracts from traditional healthcare providers (as far as they can tell, I’m just another academic, albeit one with fewer credentials ;)), and I’m proud that they’re evaluated and deemed worthy of poster presentations alongside mainstream researchers. Ditto for our written publications, whether they be letters to the editor or other types of articles submitted to journals and publications.

We need to find more ways to share and distribute knowledge with the “traditional” medical and academic research world. And I’d love to do more – so please share ideas if you have them. And if you’re someone who bridges the gap to the traditional world, I appreciate your help sharing these types of articles and conversations with your colleagues.

DIYPS.org

#WeAreNotWaiting to make the world a better place

autotune

Regulatory Approval Is A Red Herring

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

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

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

Missing metrics in diabetes measurement by @DanaMLewis

Broken bones (trimalleolar ankle fracture), type 1 diabetes, and #OpenAPS

4 years DIY closed looping with #OpenAPS – what changed and what hasn’t

Vitamin D and insulin sensitivity

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

Why a non-academic (patient) publishes in academic journals

Recent Posts

Recent Comments

Archives

Categories

Meta