Autotune (automatically assessing basal rates, ISF, and carb ratio with #OpenAPS – and even without it!)

What if, instead of guessing needed changes (the current most used method) basal rates, ISF, and carb ratios…we could use data to empirically determine how these ratios should be adjusted?

Meet autotune.

What if we could use data to determine basal rates, ISF and carb ratio? Meet autotune

Historically, most people have guessed basal rates, ISF, and carb ratios. Their doctors may use things like the “rule of 1500” or “1800” or body weight. But, that’s all a general starting place. Over time, people have to manually tweak these underlying basals and ratios in order to best live life with type 1 diabetes. It’s hard to do this manually, and know if you’re overcompensating with meal boluses (aka an incorrect carb ratio) for basal, or over-basaling to compensate for meal times or an incorrect ISF.

And why do these values matter?

It’s not just about manually dosing with this information. But importantly, for most DIY closed loops (like #OpenAPS), dose adjustments are made based on the underlying basals, ISF, and carb ratio. For someone with reasonably tuned basals and ratios, that’s works great. But for someone with values that are way off, it means the system can’t help them adjust as much as someone with well-tuned values. It’ll still help, but it’ll be a fraction as powerful as it could be for that person.

There wasn’t much we could do about that…at first. We designed OpenAPS to fall back to whatever values people had in their pumps, because that’s what the person/their doctor had decided was best. However, we know some people’s aren’t that great, for a variety of reasons. (Growth, activity changes, hormonal cycles, diet and lifestyle changes – to name a few. Aka, life.)

With autosensitivity, we were able to start to assess when actual BG deltas were off compared to what the system predicted should be happening. And with that assessment, it would dynamically adjust ISF, basals, and targets to adjust. However, a common reaction was people seeing the autosens result (based on 24 hours data) and assume that mean that their underlying ISF/basal should be changed. But that’s not the case for two reasons. First, a 24 hour period shouldn’t be what determines those changes. Second, with autosens we cannot tell apart the effects of basals vs. the effect of ISF.

Autotune, by contrast, is designed to iteratively adjust basals, ISF, and carb ratio over the course of weeks – based on a longer stretch of data. Because it makes changes more slowly than autosens, autotune ends up drawing on a larger pool of data, and is therefore able to differentiate whether and how basals and/or ISF need to be adjusted, and also whether carb ratio needs to be changed. Whereas we don’t recommend changing basals or ISF based on the output of autosens (because it’s only looking at 24h of data, and can’t tell apart the effects of basals vs. the effect of ISF), autotune is intended to be used to help guide basal, ISF, and carb ratio changes because it’s tracking trends over a large period of time.

Ideally, for those of us using DIY closed loops like OpenAPS, you can run autotune iteratively inside the closed loop, and let it tune basals, ISF, and carb ratio nightly and use those updated settings automatically. Like autosens, and everything else in OpenAPS, there are safety caps. Therefore, none of these parameters can be tuned beyond 20-30% from the underlying pump values. If someone’s autotune keeps recommending the maximum (20% more resistant, or 30% more sensitive) change over time, then it’s worth a conversation with their doctor about whether your underlying values need changing on the pump – and the person can take this report in to start the discussion.

Not everyone will want to let it run iteratively, though – not to mention, we want it to be useful to anyone, regardless of which DIY closed loop they choose to use – or not! Ideally, this can be run one-off by anyone with Nightscout data of BG and insulin treatments. (Note – I wrote this blog post on a Friday night saying “There’s still some more work that needs to be done to make it easier to run as a one-off (and test it with people who aren’t looping but have the right data)…but this is the goal of autotune!” And as by Saturday morning, we had volunteers who sat down with us and within 1-2 hours had it figured out and documented! True #WeAreNotWaiting. :))

And from what we know, this may be the first tool to help actually make data-driven recommendations on how to change basal rates, ISF, and carb ratios.

How autotune works:

Step 1: Autotune-prep

  • Autotune-prep takes three things initially: glucose data; treatments data; and starting profile (originally from pump; afterwards autotune will set a profile)
  • It calculates BGI and deviation for each glucose value based on treatments
  • Then, it categorizes each glucose value as attributable to either carb sensitivity factor (CSF), ISF, or basals
  • To determine if a “datum” is attributable to CSF, carbs on board (COB) are calculated and decayed over time based on observed BGI deviations, using the same algorithm used by Advanced Meal Asssit. Glucose values after carb entry are attributed to CSF until COB = 0 and BGI deviation <= 0. Subsequent data is attributed as ISF or basals.
  • If BGI is positive (meaning insulin activity is negative), BGI is smaller than 1/4 of basal BGI, or average delta is positive, that data is attributed to basals.
  • Otherwise, the data is attributed to ISF.
  • All this data is output to a single file with 3 sections: ISF, CSF, and basals.

Step 2: Autotune-core

  • Autotune-core reads the prepped glucose file with 3 sections. It calculates what adjustments should be made to ISF, CSF, and basals accordingly.
  • For basals, it divides the day into hour long increments. It calculates the total deviations for that hour increment and calculates what change in basal would be required to adjust those deviations to 0. It then applies 20% of that change needed to the three hours prior (because of insulin impact time). If increasing basal, it increases each of the 3 hour increments by the same amount. If decreasing basal, it does so proportionally, so the biggest basal is reduced the most.
  • For ISF, it calculates the 50th percentile deviation for the entire day and determines how much ISF would need to change to get that deviation to 0. It applies 10% of that as an adjustment to ISF.
  • For CSF, it calculates the total deviations over all of the day’s mealtimes and compares to the deviations that are expected based on existing CSF and the known amount of carbs entered, and applies 10% of that adjustment to CSF.
  • Autotune applies a 20% limit on how much a given basal, or ISF or CSF, can vary from what is in the existing pump profile, so that if it’s running as part of your loop, autotune can’t get too far off without a chance for a human to review the changes.

(See more about how to run autotune here in the OpenAPS docs.)

What autotune output looks like:

Here’s an example of autotune output.

OpenAPS autotune example by @DanaMLewis

Autotune is one of the things Scott and I spent time on over the holidays (and hinted about at the end of my development review of 2016 for OpenAPS). As always with #OpenAPS, it’s awesome to take an idea, get it coded up, get it tested with some early adopters/other developers within days, and continue to improve it!

A big thank you to those who’ve been testing and helping iterate on autotune (and of course, all other things OpenAPS). It’s currently in the dev branch of oref0 for anyone who wants to try it out, either one-off or for part of their dev loop. Documentation is currently here, and this is the issue in Github for logging feedback/input, along with sharing and asking questions as always in Gitter!

 

 

Our take on how to DIY closed loop, safely

You will often see similar growth and evolution cycles across any type of online community, and the closed loop community is following this growth cycle as expected. Much like how Nightscout went from one very hard way to setup to get your CGM data in the cloud, to ultimately having dozens of DIY options and now more recently, multiple commercial options, closed looping is following similar trends. OpenAPS was the first open source option for people who wanted to DIY loop, and now there are a growing number of ways to build or run closed loops! And next year, there should be at least one commercial option publicly available in the U.S. followed by several more options in 2018 on the commercial market. Awesome! This is exactly the progress we were hoping to see, and facilitate happening more quickly, by making our work & encouraging others to make their work open source.

We’ve learned a lot (from building our own closed loop and watching others do so through OpenAPS) that we think is relevant to anyone who pursues DIY closed looping, regardless of the technology option they choose. This thought process and approach will likely also be relevant to those who switch to a closed loop commercial option in the future, so we wanted to document some of the thought process that may be involved.

Approaching closed looping safely

Before considering closed looping, people should know:

  • A (hybrid or even full) closed loop is not a cure. There will be a learning curve, much like switching to a pump for the first time.
  • Even after you get comfortable with a closed loop, there will still sometimes be high or low BGs, because we are still dealing with insulin that peaks in 60-90 minutes; we’ll still get kinked pump sites or pooled insulin; and we’ll still have hormones that drive our BGs up and down very rapidly in ways we can’t predict, but must react to. Closed looping helps a lot, but there’s still a lot that goes into managing diabetes.

Before using a DIY closed loop, people should consider:

  • Identifying or creating the method to visualize their data in a way they are comfortable with, both for real-time monitoring of loop activity and retrospective monitoring. This is a key component of DIY looping.
  • Running in “open loop” mode, where the system provides recommendations and you spend days or weeks analyzing and comparing those recommendations to how you would calculate and choose to take action manually.
  • Based on watching the “open loop” suggestions, decide your safety limits: you should set max basal and bolus rates, as well as max net IOB limits where relevant. Start conservative, knowing you can change them over time as you watch and validate how a particular DIY loop works with your body and your lifestyle.

Getting started with a DIY closed loop, people should think about the following:

  • Understand how it works, so you know how to fix it. Remember, by pursuing a DIY closed loop, you are responsible for it and the operation of it. No one is forcing you to do this; it’s one of many choices you can and will make with regards to how you personally choose to manage your diabetes.
  • But even more importantly, you need to understand how it works so you can choose if you need to step in and take manual action. You should understand how it works so you can validate “this is what it should be doing” and “I am getting the output and outcomes that I would expect if I were doing this decision making manually”.
  • Often, people will get frustrated by diabetes and take actions that the loop then has to compensate for. Or they’ll get lax on when they meal bolus, or not enter carbs into the system, etc. You will get much better results by putting better data into the system, and also by having a better understanding of insulin timing in your body, especially at meal times. Using techniques like “eating soon mode” will dramatically help anyone, with or without a closed loop, reduce and limit severity of meal spikes. Ditto goes for having good CGM “calibration hygiene” (h/t to Pete for this phrase) and ensuring you have thought about the ramifications of automating insulin dosing based on CGM data, and how you may or may not want to loop if you doubt your CGM data. (Like “eating soon”, ‘soaking’ a CGM sensor may yield you better first day results.)
  • Start with higher targets for the loop than you might correct to manually.
  • Move first from an “open loop” mode to a “low glucose suspend” type mode first, where max net IOB is 0 and/or max basal is set at or just above your max daily scheduled basal, so it low temps to prevent and limit lows, but does not high temp above bringing net IOB back to 0.
  • Gradually increase max net IOB above 0 (and/or increase max basal) every few days after several days without low BGs; similarly, adjust targets down 10 points for every few days gone without experiencing low BGs.
  • Test basic algorithms and adjust targets and various max rates before moving on to testing advanced features. (It will be a lot easier to troubleshoot, and learn how a new feature works, if you’re not also adjusting to closed looping in its entirety).
This is our (Dana & Scott‘s) take on things to think about before and when pursuing a closed loop option. But there’s about a hundred others running around the world with closed loops, too, so if you have input to share with people that they should consider before looping, leave a comment below! :) And if you’re looking to DIY closed loop before a commercial solution is available, you might also be interested in checking out the OpenAPS Reference Design and some FAQs related to OpenAPS.

What we heard and saw at #DData16 and #2016ADA

As mentioned in the previous post, we had the privilege of coming to New Orleans this past weekend for two events – #DData16 and the American Diabetes Association Scientific Sessions (#2016ADA). A few things stuck out, which I wanted to highlight here.

At #DData16:

  • The focus was on artificial pancreas, and there was a great panel moderated by Howard Look with several of the AP makers. I was struck by how many of them referenced or made mention of #OpenAPS or the DIY/#WeAreNotWaiting movement, and the need for industry to collaborate with the DIY community (yes).
  • I was also floored when someone from Dexcom referenced having read one of my older blog posts that mentioned a question of why ??? was displayed to me instead of the information about what was actually going on with my sensor. It was a great reminder to me of how important it is for us to speak up and keep sharing our experiences and help device manufacturers know what we need for current and future products, the ones we use every day to help keep us alive.
  • Mark Wilson gave a PHENOMENAL presentation, using a great analogy about driving and accessing the dashboard to help people understand why people with diabetes might choose to DIY. He also talked about his experiences with #OpenAPS, and I highly recommend watching it. (Kudos to Wes for livestreaming it and making it broadly available to all – watch it here!) I’ve mentioned Mark & his DIY-ing here before, especially because one of his creations (the Urchin watchface) is one of my favorite ways to help me view my data, my way.
  • Howard DM’ed me in the middle of the day to ask if I minded going up as part of the patient panel of people with AP experiences. I wasn’t sure what the topic was, but the questions allowed us to talk about our experiences with AP (and in my case, I’ve been using a hybrid closed loop for something like 557 or so days at this point). I made several points about the need for a “plug n play” system, with modularity so I can choose the best pump, sensor, and algorithm for me – which may or may not be made all by the same company. (This is also FDA’s vision for the future, and Dr. Courtney Lias both gave a good presentation on this topic and was engaged in the event’s conversation all day!).

At #2016ADA:

  • There needs to be a patient research access program developed (not just by the American Diabetes Association for their future Scientific Sessions meetings, but at all scientific and academic conferences). Technology has enabled patients to make significant contributions to the medical and scientific fields, and cost and access are huge barriers to preventing this knowledge from scaling. At #2016ADA, “patient” is not even an option on the back of the registration form. Scott and I are privileged that we could potentially pay for this, but we don’t think we should have to pay ($410 for a day pass or $900 for a weekend pass) so much when we are not backed by industry or an academic organization of any sort. (As a side note, a big thank you to the many people who have a) engaged in discussion around this topic b) helped reach out to contacts at ADA to discuss this topic and c) asked about ways to contribute to the cost of us presenting this research this weekend.)
  • We presented research from 18 of the first 40 users of #OpenAPS. You can find the FULL CONTENT of our findings and the research poster content in this post on OpenAPS.org. We specifically posted our content online (and tweeted it out – see this thread) for a few reasons:
    • First, everything about #OpenAPS is open source. The content of our poster or any presentation is similarly open source.
    • Not everyone had time to come by the poster.
    • Not everyone has the privilege or funds to attend #2016ADA, and there’s no reason not to share this content online, especially when we will likely get more knowledge sharing as a result of doing so.
  • With the above in mind, we encouraged people stopping by to take whatever photos of our poster that they wanted, and told them about the content being posted online. (And in fact, in addition to the blog post about the poster, that information is now on the “Outcomes” page on OpenAPS.org.)
  • Frustratingly, some people were asked to take down posted photos of our poster. If anyone received such a note, please feel free to pass on my tweet that you have authorization by the authors to have taken/used the photo. This is another area (like the need to develop patient research access programs) that needs to be figured out by scientific/academic conferences – presenters/authors should be able to specifically allow sharing and dissemination of information that they are presenting.
  • Speaking of photos, I was surprised that around half a dozen clinicians (HCPs) stopped by and made mention of having used the picture of the #OpenAPS rig and the story of #OpenAPS in one of their presentations! I am thrilled this story is spreading, and being spread even by people we haven’t had direct contact with previously! (Feel free to use this photo in presentations, too, although I’d love to hear about your presentation and see a copy of it!)
  • We had many amazing conversations during the poster session on Sunday. It was scheduled for two hours (12-2pm), but we ended up being there around four hours and had hundreds of fantastic dialogues. Here were some of the most common themes of conversation:
    • Why are patients doing this?
      • Here’s my why: I originally needed louder alarms, built a smart alarm system that had predictive alerts and turned into an open loop system, and ultimately realized I could close the loop.
    • What can we learn from the people who are DIY-ing?
    • How can we further study the DIY closed loop community?
      • This is my second favorite topic, which touches on a few things – 1) the plan to do a follow up study of the larger cohort (since we now have (n=1)*84 loopers) with a full retrospective analysis of the data rather than just self-reported outcomes, as this study used; 2) ideas around doing a comparison study between one or more of the #OpenAPS algorithms and some of the commercial or academic algorithms; 3) ideas to use some of the #OpenAPS-developed tools (like a basal tuning tool that we are planning to build) in a clinical trial to help HCPs help patients adjust more quickly and easily to pump therapy.
    • What other pumps will work with this? How can there be more access to this type of DIY technology?
      • We utilize older pumps that allow us to send temp basal commands; we would love to use a more modern pump that’s able to be purchased on the market today, and had several conversations with device manufacturers about how that might be possible;  we’ll continue to have these conversations until it becomes a reality.
  • There is some great coverage coming of the poster & the #OpenAPS community, and I’ll post links here as I see them come out. For starters, Dave deBronkart did a 22 minute interview with Scott & I, which you can see here. DiabetesMine also included mention of the #OpenAPS poster in their conference roundup. And diaTribe wrote up the the poster as a “new now next”! Plus, WebMD wrote an article on #OpenAPS and the poster as well.

Scott and I walked away from this weekend with energy for new collaborations (and new contacts for clinical trial and retrospective analysis partnerships) and several ideas for the next phase of studies that we want to plan in partnership with the #OpenAPS community. (We were blown away to discover that OpenAPS advanced meal assist algorithm is considered by some experts to be one of the most advanced and aggressive algorithms in existence for managing post-meal BG, and may be more advanced than anything that has yet been tested in clinical trials.) Stay tuned for more!

The second year of #DIYPS (and my first full year with a closed loop)

As we developed #DIYPS from a louder alarm system to a proactive alert system (details here about the original #DIYPS system before we closed the loop) to a closed loop that would auto-adjust my insulin pump basal rates as-needed overnight, I have been tracking the outcomes.

There were the first few nights of “wow! this works! I wake up at night when I’m high/low”. Then there were the first 100 nights that involved more iteration, testing, and improvements as we built it out more. And then suddenly it had been a year of using #DIYPS, and it was awesome to see how my average BG and a1c were down – and stayed down – while equally as important, my % time in range was up and stayed up. Not to mention, the quality of life improvements of having better nights of sleep were significant.

Year two has been along the same lines – more improvements on A1c/average BGs, time in range, and sleep – but heavily augmented by the fact that I now have a closed loop. If you follow me on Twitter or have checked out the hashtag, you might be tired of seeing me post CGM graphs. At this point, they all look very similar:

(It’s worth noting that I still use #DIYPS, especially during the day to trigger “eating-soon” mode or basically get a snapshot glance at what my BGs are predicted to be, especially if I plan to go out without my loop in tow.)

In this past year, we also went from closing the loop with the #DIYPS algorithms (which required internet connectivity so I could tell the system when I was having carbs), to deciding we wanted to find a way to make it possible for more people to safely DIY a closed loop. (And, we feel very strongly that the DIY part of closing the loop is very important and deciding to do so is a very personal question.)

Thus, #OpenAPS was born in February 2015. Ben West spent a lot of time in 2015 building out the openaps toolkit to enable communication with diabetes devices to make things like closed loops possible. And so the first few months of #OpenAPS seemed slow, while we were busy working on the toolkit and finding ways to take what we learned with the #DIYPS closed loop and model a closed loop that didn’t require knowledge of carbs and could work without internet connectivity (see more about the #OpenAPS reference design here).

In July, we saw a tipping point – multiple other people began to close the loop, despite the fact that we didn’t have very much documented or available to guide them beyond the reference design. (These first couple of folks are incredible! Watch the #OpenAPS hashtag on Twitter to see them share some of their experiences.) With their help, the documentation has grown by leaps and bounds, as has the number of people who were subsequently able to close the loop.

As of 12/31/15 as I write this post, there are 22 people who have told me that they have a closed loop running that’s based on the OpenAPS reference design. I make a big deal about marking the date when I make a statement about the number of people running #OpenAPS (i.e. (n=1)*22), because every time I turn around, someone else seems to have done it!

It’s so exciting to see what’s happened in 2015, and what this type of #WeAreNotWaiting spirit has enabled. For Scott & me this year: we’ve climbed mountains around the world (from Machu Picchu to Switzerland), gotten married, changed jobs, and explored Europe together. Diabetes was there, but it wasn’t the focus.

There are dozens of other amazing stories like this in the #WeAreNotWaiting community. As we look to the new year, and I start to wonder about what might be next, I realize the speed of technology and the spirit of ingenuity in this community makes it impossible to predict exactly what we’ll see in 2016.

What I do know is this: we’ll see more people closing the loop, and we’ll see more ways to close the loop, using devices other than the Raspberry Pi, Carelink stick and Medtronic pump.  We’ll see more new ways to communicate with old & new diabetes devices and more ways to make the diabetes parts of our lives easier – all because #WeAreNotWaiting.

The power of visualizing your data, your way

Sometimes, it’s the little things that make a big difference – even little glimpses of data, or little improvements to ways that you can control the way you access and view your data (and generate alarms).

For example, I recently had a conversation with a few people in the #WeAreNotWaiting community about the different watch faces that exist for displaying CGM data; and about how much I like my #DIYPS watch face. A few reasons why:

  • It’s a little more discreet than some watch faces showing BG data, so the average person won’t glance at my watch and see a large number.
  • It pulls from the #DIYPS interface, so I can see what I’m predicted to be, and any current recommendations (such as carbs, temp basal, or bolus needed).

It’s data-heavy, but I like having all this information without having to pull my CGM out and run calculations in my head; or pull out my phone and pull up a web page to #DIYPS; etc.

One of the many cool things about the #WeAreNotWaiting community is how together we have learned and created so many new ways to visualize our data, on various devices (tablets, phones, smart watches) and various size screens. And so when I hear that someone’s not wanting a smart watch, or isn’t using it for diabetes related things, sometimes I think it’s a matter of them finding the right tools to build their own display that works for them. Several times a week I hear about various people working on new, interesting DIY diabetes projects, and it’s awesome that we have tech to improve the tools we have – and excellent social media channels to communicate about these projects.

Related to that, I wanted to share an update – recently Milos, Jason, and others have done some really amazing work to visualize basal rates in Nightscout. (If you use Nightscout, you can get this in the 0.8.2 release – see here for more details.) This means it also can pull in temporary basal rates that are used in #OpenAPS, so you can get a nice visual showing the adjusted basal rate compared to normal scheduled basal rates – and see why it might be needed – on top of display of BG data and everything else that Nightscout offers.

In this example, it also shows how OpenAPS deals with compression drops, or how it might react to other flukey data. Remember, we designed OpenAPS to only enact 30 minute temporary basal rates in a way that is the safest possible thing to do, even if it loses communication. But if it keeps communication, and the system sees a drop and a return to the normal pattern from before (see visual), it can counteract a low temp with higher temp, or vice versa.

The visualization of temp basals in Nightscout (another example here) is an excellent improvement over how I previously used to check and see what OpenAPS had been doing. I have a watchface (similar to the above #DIYPS one) that shows me what the loop is doing currently, but when I wake up in the morning, I was mostly using a basic screen like the below to see the positive, negative, and net temp basal rates on an hourly basis and comparing that to my CGM graph to get an understanding of what happened.

Visualizing basal rates in Nightscout is a seemingly minor change, but every time we make a change like this that allows me to contextualize all of my data in one place (on a single glanceable watchface; or on the Nightscout screen); it saves a few seconds or minutes that add up to a lot of time saved every day, week, month, and additional year that I’m dealing with diabetes – a big win.

Building diabetes technology is like building a mountain bike

I’ve had the opportunity to meet some fantastic people through our work with #DIYPS and #OpenAPS, one of whom is Eric Von Hippel, an MIT professor and researcher who work on user innovation. He shared a great example of user innovation that I was previously unfamiliar with, but is an awesome parallel for what we in the diabetes community are doing.

History: bike manufacturers used to make bikes for riding on flat surfaces. Some people wanted to ride their bikes down mountains, but existing bikes weren’t too comfortable (they didn’t have spring-based seats – ouch!). So, bikers started customizing and modifying the bikes they had. Eventually, bike manufacturers saw the demand and started building mountain bikes with the same features that the original mountain bikers had used. (And if you don’t like my paraphrased version of this story, Wikipedia is always your friend!)

The parallels:

We in the diabetes community have seen a series of needs that are not being met with our existing, FDA approved medical devices that are out on the market. From not-loud-enough alarms to not enabling us to track critical information like temporary basal rate history on the pump itself, these are the needs that drove me (and Scott) to first build #DIYPS and then to close the loop. At the same time, the need for remote data access is what drove John Costik and then the other Nightscout founders and developers to build an amazing, community-based open source tool to enable real-time remote data sharing.

Are there commercial products coming to market or are in the market that meet some of these needs now? Sure. But remember, I’ve had diabetes since 2002. In 2013, when Scott and I first started working to solve my need for louder alarms, there was NO commercial solution available for either remote data access or alarm customization. Thus the need for #DIYPS, which we built in 2013, and Nightscout, which blossomed in early 2014. And even though tools like Dexcom SHARE and MiniMed Connect have come to market (and in some cases, more quickly with help from the community communicating to the FDA about the critical importance of these tools), they came in 2015, which is a long time to wait for new tools when you’re dealing with diabetes 24/7/365. And when we managed to close the loop, again with help from the amazing #wearenotwaiting community, in December of 2014? Well, it’s now nearing the end of a year (and with amazing continued results from #OpenAPS not just for me, but for 13 additional people and potentially more to come soon), and we are AT LEAST a year and a half, if not more, away from any commercial device to reach the market. Not to mention: I’m not sure that the first generation of closed loops commercially available will be good enough for me.

The commercial entities are getting there. And, I always want to give them credit – I have a closed loop, but I can’t have one without a solidly working insulin pump and an excellent CGM system. They are, for the most part (with the exception of some missing features), making good, solid safe products for me to use.

The manufacturers are also starting to be open to more conversations. Not just “listening”, which they’ve sort-of/maybe done in drips over the past, but actual two-way conversations where we can share the needs that we know of in the community, and discuss what can be incorporated into their commercial product pipeline more quickly. This is progress starting to be made, and I’m excited to see more of it. It seems like there is a refreshed mindset and energy in the industry, as well as an understanding that we all care deeply about safety and that we’re all in this together to make life with diabetes less of a burden – like riding downhill on a mountain bike rather than a road bike.

“Should I build an artificial pancreas?” (It’s a personal question)

Given that many (7 almost 8!) of us have closed the loop with OpenAPS, and sometimes show pictures of great overnights like the below, and given the fact that diabetes is a complicated, annoying, unfair disease, there is a lot of interest in closing the loop. Scott and I definitely get that, which is why we started the #OpenAPS movement.

I have been asked more and more lately, “Are you going to make this available to less tech-savvy people?” and “Should I build one?”.

The answer to the first question is emotionally hard, because a DIY build of a medical device that auto-adjusts insulin will always involve some technical knowledge – or at the very least, a growth mindset and willing to learn many new things to build a technical knowledge in order to proceed through the murky process of building a not-100%-documented artificial pancreas. You don’t have to be a programmer or an engineer; but you do have to have time and energy to spend learning as well as doing. I say this every day: the DIY part is important.

(And, I know people always want to hear “yes! It’ll be out on X date, and just as easy as installing Nightscout.” But it’s not as easy as installing something like Nightscout and never will be.)

That leads into the second question as an explanation of why it’s not as easy as we would wish:

Even if you have a very technical background, you’ll still spend time learning new languages, new pieces of software, and building pieces of your own. Things will break, things will need to be improved, and you need to have the knowledge of what’s going on and understand the logic of what you’re trying to achieve at each stage in order to be able to troubleshoot both the code part of things and the diabetes part of things.

It is hard. And it is a lot of work.

What you don’t see when someone says they’ve (DIY) closed the loop:

For every “I had such a great night” picture someone posts, that probably represents at least (10?+) hours of working on building or troubleshooting their system. Scott and I have each spent hundreds of hours working with my system, from trouble shooting, to building in new features, to reaffirming that things are all working as planned, etc. That figure should be a bit lower for new people as a result of our efforts, but it will never be as easy as just plugging something in, giving it your weight, and letting it take over. The system only does what you program it to do.

I often say this is “not a set-and-forget” system. And this is also true in the wearability of it. Right now, I use a Raspberry Pi and Carelink USB stick to communicate with my pump. They’re great, but the separate power source I also have to keep charged, plus keeping the USB in range of my pump, plus making sure it’s all working, can be a headache sometimes. (Which is why I’m so glad we made an offline mode, to reduce one of the biggest headaches of using the system.) When I’m on the go during the day, sometimes I don’t take it with me, or I choose to stop and un-power it and resume it when I get home. At this point, I wouldn’t be surprised if most people use it for nighttime use only (at least for the most part). But even with nighttime use only, there’s still constant changing of the code (in some cases daily), tweaking, altering, fixing, breaking, and un-breaking various parts.

Did I mention it was a lot of work?

And does a closed loop prevent all lows and highs? No.

It’s important to realize this is not a cure. I work really hard to do eating soon mode before meals to prevent spikes from the amount of carbs I choose to eat. I still have to test my blood sugar and calibrate my CGMs multiple times a day. I still have to change out my pump site every 2-3 days, and deal with the normal hassles of wonky pump sites, etc. I still have some highs – although the loop helps me handle them and I spend less time above range. And I still have some lows – although usually they’re from human error related to bolusing, the loop helps prevent them from always being a true low and/or blunting the drop so I don’t require as much correction. But diabetes is still a good amount of work, even with a closed loop.

Is it worth it to self-build an artificial pancreas?

This is a personal question. It’s a lot of work, with risk involved.

For me, I have decided and continue to decide that it’s worth it.

But only you can decide if the work and the risk are worth the potential rewards for you.

Does the FDA care more about safety than people with diabetes do?

Today my inbox was suddenly flooded with links to a video with some commentary about artificial pancreas technology at a conference by a representative of the U.S. FDA. The implication many people are getting after watching the video clip is that this FDA representative is implying that people are being unsafe by building their own artificial pancreas. He mentions it is consumer prerogative to build an artificial pancreas – which is correct. The implication of his analogy is that changing your car and killing yourself is similar to a DIY artificial pancreas effort.

The scary takeaway from the video, in my opinion, as well as other public comments in the past, is the implication that the FDA cares more about the potential harms of taking action than the almost certain harms of inaction. And it’s increasingly frustrating that the FDA appears to imply publicly that those of us in the #wearenotwaiting community are doing things unsafely as a result of taking action.

Safety is what drives the #wearenotwaiting movement. In my case, I refuse to sleep another night with the fear that I won’t wake up in the morning because there’s not an FDA-approved system on the market that will wake me up if my life is in danger, let alone a system that can take action and change the situation to be more safe. So I built my own (#DIYPS), because the current FDA-approved CGM devices were not (and still are not) loud enough to wake me up at night, putting me at risk of dying in my sleep. And yes, it ultimately turned into an artificial pancreas – with the same goal of ensuring I wake up every morning, safely (alive). That is my prerogative for sure.

But I fail to see why the FDA, which collectively has no particular knowledge of these systems (especially as they have no jurisdiction, acknowledged on all fronts, over what I do myself – it’s my prerogative), is making public statements implying that these types of systems are categorically unsafe.

As a matter of fact, every DIY system I’ve seen is safer than the FDA-approved standard of care available for people with diabetes. The thousands of people using Nightscout, which is currently a DIY remote view-only monitoring system? Provides more safety and security for people with diabetes, not to mention it is helping achieve better outcomes for people with diabetes than they were able to achieve before with the standard of diabetes care as it exists today. (This was originally for the most part because of restricted access to data, although while that has improved there’s still interoperability issues getting access to real-time data in the same place from the 3+ average devices a person with diabetes uses…unless they have Nightscout or another DIY tool running.) The dozens of people working on their DIY version of an artificial pancreas system (many of whom are collaborating and sharing data in the #OpenAPS community)? These systems are safer than the standard of care, which is to let an insulin pump continue to overdose you if you are dangerously low while you sleep.

(You can see some of my personal data from #DIYPS, before we closed the loop, here and more about outcomes after we closed the loop and had #OpenAPS here. My closed loop artificial pancreas system continues to work excellently nine plus months in, and you can continue to watch my outcomes as I post them to Twitter regularly using the #DIYPS and #OpenAPS hashtags. I’ve also shared the other powerful lessons that DIY tech has helped me learn about diabetes care that helps all people with diabetes, regardless of technology.)

Are there risks to DIY efforts? Yes. But there’s risks to living with diabetes regardless. And as a person with diabetes, I am well aware of the risks that I choose to take. Diabetes is a disease in which you carry around large amounts of a lethal drug in your pocket that you are supposed to inject daily in order to save your life. As a person with diabetes, we are nothing but aware of the multitude of risks of living with this chronic disease 24/7/365.

In fact, even without a DIY artificial pancreas system, I am at risk every day simply from using my FDA-approved insulin pump that does not accurately track how much insulin I am given. (Read more here about how most insulin pumps on the market calculate IOB only from boluses, and often do not provide a record let alone incorporate any temporary adjustments to your basal rates and do not in any case track the impact of suspending your pump completely.)

And as someone who has founded the #OpenAPS movement, with the goal of an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available to more quickly improve and save as many lives as possible and reduce the burden of type 1 diabetes…..we approach it with safety first in mind, and is a big part of why the DIY part is critical and is a part of our number one priority of safety.

Not everyone will choose to go the DIY route. In fact, most people do not and I am told all the time “Oh, I would never do that.” And that’s fine! Everyone can choose what they want for themselves.

But technology has made it increasingly feasible for those of us who want to improve our own safety to do so, because the industry and the FDA are not moving quickly enough to meet our needs.

That, indeed, is our prerogative – to increase our own safety.

Context – give me my data (on my device)

Today I saw that Medtronic announced a partnership with IBM. You can read about it on Twitter, where I first saw it, or elsewhere online. There’s lots of news articles and PR about it, too, which I haven’t read yet in great detail.

My initial reaction:

Additional context:

When I reduce my insulin (either by “suspending” the pump’s activity altogether, or by reducing my basal rate with a “temp” or temporary basal rate), there’s no record of it visible on my insulin pump.

None, at all.

Suspended for 15 minutes while I’m in the shower? No record of it if I accidentally resume insulin activity before checking to see when I suspended it.

Same for if I go running and activate a reduce basal rate (again, a “temp”) of 0.3u/hour instead of my usual 1.3/hour. That’s 1u less of insulin than I normally get. If I cancel it, or if that hour ends without me noticing it?

No record at all.

Which means if my blood glucose skyrockets an hour later, it will take me much longer to catch up with insulin if I don’t realize that I’m -1u (negative one unit) below what my body is used to.

Suspending your pump for 3 hours to go swimming? Same deal. Your body has less insulin than it’s used to, but you have to manually and mentally keep track of it.

The reverse is true as well – if you are sick and your body is more resistant to insulin than usual, and you use a higher basal rate than your usual as a way to additionally correct for a high BG?

No record of the additional insulin you’re putting into your body above your baseline basal profile.

THIS IS DANGEROUS.

And yet this is the FDA approved medical device that everyone is happy that I’m using? Even with critical flaws that endanger my life every day?

And the world has a problem with patients “hacking” or otherwise finding ways to access this critical data since we can’t get it from our approved devices?

This is backwards.

Medtronic and other pump brands track how much “insulin on board” (aka IOB) you have…but this number is wrong, because it doesn’t calculate the lack of insulin if you adjust your basal rates (examples above).

This is something I’ve been doing with #DIYPS to compensate for the inaccessibility of data from my FDA-approved medical device. Instead, I have to calculate for myself the “net” IOB number that takes into account any ‘negative’ corrections from suspending or negative or positive temp basal rates. These make a huge difference in my diabetes care.

We’ve learned from talking to people about #DIYPS for a year and a half that many people don’t use temporary basal rates, even though they’re very effective to ward off future lows and highs.

Why?

For one thing, it’s because there’s no record in their pumps. It’s too hard, and too much guesswork when there’s no record.

I don’t understand why the pump companies seem to ignore this. (If someone has a pump that tracks net IOB and/or shows a history of temporary basal rates and suspension, let me know. I’m familiar mainly with Medtronic’s pumps.)

This is not ok.

So while I think there’s a lot of potential for Medtronic to do more things with diabetes data (like this or this) through this partnership with IBM’s Watson? In the meantime, I’d like them to start with something much more simple – and with guaranteed impact.

Give me, the patient, my data that I need – directly on my medical device – so I can safely take care of myself and better manage my diabetes.

(Note – I realize FDA approval cycles on pumps take a long time, and this is unlikely to get fixed in current pumps. But future pumps? This should be fixed across the industry. And in the meantime? Companies can and should make it much easier to access data from the pumps via their approved uploader methods and make it easier to read the data. Right now, it’s not even easy to see the data off your pump. Let’s change this.)

Why the DIY part of OpenAPS is important

I had the chance to talk about DIYPS and OpenAPS during a demo session in DC last week. (Thank you to Gary from Quantified Self and Marty from the National Academy of Sciences for making this possible!)

I walked away with several insights:

  1. Many people don’t know about diabetes; fewer have a realization of current diabetes tech. In several cases as I was describing the closed loop artificial pancreas, people stopped me and were wowed – but not by the closed loop. They were impressed by the CGM.
  2. Others think that this type of technology is already out on the market.

So, I believe we have a long way to go in communicating and advocating for this type of technology. We know it’s behind where it should be – and we want it to catch up. That’s a big part of the OpenAPS goals to help the FDA, device companies, and everyone involved move a little faster than they might otherwise, because #WeAreNotWaiting.

But here’s the other question I was often asked: “How many people have you given this to?”

I frequently embarked on an explanation of how we can’t “give” away #DIYPS or the OpenAPS implementation – in fact, we can’t and won’t give away the code, either. Some of that is because the FDA says no – and some of it is common sense and principles that both Scott and I hold.

Here’s why I think it is so important to keep the DIY in DIYPS and each OpenAPS implementation that is in progress:

  • You need to have a deep understanding of the system before even considering using it on yourself. You need to know what it’s trying to do in all situations, including the fringe cases (the “this is unlikely to happen but if it does…”), so that you know when it’s working – and when it’s not – whether it’s 3pm in the afternoon at work, or 3am and you wake up and find something is not right and the system is not working.
  • You need to go step by step and test and ensure at each stage that it is working as expected – both in a “this is what it should be doing” and “it is giving out the correct amount of insulin”. Remember, insulin is a lethal drug. It’s also a lifesaving drug. It’s important to remember both of these things and balance the risks accordingly.

From the conversations I’ve had with people interested in learning more or getting a DIYPS-type system for themselves, they fall into two categories:

  1. “How can I buy it from you?”
  2. “What do I need to do to make one?”

Given my above reasoning, the second question is my favorite. The first one scares me, if someone does not then switch to the #2 question. Many people do go from #1 to #2, which is great.

DIYPS, for me, and OpenAPS implementations, for others, are works in progress. They’re not perfect. They’re better than what’s out there (like sleeping through alarms when you’re low at night), but they also have big risks. And it’s important to know, and respect these risks, and understand the limitations of the system, before being able to take advantage of this type of system – and to build the system with appropriate safeguards. (This is one of the reason we have OpenAPS, for example, designed to accept multiple failure points – like walking out of range, loss of connectivity, etc.)

The ability to buy a “black box” type system where you don’t know exactly how it works, but you trust that it works? That will be coming from the major device manufacturers in several years – hopefully sooner rather than later, and that’s something that OpenAPS will hopefully help make happen more quickly.

So to answer the #2 question, what do you need to make a DIYPS or OpenAPS of your own?

I’ll answer the technical aspects of this question in another post, but the first thing I always say is: “The willingness to build and test and test and test some more before ever considering using it on yourself.”