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

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

Example citation:

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


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

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

The backstory on this study

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

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

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

Study Design:

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

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

Results:

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

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

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

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

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

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

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

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

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

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

In summary:

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

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


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

Example citation:

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

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

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

Missing metrics in diabetes measurement by @DanaMLewis

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

Missing_metrics_@DanaMLewis

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

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_DanaMLewisAmazingly, 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.

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.

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

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

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.

Ripple_effect_DanaMLewisThis 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:

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

Presentations and poster content from @DanaMLewis at #2018ADA

DanaMLewis_ADA2018As I mentioned, I am honored to have two presentations and a co-authored poster being presented at #2018ADA. As per my usual, I plan to post all content and make it fully available online as the embargo lifts. There will be three sets of content:

  • Poster 79-LB in Category 12-A Detecting Insulin Sensitivity Changes for Individuals with Type 1 Diabetes using “Autosensitivity” from OpenAPS’ poster, co-authored by Dana Lewis, Tim Street, Scott Leibrand, and Sayali Phatak.
  • Content from my presentation Saturday, The Data behind DIY Diabetes—Opportunities for Collaboration and Ongoing Research’, which is part of the “The Diabetes Do-It-Yourself (DIY) Revolution” Symposium!
  • Content from my presentation Monday, Improvements in A1c and Time-in-Range in DIY Closed-Loop (OpenAPS) Users’, co-authored by Dana Lewis, Scott Swain, and Tom Donner.

First up: the autosensitivity poster!

Dana_Scott_ADA2018_autosens_posterYou can find the full write up and content of the autosensitivity poster in a post over on OpenAPS.org. There’s also a twitter thread if you’d like to share this poster with others on Twitter or elsewhere.

Summary: we ran autosensitivity retrospectively on the command line to assess patterns of sensitivity changes for 16 individuals who had donated data in the OpenAPS Data Commons. Many had normal distributions of sensitivity, but we found a few people who trended sensitive or resistant, indicating underlying pump settings could likely benefit from a change.
2018 ADA poster on Autosensitivity from OpenAPS by DanaMLewis

 

Presentation:
The Data behind DIY Diabetes—Opportunities for Collaboration and Ongoing Research’

This presentation was a big deal to me, as it was flanked by 3 other excellent presentations on the topic of DIY and diabetes. Jason Wittmer gave a great overview and context setting of DIY diabetes, ranging from DIY remote monitoring and CGM tools all the way to DIY closed loops like OpenAPS. Jason is a dad who created OpenAPS rigs for his son with T1D. Lorenzo Sandini spoke about the clinician’s perspective for when patients come into the office with DIY tools. He knows it from both sides – he’s using OpenAPS rigs, and also has patients who use OpenAPS. And after my presentation, Joyce Lee also spoke about the overarching landscape of diabetes and the role DIY plays in this emerging technology space.

Why did I present as part of this group today? One of the roles I’ve taken on in the last few years in the OpenAPS community (among others) is a collaborator and facilitator of research with and about the community. I put together the first outcomes study (see here in JDST or here in a blog post form on OpenAPS.org) in 2016. We presented a poster on Autotune last year at ADA (see here in a blog post form on OpenAPS.org). I’ve also worked to create and manage the OpenAPS Data Commons, as well as build tools for researchers to use this data, so individuals can easily and anonymously donate their DIY closed loop data for other research projects, lowering the friction and barriers for both patients and researchers. And, I’ve co-led or led several research projects with the community’s data as a result.

My presentation was therefore about setting the stage with background on OpenAPS & how we ended up creating the OpenAPS Data Commons; presenting a selection of research projects that have utilized data from the community; highlighting other research projects working with the OpenAPS community; announcing a new international collaboration (OPEN – more coming on that in the future!) for research with the DIY community; and hopefully encouraging other diabetes researchers to think about sharing their work, data, methods, tools, and insights as openly possible to help us all move forward with improving the lives of people with diabetes.

That is, of course, quite an abbreviated summary! I’ve shared a thread on Twitter that goes into detail on each of the key points as part of the presentation, or there’s a version of this Twitter/presentation content also written below.

If you’re someone who wants to do research with retrospective data from the OpenAPS Data Commons, you can find out more about it here (including instructions on how to request data). And if you’re interested in prospective research, please do reach out as well!

Full content for those who don’t want to read Twitter:

Patients are often seen as passive recipients of care, but many of us PWDs have discovered that problems are opportunities to change things. My journey to DIY began after I was frustrated by my inability to hear CGM alarms at night. 4 years ago, there was no way for me to access my own device data in real time OR retrospectively. Thanks to John Costik for sharing his code, I was able to get my CGM data & send it to the cloud and down to my phone, creating a louder alarm. Scott and I created an algorithm to push notifications to me to take action. This was an ‘open loop’ system we called #DIYPS. With Ben West’s help, we realized could combine our algorithm with small, off-the-shelf hardware & a radio stick to automate insulin delivery. #OpenAPS was thus created, open sourcing all components of DIY closed loop system so others could close the loop, too. An #OpenAPS rig consists of a small computer, radio chip, & battery. The hardware is constantly evolving. Many of us also use Nightscout to visualize our closed loop data, and share with loved ones.

2018ADA_slide12018ADA_slide 42018ADA_slide 32018ADA_Slide 2

 

 

 

 

 

 

I closed the loop in December of 2015. As people learned about it, I got pushback: “It works for you, but how do you know it’s going to work for others?” I didn’t, and I said so. But that didn’t mean I shouldn’t share what was working for me.

Once we had dozens of users of #OpenAPS, we presented a research study at #2016ADA, with 18 individuals sharing outcomes data on A1c, TIR, and QOL improvements. (See that publication here: https://twitter.com/danamlewis/status/763782789070192640 ). I was often asked to share my data for people to analyze, but I’m not representative of entire #OpenAPS community. Plus, the community has kept growing: we estimate there are more than (n=1)*710+ (as of June 2018) people worldwide using different kinds of DIY APs. (Note: if you’d like to keep track of the growing #OpenAPS community, the count of loopers worldwide is updated periodically at  https://openaps.org/outcomes ).  I began to work with Open Humans to build the #OpenAPS Data Commons, enabling individuals to anonymously upload their data and consent to share it with the Data Commons.

2018ADA_Slide 52018ADA_Slide 62018ADA_Slide 72018ADA_Slide 8

 

 

 

 

 

Criteria for using the #OpenAPS Data Commons:

  • 1) share insights back with the community, especially if you find something about an individual’s data set where we should notify them
  • 2) publish in an accessible (and preferably open) manner

I’ve learned that not many are prepared to take advantage of the rich (and complex) data available from #OpenAPS users; and many researchers have varying background and skillsets.  To aid researchers, I created a series of open source tools (described here: http://bit.ly/2l5ypxq, and tools available at https://github.com/danamlewis/OpenHumansDataTools ) to help researchers & patients working with data.

2018ADA_Slide 10 2018ADA_Slide 9

 

 

 

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

  • 2018ADA_Slide 112018ADA_Slide 12One research project, in collaboration with a Stanford team, evaluated published machine learning model predictions & #OpenAPS predictions. Some models (particularly linear regression) = accurate predictions in short term, but less so longer term when insulin peaks. This study is pending publication, but I’d like to note the challenge of more traditional research keeping pace with DIY innovation: the code (and data) studied was from January 2017. #OpenAPS prediction code has been updated 2x since then.
  • In response to the feedback from the #2016ADA #OpenAPS Outcomes study we presented, a follow up study on #OpenAPS outcomes was created in partnership with a team at Johns Hopkins. That study will be presented on Monday, 6-6:15pm (352-OR).
  • 2018ADA_Slide 13Many people share publicly online their outcomes with DIY closed loops. Sulka Haro has shared his script to evaluate the reduction in daily manual diabetes interventions after they began using #OpenAPS. Before: 4.5/day manual corrections; now they treat <1/day.
  • #OpenAPS features such as autosensitivity automatically detect sensitivity changes and insulin needs, improving outcomes. (See above at the top of this post for the full poster content).
  • If you missed it at #2017ADA (see here: http://bit.ly/2rMBFmn) , Autotune is a tool for assessing changes to basal rates, ISF, and carb ratio. Developed for #OpenAPS users but can also be used by traditional pumpers (and some MDI users also utilize it).

I’m also thrilled to share a new tool we’ve created: an #OpenAPS simulator to allow us to more easily back-test and compare settings changes & feature changes in #OpenAPS code.
2018ADA_Slide 14

  • Screen Shot 2018-06-22 at 4.48.06 PM2018ADA_Slide 16  We pulled a recent week of data for n=1 adult PWD who does no-bolus, rough carb entry meal announcements, and ran the simulator to predict what the outcomes would be for no-bolus and no meal-announcement.

 

  • 2018ADA_Slide 172018ADA_Slide 18 We also ran the simulator on n=1 teen PWD who does no-bolus and no-meal-announcement in real life. The simulator tracked closely to his actual outcomes (validated this week with a lab-A1c of 6.1)

 

 

 

The new #OpenAPS simulator will allow us to better test future algorithm changes and features across a diverse data set donated by DIY closed loop users.

There are many other studies & collaborations ongoing with the DIY community.

  • Michelle Litchman, Perry Gee, Lesly Kelly, and myself have a paper pending review analyzing social-media-reported outcomes & themes from DIY community.
  • 2018ADA_Slide 19There are also multiple other posters about DIY outcomes here at #2018ADA:
  • 2018ADA_Slide 20 There are many topics of interest in DIY community we’d like to see studies on, and have data for. These include: “eating soon” (optimal insulin dosing for lesser post-prandial spikes); and variability in sensitivity for various ages, pregnancy, and menstrual cycle.
  • 2018ADA_Slide 21I’m also thrilled to announce funding will be awarded to OPEN (a new collaboration on Outcomes of Patients’ Evidence, with Novel, DIY-AP tech), a 36-month international collaboration assessing outcomes, QOL, further development, access of real-world AP tech, etc. (More to come on this soon!)

In summary: we don’t have a choice in living with diabetes. We *do* have a choice to DIY, and also to research to learn more and improve knowledge and availability of tools for us PWDs, more quickly. We would love to partner and collaborate with anyone interested in working with the DIY community, whether that is utilizing the #OpenAPS Data Commons for retrospective studies or designing prospective studies. If you take away one thing today: let it be the request for us to all openly share our tools, data, and insights so we can all make life with type 1 diabetes better, faster.

2018ADA_Slide 222018ADA_Slide 23

 

 

 

 

A huge thank you as always to the community: those who have donated and shared data; those who have helped develop, test, troubleshoot, and otherwise help power the #OpenAPS and other DIY diabetes communities.

2018ADA_Slide 24

Presentation:
Improvements in A1c and Time-in-Range in DIY Closed-Loop (OpenAPS) Users

(full tweet thread available here; or a description of this presentation below)

#OpenAPS is an open and transparent effort to make safe and effective Artificial Pancreas System (APS) technology widely available to reduce the burden of Type 1 diabetes. #OpenAPS evolved from my first DIY closed loop system and our desire to openly share what we’ve learned living with DIY closed loops. It takes a small, off-the-shelf computer; a radio; and a battery to communicate with existing insulin pumps and CGMs. As a PWD, I care a lot about safety: the safety reference design is the first thing in #OpenAPS that was shared, in order to help set expectations around what a DIY closed loop can (and cannot) do.

ADA2018_Slide 23ADA2018_Slide 24As I shared about my own DIY experience, people questioned whether it would work for others, or just me. At #2016ADA, we presented an outcomes study with data from 18 of the first 40 DIY closed loop users. Feedback on that study included requests to evaluate CGM data, given concerns around accuracy of self-reported outcomes.

This 2018 #OpenAPS outcomes study was the result. We performed a retrospective cross-over analysis of continuous BG readings recorded during 2-week segments 4-6 weeks before and after initiation of OpenAPS.

ADA2018_Slide 26For this study, n=20 based on the availability of data that met the stringent protocol requirements (and the limited number of people who had both recorded that data and donated it to the #OpenAPS Data Commons in early 2017).  Demographics show that, like the 2016 study, the people choosing to #OpenAPS typically have lower A1C than the average T1D population; have had diabetes for over a decade; and are long-time pump and CGM users. Like the 2016 study, this 2018 study found mean BG and TIR improved across all time categories (overall, day, and nighttime).

ADA2018_Slide 28ADA2018_Slide 29ADA2018_Slide 30ADA2018_Slide 31ADA2018_Slide 32

Overall, mean BG (mg/dl) improved (135.7 to 128.3); mean estimated HbA1c improved (6.4 to 6.1%). TIR (70-180) increased from 75.8 to 82.2%. Overall, time spent high and low were all reduced, in addition to eAG and A1c reduction. Overnight (11pm-7am) had smaller improvement in all categories compared to daytime improvements in these categories.

Notably: although this study primarily focused on a 4-6 week time frame pre-looping vs. 4-6 weeks post-looping, the improvements in all categories are sustained over time by #OpenAPS users.

ADA2018_Slide 33 ADA2018_Slide 34

ADA2018_Slide 35Conclusion: Even with tight initial control, persons with T1D saw meaningful improvements in estimated A1c, TIR, and a reduction in time spent high and low, during the day and at night, after initiating #OpenAPS. Although this study focused on BG data from CGM, do not overlook additional QOL benefits when analyzing benefits of hybrid closed loop therapy or designing future studies! See these examples shared from Sulka Haro and Jason Wittmer as example of quality of life impacts of #OpenAPS.

A huge thank you to the community: those who have donated and shared data; those who have helped develop, test, troubleshoot, and otherwise help power the #OpenAPS and other DIY diabetes communities.

And, special thank you to my co-authors, Scott Swain & Tom Donner, for the collaboration on this study. Lewis_Donner_Swain_ADA2018

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

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:

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

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

  2. 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.
  3. 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. :)

  4. Q: Will any of this work for people NOT on Fiasp?
    A: Nothing is guaranteed (even for other people on Fiasp), but the folks who’ve started testing 0.6.0 even without Fiasp (on Humalog or Novolog/Novorapid, etc.) have been happier on it vs. earlier versions, too.

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

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

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

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

If you give a mouse a cookie or give a patient their data, great things will happen.

First, it was louder CGM alarms and predictive alerts (#DIYPS).

Next, it was a basic hybrid closed loop artificial pancreas that we open sourced so other people could build one if they wanted to (#OpenAPS, with the oref0 basic algorithm).

Then, it was all kinds of nifty lessons learned about timing insulin activity optimally (do eating soon mode around an hour before a meal) and how to use things like IFTTT integration to squash even the tiniest (like from 100mg/dL to 140mg/dL) predictable rises.

It was also things like displays, button, widgets on the devices of my choice – ranging from being able to “text” my pancreas, to a swipe and button tap on my phone, to a button press on my watch – not to mention tinier sized pancreases that fit in or clip easily to a pocket.

Then it was autosensitivity that enabled the system to adjust to my changing circumstances (like getting a norovirus), plus autotune to make sure my baseline pump settings were where they needed to be.

And now, it’s oref1 features that enable me to make different choices at every meal depending on the social situation and what I feel like doing, while still getting good outcomes. Actually, not good outcomes. GREAT outcomes.

With oref0 and OpenAPS, I’d been getting good or really good outcomes for 2 years. But it wasn’t perfect – I wasn’t routinely getting 100% time in range with lower end of the range BG for a 24hour average. ~90% time in range was more common. (Note – this time in range is generally calculated with 80-160mg/dL. I could easily “get” higher time in range with an 80-180 mg/dL target, or a lot higher also with a 70-170mg/dL target, but 80-160mg/dL was what I was actually shooting for, so that’s what I calculate for me personally). I was fairly happy with my average BGs, but they could have been slightly better.

I wrote from a general perspective this week about being able to “choose one” thing to give up. And oref1 is a definite game changer for this.

  • It’s being able to put in a carb estimate and do a single, partial bolus, and see your BG go from 90 to peaking out at 130 mg/dL despite a large carb (and pure ballpark estimate) meal. And no later rise or drop, either.
  • It’s now seeing multiple days a week with 24 hour average BGs a full ~10 or so points lower than you’re used to regularly seeing – and multiple days in a week with full 100% time in range (for 80-160mg/dL), and otherwise being really darn close to 100% way more often than I’ve been before.

But I have to tell you – seeing is believing, even more than the numbers show.

I remember in the early days of #DIYPS and #OpenAPS, there were a lot of people saying “well, that’s you”. But it’s not just me. See Tim’s take on “changing the habits of a lifetime“. See Katie’s parent perspective on how much her interactions/interventions have lessened on a daily basis when testing SMB.

See this quote from Matthias, an early tester of oref1:

I was pretty happy with my 5.8% from a couple months of SMB, which has included the 2 worst months of eating habits in years.  It almost feels like a break from diabetes, even though I’m still checking hourly to make sure everything is connected and working etc and periodically glancing to see if I need to do anything.  So much of the burden of tight control has been lifted, and I can’t even do a decent job explaining the feeling to family.

And another note from Katie, who started testing SMB and oref1:

We used to battle 220s at this time of day (showing a picture flat at 109). Four basal rates in morning. Extra bolus while leaving house. Several text messages before second class of day would be over. Crazy amount of work [in the morning]. Now I just have to brush my teeth.

And this, too:

I don’t know if I’ve ever gone 24 hours without ANY mention of something that was because of diabetes to (my child).

Ya’ll. This stuff matters. Diabetes is SO much more than the math – it’s the countless seconds that add up and subtract from our focus on school/work/life. And diabetes is taking away this time not just from a person with diabetes, but from our parents/spouses/siblings/children/loved ones. It’s a burden, it’s stressful…and everything we can do matters for improving quality of life. It brings me to tears every time someone posts about these types of transformative experiences, because it’s yet another reminder that this work makes a real difference in the real lives of real people. (And, it’s helpful for Scott to hear this type of feedback, too – since he doesn’t have diabetes himself, it’s powerful for him to see the impact of how his code contributions and the features we’re designing and building are making a difference not just to BG outcomes.)

Thank you to everyone who keeps paying it forward to help others, and to all of you who share your stories and feedback to help and encourage us to keep making things better for everyone.

 

Why guess when you don’t have to? (#OpenAPS logs & why they’re handy)

One of the biggest benefits (in my very biased opinion) of a DIY closed loop is this: it’s designed to be understandable to the person using it.

You don’t have to guess “what did it do at 2am?” or “why did it do a temp basal and not an SMB?”

Well, you COULD guess – but you don’t have to. Guessing is a choice ;).

Because we’ve been designing a system that a person has to decide to trust, it provides information about everything it’s doing and the information it has. That’s what “the logs” are for, and you can get information from “the logs” from a couple of places:

  • The OpenAPS “pill” in Nightscout
  • Secondary logging sources like Papertrail
  • Information that shows up on your Pebble watch
  • The full logs from SSH’ing into a rig (usually what we mean when we ask, “what do your logs say?”)

Here’s an example of the information the OpenAPS pill provides me in Nightscout:

Example OpenAPS pill info in Nightscout

This tells me that at 11:03 am, my BG was 121; I had no carbs on board; was dropping a tiny bit as expected and was likely going to end up slightly below my target; and the current temporary basal rate running was about equivalent to what OpenAPS thought I needed at the time. I had 0.47 netIOB, all from basal adjustments. It also specifies some of the eventual numbers that are what trigger the “purple line predictions” displayed in Nightscout, so if you can’t tell where the line is (90 or 100?), you can use the pill information to determine that more easily.

(Here’s the instructions for setting up Nightscout for OpenAPS)

Here’s an example of a log from Papertrail and what it tells us:

Example papertrail usage for OpenAPS

This example is from Katie, who described her daughter’s patterns in the morning: when Anna leaves her rig in the bedroom and went to take a shower, you can see the tune change at around 6:55, meaning she’s out of range of the rig. After the shower, getting dressed, and getting back to the rig around 7:25, it goes back to “normal” tuning (which means reading and writing to the pump as usual).

Papertrail is handy for figuring out if a rig is working or not remotely and high level why it might not be, especially if it’s a communication or power problem. But I generally find it to be most helpful when you know what kind of problem it is, and use it to drill down on a particular thing. However, it’s not going to give you absolutely all the details needed for every problem – so make sure to read about how to access the traditional logs, too, and be able to do that on the go.

(Here’s the instructions for getting Papertrail going for OpenAPS)

Here’s what the logs ported to my Pebble tell me:

OpenAPS logs on Pebble watch @DanaMLewis example

There’s several helpful things that display on my watch (using the excellent “Urchin” watchface designed by Mark Wilson, which you can customize to suit your personal preference): BGs, basal activity, and then some detailed text, similar to what’s in the OpenAPS pill (current BG, the change in BG, timestamp of BG, my netIOB, my eventual BGs, and any temp basal activity). In this case, it’s easy for me to glance and see that I was a bit low for a while; am now flat but have negative net IOB so it’s been high temping a bit to level out the netIOB.

(I’ve always preferred a data-rich watchface – even back in the days of “open looping” with #DIYPS:)

https://twitter.com/danamlewis/status/652566409537433600/photo/1

(Here’s more about the Urchin watchface)

Here’s what the full logs from the rig tell me:

Example OpenAPS logs from the rig

This has a LOT of information in it (which is why it’s so awesome). There are messages being shared by each step of the loop – when it’s listening for “silence” to make sure it can talk successfully to the pump; refreshing pump history; checking the clocks on devices and for fresh BGs; and then processing through the math on what the BG is, where it’s headed, and what needs to happen. You can also see from this example where autosensitivity is kicking in, adjust basals slightly up, target down, and sensitivity down, etc. (And for those who aren’t testing oref1 features like SMB and UAM yet, you’ll get a glimpse of how there’s now additional information in the logs about if those features are currently enabled.)

(Here are some other logs you can watch, and how to run them)

Pro tip for OpenAPS users: if you’re logged into your rig, you just have to type l (the letter “L” but lower case) for it to bring up your logs!

So if you find yourself wondering: what did OpenAPS do/why did it do <thing>? Instead of wondering, start by looking at the logs.

And remember, if you don’t know what the problem is – the full logs are the best source of information for spotting what the main problem is. You can then use the information from the logs to ask about how to resolve a particular problem (Gitter is great for this!)– but part of troubleshooting well/finding out more is taking the first step to pull up your logs, because anyone who is going to help you troubleshoot will need that information to figure out a solution.

And if you ever see someone say “RTFL”, instead of “read the manual” or “read the docs”, it means “read the logs”. 😉 :)

Introducing oref1 and super-microboluses (SMB) (and what it means compared to oref0, the original #OpenAPS algorithm)

For a while, I’ve been mentioning “next-generation” algorithms in passing when talking about some of the work that Scott and I have been doing as it relates to OpenAPS development. After we created autotune to help people (even non-loopers) tune underlying pump basal rates, ISF, and CSF, we revisited one of our regular threads of conversations about how it might be possible to further reduce the burden of life with diabetes with algorithm improvements related to meal-time insulin dosing.

This is why we first created meal-assist and then “advanced meal-assist” (AMA), because we learned that most people have trouble with estimating carbs and figuring out optimal timing of meal-related insulin dosing. AMA, if enabled and informed about the number of carbs, is a stronger aid for OpenAPS users who want extra help during and following mealtimes.

Since creating AMA, Scott and I had another idea of a way that we could do even more for meal-time outcomes. Given the time constraints and reality of currently available mealtime insulins (that peak in 60-90 minutes; they’re not instantaneous), we started talking about how to leverage the idea of a “super bolus” for closed loopers.

A super bolus is an approach you can take to give more insulin up front at a meal, beyond what the carb count would call for, by “borrowing” from basal insulin that would be delivered over the next few hours. By adding insulin to the bolus and then low temping for a few hours after that, it essentially “front shifts” some of the insulin activity.

Like a lot of things done manually, it’s hard to do safely and achieve optimal outcomes. But, like a lot of things, we’ve learned that by letting computers do more precise math than we humans are wont to do, OpenAPS can actually do really well with this concept.

Introducing oref1

Those of you who are familiar with the original OpenAPS reference design know that ONLY setting temporary basal rates was a big safety constraint. Why? Because it’s less of an issue if a temporary basal rate is issued over and over again; and if the system stops communicating, the temp basal eventually expires and resume normal pump activity. That was a core part of oref0. So to distinguish this new set of algorithm features that depart from that aspect of the oref0 approach, we are introducing it as “oref1”. Most OpenAPS users will only use oref0, like they have been doing. oref1 should only be enabled specifically by any advanced users who want to test or use these features.

The notable difference between the oref0 and oref1 algorithms is that, when enabled, oref1 makes use of small “supermicroboluses” (SMB) of insulin at mealtimes to more quickly (but safely) administer the insulin required to respond to blood sugar rises due to carb absorption.

Introducing SuperMicroBoluses (or “SMB”)

The microboluses administered by oref1 are called “super” because they use a miniature version of the “super bolus” technique described above.  They allow oref1 to safely dose mealtime insulin more rapidly, while at the same time setting a temp basal rate of zero of sufficient duration to ensure that BG levels will return to a safe range with no further action even if carb absorption slows suddenly (for example, due to post-meal activity or GI upset) or stops completely (for example due to an interrupted meal or a carb estimate that turns out to be too high). Where oref0 AMA might decide that 1 U of extra insulin is likely to be required, and will set a 2U/hr higher-than-normal temporary basal rate to deliver that insulin over 30 minutes, oref1 with SMB might deliver that same 1U of insulin as 0.4U, 0.3U, 0.2U, and 0.1U boluses, at 5 minute intervals, along with a 60 minute zero temp (from a normal basal of 1U/hr) in case the extra insulin proves unnecessary.

As with oref0, the oref1 algorithm continuously recalculates the insulin required every 5 minutes based on CGM data and previous dosing, which means that oref1 will continually issue new SMBs every 5 minutes, increasing or reducing their size as needed as long as CGM data indicates that blood glucose levels are rising (or not falling) relative to what would be expected from insulin alone.  If BG levels start falling, there is generally already a long zero temp basal running, which means that excess IOB is quickly reduced as needed, until BG levels stabilize and more insulin is warranted.

Safety constraints and safety design for SMB and oref1

Automatically administering boluses safely is of course the key challenge with such an algorithm, as we must find another way to avoid the issues highlighted in the oref0 design constraints.  In oref1, this is accomplished by using several new safety checks (as outlined here), and verifying all output, before the system can administer a SMB.

At the core of the oref1 SMB safety checks is the concept that OpenAPS must verify, via multiple redundant methods, that it knows about all insulin that has been delivered by the pump, and that the pump is not currently in the process of delivering a bolus, before it can safely do so.  In addition, it must calculate the length of zero temp required to eventually bring BG levels back in range even with no further carb absorption, set that temporary basal rate if needed, and verify that the correct temporary basal rate is running for the proper duration before administering a SMB.

To verify that it knows about all recent insulin dosing and that no bolus is currently being administered, oref1 first checks the pump’s reservoir level, then performs a full query of the pump’s treatment history, calculates the required insulin dose (noting the reservoir level the pump should be at when the dose is administered) and then checks the pump’s bolusing status and reservoir level again immediately before dosing.  These checks guard against dosing based on a stale recommendation that might otherwise be administered more than once, or the possibility that one OpenAPS rig might administer a bolus just as another rig is about to do so.  In addition, all SMBs are limited to 1/3 of the insulin known to be required based on current information, such that even in the race condition where two rigs nearly simultaneously issue boluses, no more than 2/3 of the required insulin is delivered, and future SMBs can be adjusted to ensure that oref1 never delivers more insulin than it can safely withhold via a zero temp basal.

In some situations, a lack of BG or intermittent pump communications can prevent SMBs from being delivered promptly.  In such cases, oref1 attempts to fall back to oref0 + AMA behavior and set an appropriate high temp basal.  However, if it is unable to do so, manual boluses are sometimes required to finish dosing for the recently consumed meal and prevent BG from rising too high.  As a result, oref1’s SMB features are only enabled as long as carb impact is still present: after a few hours (after carbs all decay), all such features are disabled, and oref1-enabled OpenAPS instances return to oref0 behavior while the user is asleep or otherwise not engaging with the system.

In addition to these safety status checks, the oref1 algorithm’s design helps ensure safety.  As already noted, setting a long-duration temporary basal rate of zero while super-microbolusing provides good protection against hypoglycemia, and very strong protection against severe hypoglycemia, by ensuring that insulin delivery is zero when BG levels start to drop, even if the OpenAPS rig loses communication with the pump, and that such a suspension is long enough to eventually bring BG levels back up to the target range, even if no manual corrective action is taken (for example, during sleep).  Because of these design features, oref1 may even represent an improvement over oref0 w/ AMA in terms of avoiding post-meal hypoglycemia.

In real world testing, oref1 has thus far proven at least as safe as oref0 w/ AMA with regard to hypoglycemia, and better able to prevent post-meal hyperglycemia when SMB is ongoing.

What does SMB “look” like?

Here is what SMB activity currently looks like when displayed on Nightscout, and my Pebble watch:

First oref1 SMB OpenAPS test by @DanaMLewisFirst oref1 SMB OpenAPS test as seen on @DanaMLewis pebble watch

How do features like this get developed and tested?

SMB, like any other advanced feature, goes through extensive testing. First, we talk about it. Then, it becomes written up in plain language as an issue for us to track discussion and development. Then we begin to develop the feature, and Scott and I test it on a spare pump and rig. When it gets to the point of being ready to test it in the real world, I test it during a time period when I can focus on observing and monitoring what it is doing. Throughout all of this, we continue to make tweaks and changes to improve what we’re developing. After several days (or for something this different, weeks) of Dana-testing, we then have a few other volunteers begin to test it on spare rigs. They follow the same process of monitoring it on spare rigs and giving feedback and helping us develop it before choosing to run it on a rig and a pump connected to their body. More feedback, discussion, and observation. Eventually, it gets to a point where it is ready to go to the “dev” branch of OpenAPS code, which is where this code is now heading. Several people will review the code and approve it to be added to the “dev” branch. We will then have others test the “dev” branch with this and any other features or code changes – both by people who want to enable this code feature, as well as people who don’t want this feature (to make sure we don’t break existing setups). Eventually, after numerous thumbs up from multiple members of the community who have helped us test different use cases, that code from the “dev” branch will be “approved” and will go to the “master” branch of code where it is available to a more typical user of OpenAPS.

However, not everyone automatically gets this code or will use it. People already running on the master branch won’t get this code or be able to use it until they update their rig. Even then, unless they were to specifically enable this feature (or any other advanced feature), they would not have this particular segment of code drive any of their rig’s behavior.

Where to find out more about oref1, SMB, etc.:

  • We have updated the OpenAPS Reference Design to reflect the differences between oref0 and the oref1 features.
  • OpenAPS documentation about oref1, which as of July 13, 2017 is now part of the master branch of oref0 code.
  • Ask questions! Like all things developed in the OpenAPS community, SMB and oref1-related features will evolve over time. We encourage you to hop into Gitter and ask questions about these features & whether they’re right for you (if you’re DIY closed looping).

Special note of thanks to several people who have contributed to ongoing discussions about SMB, plus the very early testers who have been running this on spare rigs and pumps. Plus always, ongoing thanks to everyone who is contributing and has contributed to OpenAPS development!