As many of you know, we held our Fall 2015 DiabetesMine D-Data Exchange event on Nov. 19. One huge highlight of this gathering of diabetes technologists was an amazing talk by Chris Hannemann, a U.C. Berkeley alumni and mechanical engineer who in August became the 5th person on the planet to go live using what is known as OpenAPS, a fully functional homemade artificial pancreas.
At this point, 15 people and counting are now using this open source closed-loop system, which is made up of a jumble of products cobbled together: a Medtronic insulin pump, Dexcom CGM receiver, Raspberry Pi device for running Linux OS, a CareLink USB stick to enable communication to the pump, and a battery pack. Whoa…
Here’s the inside story from Chris himself on how he got involved with this revolution in diabetes care:
For the past hundred days or so, I have been using a single-hormone hybrid closed-loop system—better known as an artificial pancreas. I’m not in a clinical trial, nor do I have advanced access to some future product, but rather I’m a member of a DIY (do-it-yourself) community that has figured out how to do it using standard medical devices. Let’s back up and see how I got here.
I was diagnosed with type 1 diabetes at the age of 8. Two years later, my father was diagnosed with type 2. A year after that, my sister was diagnosed with type 1. We had no family history of diabetes and no friends or relatives with the disease at the time, so it was a bit of a shock to say the least. All things considered, we took it in stride, and I’ve since thanked my parents for the approach they took to management: guiding without controlling, monitoring without hovering. That isn’t to say my early years were without incident, of course. I had a handful of scary hypoglycemic events, and my A1c values were all over the place during puberty. Still, I was a happy kid, and the fact that I had to deal with diabetes was more of a nuisance than a roadblock.
High school and college followed suit for the most part, but things changed part way through grad school. A particularly violent and jarring overnight hypoglycemic incident caused me to reevaluate my treatment, and so, at the age of 23—15 years after diagnosis—I turned to insulin pumping for the first time. My control improved greatly, and I felt like I was back on track.
Simultaneously, I went into data collection mode, and started making adjustments and sharing spreadsheets with my endocrinologist weekly. I soon found myself in a sea of data that I thought should be accessible and easily combined, but was instead met with cumbersome software interfaces and no way to pull outside data into the mix. I harnessed my frustration, teamed up with a friend at Google, and submitted a proposal to U.C. Berkeley’s Big Ideas competition. The proposal looks simple and even archaic now, but back then it was a pipe dream—a way to automate data collection and integrate different data sources to get a more complete picture of my disease. Our work was awarded one of the prizes, and I went in search of some partners.
Unfortunately, the DIY diabetes community that exists today—the 15,000-strong CGM in the Cloud Facebook group, the plentiful repositories populating GitHub—was still years off. Back then, it was just a few individuals with Visual Basic macros running in Excel spreadsheets buried deep in online forums, and I soon hit a wall in terms of interested parties with relevant skills. I got my first job out of grad school and the project went mostly dormant. My enthusiasm for data collection waned, and I regressed to a familiar norm: pumping, periodic finger sticks, no real data evaluation other than A1c and average meter values.
Over the years, I watched my A1c creep back up, and this past January, it got to the point where I knew something needed to change. I hadn’t had any severe hypoglycemic incidents since switching to the pump, but my long-term outlook wasn’t positive. My endocrinologist encouraged me to look into a continuous glucose monitoring (CGM) system, but I was resistant. Years prior, I had tried one of Medtronic’s early CGMs, but a combination of poor design, terrible accuracy, and painful insertion quickly overpowered any motivation I had and rendered the system useless in my eyes. I didn’t really want to have to carry a separate receiver either, but in the end, I finally bit the bullet and got Dexcom’s standalone unit.
It. Was. Awesome.
Oftentimes it may feel like the DIY community has an “us against them” mentality, where the device manufacturers are somehow the enemy. In reality, we love the device manufacturers. The insulin pump and CGM I use are amazing pieces of equipment. The Dexcom G4 in particular was absolutely life-changing. For all my griping about having to do calibrations, not having the transmitter backfill data when I’m out of range, and not having access to raw data, this little enzyme-laden wire sitting under my skin is far and away the best piece of technology I own.
Now, however, I had a new problem: a lot of data and no clear way to use it.
In my search for what to do with my data, I stumbled upon Tidepool and, excited to see their how similar their product pipeline was to what I was looking for, gave a very modest donation and a note of encouragement. Shortly thereafter, Tidepool’s CEO Howard Look emailed me a personal thanks and, referencing my seven-year-old proposal from Berkeley, asked if I’d be interested in beta testing some of their products. I of course said yes, and was soon gazing upon my pump and CGM data beautifully displayed in unison on the first polished interface for diabetes data I can remember seeing.
That led me down the rabbit hole. I found so many people doing so many different things, and I wanted to try them all. I wanted to see my glucose live on my watch, in my laptop’s menu bar, on my phone—not because I wanted or needed all of these, but because for the first time I had options and I wanted to explore which worked best for me. I set up a Nightscout deployment, freeing up my CGM data for use in a variety of other tools. I started playing around with metabolic simulators like GlucoDyn from Perceptus. I was even excited to see apps that didn’t necessarily fit me in their target demographic (OneDrop, for example) but had the vision to make a product that enabled people with diabetes to do more with their data.
Eventually, this led me to DIYPS.org and, subsequently, OpenAPS.org. It also led me to some of the many contributors who would enable my success with OpenAPS: Ben West, the architect of Decoding CareLink and the OpenAPS tool set, who spent years figuring out how to talk to these devices; Dana Lewis and Scott Leibrand, who were the first to combine the tools into a functioning system and have since put forth great effort to grow and support the community; and Nate Racklyeft, who built an exceptional system to extend the tools and invested many patient hours teaching me how to contribute.
The funny thing is, much like me, none of these individuals started out trying to build an artificial pancreas. Ben was trying to audit his devices to restore fidelity and trustworthiness to the pieces of technology he depended on daily for survival. Dana and Scott were simply trying to make her CGM alarms louder so that she wouldn’t sleep through them at night. Nate was building an app to automatically calibrate pump basal schedules based on historical data. I was exploring different data visualization and analysis methods for my newfound treasure trove of data. There are many others, of course, each with their own path that eventually brought them to OpenAPS.
With their help, on August 19, 2015, I became the fifth individual to “close the loop” with the OpenAPS toolset; as of December 4, 2015, there are at least 17 running similar systems.
OpenAPS stands for Open Artificial Pancreas System. To be clear, OpenAPS is not itself an artificial pancreas. Rather, it is an open-source toolset for communicating with diabetes devices. This enables and empowers users to both acquire more complete data in real time from their insulin pump and CGM as well as create their own artificial pancreas. We do not actually modify the pump or CGM in any way, but instead use the communication protocols that are already built into the devices. It is as if the devices spoke a different language and we just figured out how to translate it.
OpenAPS is not a commercial venture and there is little material benefit to the contributors outside of using the system itself. The core code is available for anyone to download, use, inspect, and propose changes to be reviewed by the community. There is substantial documentation published and maintained by the community so that others may get involved in the project. In fact, one of the first things that new users are encouraged to do is edit the documentation. This serves several purposes: it keeps the documentation up-to-date (after all, new users are the ones the documentation is trying to assist), it gets new users accustomed to contributing and using git and GitHub, and it allows them to pay it forward by helping the next set of users as well. After all, none of this would be possible if the first few contributors simply built their systems and then left.
A closed-loop system based on OpenAPS is actually pretty simple. Every five minutes, a small computer (in most cases, a Raspberry Pi) acquires the last few hours of CGM readings and pump history—boluses, basal rates, suspends, carb inputs, and so on. It uses this data along with your settings—insulin sensitivity, carb ratio, duration of insulin action, etc.—to predict what your glucose will be over the next few hours. If it predicts that you will be out of range, it sets a 30-minute temporary basal rate on the pump to help correct your glucose, either up or down. That’s it. In all honesty, it really isn’t that complex, and that’s part of the beauty. It is essentially what people with diabetes are doing anyway. From an algorithmic standpoint, most of the gains don’t require anything more than the math you do already. The main benefit comes from the system always paying attention and its ability to do the calculations quickly and accurately.
Of course, there are a number of things going on in the background, primarily to ensure the fidelity of the data and the safety of the user. Safety comes in many forms, and there are some extra precautions involved due to the DIY nature of the system. Some of the steps we take include: training users to build and test their system in incremental stages (first modeling only, then open loop with predictions, then finally implementing automated control); implementing redundant limits wherever possible (such as setting maximum basal rates in the code and on the pump itself); never relying on connectivity; defaulting to normal pump operation quickly in the case of an issue; and keeping the code and documentation public. This last one is important as it allows us to be vigilant as a community—the more eyes on the code, the faster you can find issues.
My system is not perfect, and there are several limitations. Like all insulin-only artificial pancreas systems, it can only raise glucose levels by reducing current insulin delivery, and is hence subject to the speed of insulin action. The predictions it makes are subject to the quality of the inputs it receives, and we all know that the untracked inconveniences of life—stress, sickness, that soda you thought was diet—can be significant. It is also reasonably bulky and has limited range, but still, I have found the benefits greatly outweigh these inconveniences.
So how well does my OpenAPS implementation work? I was on the CGM for nearly six months before closing the loop, so I have a decent baseline data set for comparison:
Pre-OpenAPS (Pump + CGM, open loop)
Days = 179
Time in Target (80 – 180 mg/dL) = 70%
Average Blood Glucose = 144 mg/dL
OpenAPS (closed loop)
Days = 107
Time in Target (80 – 180 mg/dL) = 83%
Average Blood Glucose = 129 mg/dL
The decrease in average glucose is modest, but is still equivalent to a 0.5% decrease in A1c. The bigger change for me, however, is the increased time in target range. That bump from 70% to 83% is three additional hours each and every day where I was out of range that I am now in range. Put another way, I’ve nearly halved the time I spend out of range. Unsurprisingly, the system has the greatest impact overnight, when there are the fewest inputs (unless you’re a sleep-eater) and you typically wouldn’t be awake to do adjustments. I typically wake up now between 100 and 120 mg/dL, which means waking up ready for the world instead of ready for a correction bolus or a glass of orange juice.
It still requires input and attention, but because it automates a good portion of my decisions, it allows me to focus on the issues that aren’t algorithmic in nature. For example, since my highs are now significantly lower and less frequent than before, I can usually attribute the outliers to an actual issue—a kinked infusion set, for example—rather than simply poor carb counting or lax bolusing. As I result, I don’t get treatment fatigue and can identify and address issues more effectively.
I’ve purposefully used the phrase “an” or “my” OpenAPS implementation instead of “the” OpenAPS implementation because there is no single canonical incarnation of this system. While an individual could build something akin to a default version and get much of the benefit, the real power of the project is how it enables and encourages diversity. This goes for the specifics of the algorithms, yes, but also to how the data is visualized in real time. With fewer than 20 users, visualizations and notifications have been made for at least a dozen different platforms: desktop, mobile, wearable, auxiliary E Ink displays, you name it!
Not all of these platforms will continue to develop; there will be some coalescence around the ones that people prefer, and development will shift in those directions. But it’s a great way to do development—try to build something that you want, and if others like it, others will help it grow. It democratizes the process, and since no one is prevented from developing their own alternative, innovation is rampant. Contrast this to a monolithic, silo approach where the only way to see what a device is doing is to use the app developed by the device manufacturer.
I like to joke that we’ll have OpenAPS visualizations running on Game Boys and Tamagotchis soon (no one is actively working on this, to the best of my knowledge), but this actually gets at a nuanced point. Imagine if you did have a child who spent a good bit of time playing with a particular toy, and that you could somehow add a bit of simple, glanceable information. It probably doesn’t make sense for a medical device company to spend the resources to make that happen, but for your particular instance, for the disease that you and your family own, that could make all the difference.
OpenAPS is not for everyone, and we recognize that. There are currently several commercial closed-loop insulin-only products in development by old and new companies in the diabetes device space. These include the Medtronic MiniMed 640G (already available outside the United States) and 670G as well as devices from Bigfoot Biomedical and TypeZero Technologies. Further down the line, the dual hormone (insulin and glucagon) iLet from Boston University’s Bionic Pancreas Team promises an even greater level of glucose control. The claim of OpenAPS isn’t that it is a better device than any of these, but that it is something we can do now and an example of why patients need access to their device’s data and controls.
So if commercial devices that will be smaller, lighter, and more robust are set to available in the next year or two, why go to all this trouble?
Personally, I’m doing this because I want to control my treatment, and for a while now, it’s seemed like devices have started becoming the treatment itself. The devices—their menus, their alerts, their algorithms, their visualizations— profoundly impact my attempts to manage this disease, yet I have no control over their design and implementation. As the technology gets more and more complex, we cede more and more control to the decisions of others. The solution isn’t to keep the devices simple, but to keep them open.
Often, these design decisions are justified under the blanket of safety and security. Security is paramount, but it is also not mutually exclusive with patient access. Safety and security, while certainly related, are not synonyms. You can have an extremely secure system that is, by virtue of how it was made secure, quite unsafe. In fact, a system that enables and encourages the patient to audit its inner workings is significantly safer than one that doesn’t.
The industry is changing, and we’ve already seen positive statements on how the next generation of devices will treat our data. Sara Krugman of Tidepool stated it well in her four-part series (parts 1, 2, 3, 4) discussing the UI/UX design of the iLet (formerly Bionic Pancreas): “The interaction with the iLet is not about passing off everything. It is about collaborating in the management of blood sugar levels.” This is an excellent mindset to have going into the construction of a tool. The key is to take that collaboration one step further and provide access and a full set of instructions—an API—so that we can continue to treat ourselves. The alternative—shutting down access to the ecosystem—is a crass and ultimately futile way for a manufacturer to stay relevant.
The point is, when patients have the data and the tools, we can do amazing things with them. I think with OpenAPS we’ve demonstrated just how ingenious the DIY community can be in developing safe, effective, personalized treatments when given access to the right toolset. It is an amazing thing that we’ve done, but more than that, it’s an indicator of all the things that we can do.
How awesome is it to be helping create the future of diabetes care, Chris?! Thank you so much for sharing your story and perspective!