What is #DIYPS (Do-It-Yourself Pancreas System)?

#DIYPS (the Do-It-Yourself Pancreas System) was created by Dana Lewis and Scott Leibrand in the fall of 2013.

Curious about building a closed loop for yourself? Head to OpenAPS.org!

#DIYPS was originally developed with the goal of solving a well-known problem with an existing FDA-approved medical device. We originally set out to figure out a way to augment continuous glucose monitor (CGM) alerts, which aren’t loud enough to wake heavy sleepers, and to alert a loved one if the patient is not responding.

We were able to solve those problems and include additional features such as:

  •  Real-time processing of blood glucose (BG), insulin on board, and carbohydrate decay
  •  Customizable alerts based on CGM data and trends
  •  Real-time predictive alerts for future high or low BG states (hours in advance)
  •  Continually updated recommendations for required insulin or carbs
  • ..and as of December 2014, we ‘closed the loop’ and have #DIYPS running as a closed loop artificial pancreas.
  • (And, as of February 2015, we also launched #OpenAPS, an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available. For more details, check out OpenAPS.org)

You can read this post for more details about how the #DIYPS system works.

While #DIYPS was invented for purposes of better using a continuous glucose monitor (CGM) and initially tailored for use with an insulin pump, what we discovered is that the concepts behind #DIYPS can actually be used with many types of diabetes technology. It can be utilized by those with:

  • CGM and insulin pump
  • CGM and multiple daily injections (MDI) of insulin
  • no CGM (fingerstick testing with BG meter) and insulin pump
  • no CGM (fingerstick testing with BG meter) and multiple daily injections (MDI) of insulin

Here are some frequently asked questions about #DIYPS:

  1. Q:I love it. How can I get it?A: #DIYPS is n=1, and because it is making recommendations based on CGM data, we previously have said that we can not publicly post the code to enable someone else to utilize #DIYPS as-is. There’s two things to know. 1) To get some of the same benefits from #DIYPS as an “open loop” system, with alerts and BG visualizations, you can get Nightscout, which includes all of the publicly-available components of #DIYPS, including the ability to upload Dexcom CGM data, view it on any web browser and on a Pebble watch, and get basic alarms for high and low BG – and depending on which features you enable, you can also get predictive alarms. Some of the other core #DIYPS features (“eating-soon mode“, and sensitivity/resistance/activity modes) are now available in Nightscout. 2) If you are interested in your own closed loop system, check out OpenAPS.org and review the available OpenAPS documentation on Github to help you determine if you have the necessary equipment and help you determine whether you want to do the work to build your own implementation.
  2. Q: “Does #DIYPS really work?”A: Yes! For N=1, using the “open loop” style system with predictive alerts and notifications, we’ve seen some great results. Click here to read a post about the results from #DIYPS after the first 100 days – it’s comparable to the bionic pancreas trial results. Or, click here to read our results after using #DIYPS for a full year. We should probably update this to talk about the second year of using #DIYPS, but the results from the first year have been sustained (yay!) and also augmented by the fact that we closed the loop and have the system auto-adjusting basal rates while I sleep.
  3. Q: “Why do you think #DIYPS works?”A: There could be some correlation with increased timed/energy spent thinking about diabetes compared to normal. (We’d love to do some small scale trials comparing people who use CGMs with easy access to time-in-range metrics and/or eAG data, to compare this effect). And, #DIYPS has also taught us some key lessons related to pre-bolusing for meals and the importance of having insulin activity in the body before a meal begins. You should read 1) this post that talks about our lessons learned from #DIYPS; 2) this post that gives a great example of how someone can eat 120 grams of carbohydrates of gluten-free pizza with minimal impact to blood glucose levels with the help of #DIYPS; 3) this post that will enable you to find out your own carbohydrate absorption rate that you can start using to help you decide when and how you bolus/inject insulin to handle large meals or 4) this post talking about how you can manually enact “eating-soon mode”. And of course, the key reason #DIYPS works (in open loop mode) is because it reduces the cognitive load for a person with diabetes by constantly providing push notifications and real time alerts and predictions about what actions a person with diabetes might need to consider taking. (Read more detail from this post about the background of the system.)
  4. Q:Awesome!  What’s next?A: If you haven’t read about #OpenAPS, we encourage you to check it out at OpenAPS.org. This is where we have taken the inspiration and lessons learned from using #DIYPS in manual mode (i.e. before we closed the loop), and from our first version of a closed loop and are paying it forward with a community of collaborators to make it possible for other people to close the loop! Some new features we wanted for #DIYPS that will likely still happen, but integrated with Nightscout and/or #OpenAPS include:
    • calculation of insulin activity and carb absorption curves (and from there, ISF & IC ratios, etc.) from historical data
    • better-calibrated BG predictions using those calculated absorption curves (with appropriate error bars representing predictive uncertainty)
    • recommendations for when to change basal rates, based on observed vs. predicted BG outcomes
    • integration with activity tracking and calendar data
    • closing the loop – done as of December 2014! :) and made possible for more than (n=1) with #OpenAPS as of February 2015

    We also are collaborating with medical technology and device companies, the FDA, and other projects and organizations like Tidepool, to make sure that the ideas, insights, and features inspired by our original work on #DIYPS get integrated as widely as possible. Stay tuned (follow the #DIYPS hashtagDana Lewis & Scott Leibrand on Twitter, and keep an eye on this blog) for more details about what we’re up to.

  5. Q: “I love it. What can I do to help the #DIYPS project? (or #openAPS)”A: #DIYPS is still a Dana-specific thing, but #OpenAPS is open source and a great place to contribute. First and foremost, if you have any ability to code (or a desire to learn), we need contributors to both the Nightscout project as well as #OpenAPS. There are many things to work on, so we need as many volunteers, with as many different types of skills, as we can get.  For those who are less technical, the CGM in the Cloud Facebook group is a great place to start. For those who are technical and/or want to close the loop for themselves, check out OpenAPS.org, join the openaps-dev google group, and hop on the #intend-to-bolus channel on Gitter. If you want to contact us directly, you can reach out to us on Twitter (@DanaMLewis @ScottLeibrand) or email us (dana@openAPS.org and scott@openAPS.org). We’d also love to know if you’re working on a similar project or if you’ve heard of something else that you think we should look into for a potential #OpenAPS feature or collaboration.

Dana Lewis & Scott Leibrand

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.

OpenAPS poster cited in Nature!

I was thrilled to read a commentary by John Wilbanks and Eric Topol, out in Nature today, titled “Stop the privatization of health data“. (Click here to read a PDF version of the article.)

Tucked on the bottom of the second page of the (PDF version of the) article:

“For instance, in 2014, a woman with type 1 diabetes wired together a tiny processor, an insulin pump and a continuous glucose monitor to automate the regulation of her blood sugar levels. For a small community of patients, the collective use of such ‘home-made’ systems has resulted in improvements that are well ahead of those provided by devices and interventions emerging from conventional markets.1”

(The citation is to the poster that we presented on behalf of the #OpenAPS community at the American Diabetes Association Scientific Sessions meeting last month, with self-reported outcomes from 18 of the first 40 users and builders of DIY artificial pancreas systems)

OpenAPS (n=1)*98 as of July 19, 2016It’s worth noting that there are now (n=1)*98 users of #OpenAPS, so this “small community” is growing fast: doubling approximately every three months.

Wilbanks and Topol highlight some critical truths in their commentary, and call out another (frustrating) diabetes example to illustrate:

“Although patients can monitor their glucose levels at any instant, their aggregate records are not made accessible to them. And there is no mechanism by which patients or researchers outside the company can gain access to Medtronic’s tens of thousands of measurements.”

I’ve written about this specific example before, in fact: new ‘partnerships’ mean my personal health data is likely shared with IBM for Watson’s usage…but I don’t have access to this data or insights, and am in fact missing critical information and data visualization on my FDA-approved medical device that’s been on the market for years.

The call to action for device manufacturers, regulators, and the medical industry is simple: Give me, the patient, my data that I need so I can safely take care of myself and better manage my diabetes.

Wilbanks and Topol emphasize that this won’t happen “…unless each of us takes responsibility for our own health and disease, and for the information that we can generate about ourselves. When it comes to control over our own data, health data must be where we draw the line.”

This needs to happen everywhere, not just in diabetes. Will you join us in drawing the line?

Picture this: How to do “eating soon” mode

How do you prevent or limit meal spikes? It doesn’t take a closed loop artificial pancreas; it takes an understanding of insulin timing and the impact on your body.

I’ve written before about why getting insulin going in your body before meal carbs kick in is so important. You can read that really long post here. And I’ve written a slightly shorter post explaining how to do “eating soon mode” to achieve insulin activity peaking when you eat, without causing lows. But recently, I quickly scratched together an illustration to show the difference in the timing and outcomes between the “eating soon mode” approach compared to a traditional “pre-bolus” approach, and after receiving feedback that these images were helpful, decided to post them here.

(Again, for more context, read this post on how to calculate your eating soon amount; and this post for more of the science behind it and how we discovered this method 2+ (!) years ago. And as always, your diabetes may vary; I’m not a doctor; etc. but this is something that when applied consistently smooths out meal spikes, even when eating high fat or high protein or high carb or any kind of meal.)

What often happens with a pre-bolus of the meal insulin 15 minutes before a meal
What often happens with a pre-bolus of the meal insulin 15 minutes before a meal


The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with "eating soon" mode approach
The type of meal spike (minimal) you can achieve by getting insulin activity going 1 hour before the meal with “eating soon” mode approach.

*Note – the calculation of (TargetBG-80)/ISF is assuming that you have already corrected to your normal target, i.e. 100 or 120.

Let me count the ways that the healthcare system is broken

Alternative title to this blog post:
Choosing our battles.

I am furious: shaking with anger and frustration. Because after 13.5+ years of living with diabetes, the number one frustration continues to be fighting for access to supplies and the tools I need to treat my diabetes.

The latest scenario is this (skip to the end if you don’t want to read the emotional, nitty gritty detail part and want a tl;dr):

I changed jobs last year, and thus I had new insurance. New insurance = new authorization for all the things diabetes wise. For those of you unfamiliar, this is a long list: pump; pump supplies (reservoirs and sites); insulin; CGM receiver; CGM transmitter; CGM sensors, test strips, etc.

The biggest battle this time was for getting approval for my CGM, which I’ve been using for years. But I had to re-prove that the autoimmune disease that I have has not in fact gone away. So I did. But my CGM authorization request was denied, because my blood sugars were “too good”.

Sigh. (So maybe that’s the one “downside” to an artificial pancreas?)

I fought the denial with an appeal. Finally, after many phone calls and hoop jumping, they overturned the decision and granted approval. My CGM receiver, transmitter, and 3 months of sensors were shipped on March 15. Hooray! I figured my problems were solved until I switched insurances again in the future.

But wait, there’s more.

I waited very carefully until the end of June, past the three month mark of when I had got my first batch of sensors, to put in the order for the next 3 months worth of CGM sensors. I placed my order, went on a trip, got back to Seattle, and assumed they were floating their way to me.


I received a phone call today informing me that the supply company was working on the authorization for my CGM sensors..but couldn’t submit it because my doctor’s chart notes were older than 6 months. My response was, “why do you need an authorization? I had one three months ago.”

Turns out, the insurance only authorized me for CGM sensors until April 30. The order shipped as soon as authorization was received was dated March 15, so they knew there was no way I could submit another order for them before June 15.

Anyone else see the problem here? They knew I would have to go through this process AGAIN. It’s not like my non-curable type 1 diabetes was going to go away in the three months, thus my need for CGMs to help me manage said diabetes did not go away, either.

And because my endo appointment is scheduled for July 28, the supply company is unable to put in the order until I go to the appointment and get new chart notes (they have to be <6 months old). So I have to call the endo again and get a soon-as-possible appointment to pay my $15 co-pay to get new chart notes to get a new batch of sensors.

I. Am. So. Frustrated.

The healthcare system is so, so broken. Patients shouldn’t be running in circles, unnecessarily going to the doctor’s office and taking up their time that could be spent helping people who need that face to face time. It’s unnecessary time for the doctor, time I have to take away from work/life, and lots of paperwork and phone calls, and it’s been this way for over a decade.
I am very fortunate, because I’m currently fighting this battle for CGM, not for test strips or insulin. (Although, I’ve done that before, too.) There are people who can’t afford CGM even if they get coverage, and people who are fighting for coverage or are in parts of the world and can’t access insulin. I very much get that and am hyper-aware of my privilege here.

But that’s why I have to choose my battles. My heat of the moment reaction is to want to rattle up the poles of my insurance company and fight to make this not the reality; but the reality is, it’s not just my insurance company. It’s every insurance company. It’s the entire healthcare system right now that’s wrong and in need of balance and fixing. And so Scott and I are trying to choose our battles – and utilize the privilege we have and the resources we have – to make the biggest difference in changing the healthcare system.

So that is what we are doing, with numerous projects related to OpenAPS and the broader #WeAreNotWaiting movement: working with the FDA and other organizations and individuals who want to help make the future of healthcare better.

But in the meantime, I’m also calling my endo to change my appointment and fighting the battle for personally getting my CGM approved and probably paying 100% out of pocket for a box or two of sensors to tide me over.

How to “soak” a new CGM sensor for better first day BGs

Having used a CGM for years (and years and years, and years before that), and having chosen to build a DIY system that provides smart alerts and recommendations based on said CGM data (learn more about my #DIYPS system here) and ultimately using CGM data to build the open source closed loop system that automates insulin delivery (find out more about #OpenAPS here)…I’ve learned a few things about how to get the best data out of my sensors. Currently, I’m using Dexcom, so this applies to the Dexcom sensors.

The biggest thing I do to get better first day results from a continuous glucose monitor (CGM) sensor is to “soak” my sensors. Here’s what I mean by this:

Normally, you’d expect to see a person with one CGM sensor on their body, like this:

Dana Lewis_first day CGM sensor illustrationHowever, 12-24 hours before I expect my sensor to end, I insert my next sensor into my body. To protect the sensor (you don’t want the sensor filament itself to get torn off or lost in your body), I plop an old (“dead” battery) transmitter on it.

If you don’t have an old/dead transmitter, you could try taping over it – the goal is just to protect the sensor filament from ripping.

Dana Lewis_last day CGM sensor soak illustrationThe next day, when my sensor session ends:

  • I take the “live” transmitter off the old sensor, and remove the old sensor from my body. I hit “stop sensor” on my receiver, if it hasn’t already stopped itself.
  • I gently remove the “dead”/old transmitter from ‘new’ sensor.
  • I then stick the “live” transmitter onto the new sensor.
  • I hit “start sensor” on my receiver.

Dana Lewis_last day CGM sensor soak change illustrationThe outcome (for me) has always been significantly improved “first day” BG readings from the sensor. This works great when you can plan ahead and your outfits (don’t judge, sometimes you have important outfits like a wedding dress to plan around) and skin real estate support two sites on your body for 24 hours or so. This doesn’t work if you rip a sensor out by accident, so in those scenarios I go ahead and put a new sensor on, put the ‘live’ transmitter on, and hit ‘start’ to get through the 2 hour calibration period as soon as possible to get back to having live data. (All the while knowing that the first day is going to be more “meh” than it would be otherwise.)

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!

Research studies and usability thoughts

It’s been a busy couple (ok, more than couple) of months since we last blogged here related to developments from #DIYPS and #OpenAPS. (For context, #DIYPS is Dana’s personal system that started as a louder alarms system and evolved into an open loop and then closed loop (background here). #OpenAPS is the open source reference design that enables anyone to build their own DIY closed loop artificial pancreas. See www.OpenAPS.org for more about that specifically.)

We’ve instead spent time spreading the word about OpenAPS in other channels (in the Wall Street Journal; on WNYC’s Only Human podcast; in a keynote at OSCON, and many other places like at the White House), further developing OpenAPS algorithms (incorporating “eating soon mode” and temporary targets in addition to building in auto-sensitivity and meal assist features), working our day jobs, traveling, and more of all of the above.

Some of the biggest improvements we’ve made to OpenAPS recently have been usability improvements. In February, someone kindly did the soldering of an Edison/Rileylink “rig” for me. This was just after I did a livestream Q&A with the TuDiabetes community, saying that I didn’t mind the size of my Raspberry Pi rig. I don’t. It works, it’s an artificial pancreas, the size doesn’t matter.

That being said… Wow! Having a small rig that clips to my pocket does wonders for being able to just run out the door and go to dinner, run an errand, go on an actual run, and more. I could do all those things before, but downsizing the rig makes it even easier, and it’s a fantastic addition to the already awesome experience of having a closed loop for the past 18 months (and >11,000 hours of looping). I’m so thankful for all of the people (Pete on Rileylink, Oscar on mmeowlink, Toby for soldering my first Edison rig for me, and many many others) who have been hard at work enabling more hardware options for OpenAPS, in addition to everyone who’s been contributing to algorithm improvements, assisting with improving the documentation, helping other people navigate the setup process, and more!

That leads me to today. I just finished participating in a month-long usability study focused on OpenAPS users. (One of the cool parts was that several OpenAPS users contributed heavily to the design of the study, too!) We tracked every day (for up to 30 days) any time we interacted with the loop/system, and it was fascinating.

At one point, for a stretch of 3 days, we counted how many times we looked at our BGs. Between my watch, 3 phone apps/ways to view my data, the CGM receivers, Scott’s watch, the iPad by the bed, etc: dozens and dozens of glances. I wasn’t too surprised at how many times I glance/notice my BGs or what the loop is doing, but I bet other people are. Even with a closed loop, I still have diabetes and it still requires me to pay attention to it. I don’t *have* to pay attention as often as I would without a closed loop, and the outcomes are significantly better, but it’s still important to note that the human is still ultimately in control and responsible for keeping an eye on their system.

That’s one of the things I’ve been thinking about lately: the need to set expectations when a loop comes out on the commercial market and is more widely available. A closed loop is a tool, but it’s not a cure. Managing type 1 diabetes will still require a lot of work, even with a polished commercial APS: you’ll still need to deal with BG checks, CGM calibrations, site changes, dealing with sites and sensors that fall out or get ripped out…  And of course there will still be days where you’re sensitive or resistant and BGs are not perfect for whatever reason. In addition, it will take time to transition from the standard of care as we have it today (pump, CGM, but no algorithms and no connected devices) to open and/or closed loops.

This is one of the things among many that we are hoping to help the diabetes community with as a result of the many (80+ as of June 8, 2016!) users with #OpenAPS. We have learned a lot about trusting a closed loop system, about what it takes to transition, how to deal if the system you trust breaks, and how to use more data than you’re used to getting in order to improve diabetes care.

As a step to helping the healthcare provider community start thinking about some of these things, the #OpenAPS community submitted a poster that was accepted and will be presented this weekend at the 2016 American Diabetes Association Scientific Sessions meeting. This will be the first data published from the community, and it’s significant because it’s a study BY the community itself. We’re also working with other clinical research partners on various studies (in addition to the usability study, other studies to more thoroughly examine data from the community) for the future, but this study was a completely volunteer DIY effort, just like the entire OpenAPS movement has been.

Our hope is that clinicians walk away this weekend with insight into how engaged patients are and can be with their care, and a new way of having conversations with patients about the tools they are choosing to use and/or build. (And hopefully we’ll help many of them develop a deeper understanding of how artificial pancreas technology works: #OpenAPS is a great learning tool not only for patients, but also for all the physicians who have not had any patients on artificial pancreas systems yet.)

Stay tuned: the poster is embargoed until Saturday morning, but we’ll be sharing our results online beginning this weekend once the embargo lifts! (The hashtag for the conference is #2016ADA, and we’ll of course be posting via @OpenAPS and to #OpenAPS with the data and any insights coming out of the conference.)

How I designed a “DIY” closed loop artificial pancreas

This post was written months ago for Prescribe Design, and will also be posted/made available there as a collection of their stories by and about patients who design, but I am also posting here for anyone new to #DIYPS and/or wondering about how #OpenAPS came into existence.

About the author: Dana Lewis is the creator of #DIYPS, the Do-It-Yourself Pancreas System, and a founder of the #OpenAPS movement. (Learn more about the open source artificial pancreas movement at OpenAPS.org.)  Dana can be found online at @DanaMLewis, #DIYPS, and #OpenAPS on Twitter, and also on LinkedIn.

Diabetes is an invisible illness that’s not often noticeable, and may be considered to be “easy” compared to other diseases. After all, how hard can it be to track everything you eat, check your blood glucose levels, and give yourself insulin throughout the day?

What most people don’t realize is that managing diabetes is an extremely complex task; numerous variables influence your blood glucose levels throughout the day, from food to activity to sleep to your hormones. Some of these things are easier to measure than others, and some are easier to influence than others, as I’ve learned over the past 13 years of living with type 1 diabetes.

Dana Lewis finishing the Leavenworth half marathonDiabetes technology certainly helps – and those of us with access to insulin pumps and continuous glucose monitors are thankful that we have this technology to better help us manage our disease. But this technology is still not a cure. After I run a marathon, my blood sugar is likely to run low overnight for the next few nights. And the devices I use to help me manage still have major flaws.

For example, my continuous glucose monitor (CGM) gives me a reading of my blood glucose every 5 minutes – but I have to pay attention to it in order to see what is going on (pulling the device from my pocket and pressing a button to see my numbers). And what happens when I go to sleep? I am sleeping, rather than paying attention to my blood sugar.

Sure, you can set alarms, and if your blood glucose (BG) goes above or below your personal threshold, an alarm will sound. That’s great, unless you’re a sound sleeper like me who doesn’t always hear these sounds in my sleep – and unfortunately there’s no way on the device to make the alarms louder.

For years, I worried every night when I went to sleep that I would have a low blood sugar, not hear the alarm, and not wake up in the morning. And since I moved across the country for work, and lived by myself, it could potentially be hours before someone realized I didn’t show up for work, and days before someone decided to check on me inside my apartment.

I was worried about “going low” overnight, and I kept asking the device manufacturers for louder alarms. The manufacturers usually responded, “the alarms are loud enough, most people wake up to them!” This was frustrating, because clearly I’m not one of those people.

I realized that if only I could get my CGM data off my device in real-time, I could make a louder alarm by using my phone or my laptop instead of having to rely on the existing medical device volume settings. It would be as easy as using a basic service like IFTTT or an app like “Pushover” that allows you to  customize alerts on an iPhone.

However, for the longest time, I couldn’t get my data off of my device. (In fact, for years I had NO access to my own medical device data, because the FDA-approved software only ran on Windows computers, and I had a Mac.) But in November 2013, I by chance found someone who tweeted about how had managed to get his son’s data off the CGM in real-time, and he was willing to share his code with me. And this changed everything.

Taking a photo of a CGM screen and printing it out is not very efficient for reviewing BG data.(At the time, my continuous glucose monitor only had FDA-approved software that could be used on a Windows computer. Since I had a Mac, when my endocrinologist asked for diabetes data, I took a picture with my iPhone and pasted the images into Excel, and printed it out for him. Data access is an ongoing struggle.)

My design “ah-ha” became a series of “wow, what if” statements. At every stage, it was very easy to see what I wanted to do next and how to iterate, despite the fact that I am not a designer and I am not a traditional engineer. I had no idea that within a year I would progress from making those louder alarms to building a full hybrid closed loop artificial pancreas (one that would auto-adjust the levels on my insulin pump overnight).

Once I had my CGM data, I originally wanted to be able to send my data to Scott (my then-boyfriend and now husband, who lived 20 miles away at the time) to see, but I didn’t want him to get alarms any time I was merely one point above or below my target threshold. What was important for him to know was if I wasn’t responding to alarms. We set up the system so that Scott could see whether or not  I was taking action on a low reading, which I signaled by pressing a button. If the system alerted to Scott that I was not responding to a low reading, he could call and check on me, drive 20 miles to see me, or call 911 if necessary. (Luckily, he never needed to call 911 or come over, but within a week of building the first version of the system, he called me when my blood sugar was below 60 and I hadn’t woken up yet to the alarms.)

DIYPS prototype with Pebble
DIYPS prototype with Pebble

I realized next that if I was already pushing a button on the web interface (pictured), I might as well add three buttons and show him what action I was taking (more insulin, less insulin, or eating carbohydrates) in case I accidentally did the wrong thing in my sleep. I also customized the system so that I could log exactly how much insulin I was taking or how much I was eating.

Because I was entering every action I took (insulin given, any food eaten), we realized that this data could fuel real-time predictions and give precise estimates of where my blood sugar would be 30, 60, or 90 minutes in the future. As a result, I could see where my blood glucose level would be if I didn’t take action, and make sure I didn’t overcorrect when I did decide to take action. This was helpful during the day, too. The CGM has alarm thresholds that notify you if you cross the line; but #DIYPS will predict ahead of time that I am likely to go out of range, and will recommend action to help prevent me from crossing the threshold.

The system worked great and generated many alarms that woke me up at night. (Ironically, we generated so many alarms that Scott would periodically change the sound of the alarm without telling me, because my body would get used to ignoring the same sound over time!) The next step was deciding to get a smart watch (in my case, a Pebble) so I could see my data on my watch, and reduce the amount of time I spent pulling my CGM receiver out of my pocket and pressing the button to turn the screen on. With a watch, it was also easier to see real-time push alerts that the system would send me to tell me to take action. As a result, I was able to begin to spend less time throughout the day worrying about my blood sugar, and more time living my life while the system ran in the background, updating every few minutes and alerting me as to when I needed to pay attention when something changed.

We called this system the “Do It Yourself Pancreas System”, or #DIYPS, and we developed it completely in our “free time” on nights and weekends.

People often ask what my health care provider thinks. He didn’t appear very interested in hearing about this system when I first mentioned it, but he was glad to hear I was having positive outcomes with it.

More significantly, I had a lot of other people with diabetes interested in it and wanting to know how they could get it.

As a patient, I can only design tools and technology for myself; but because it would be seen by the FDA as a class III medical device (and making dosing recommendations from a CGM rather than a blood glucose meter, which the CGM is not approved for), I can not distribute it to other people to use as it would have to first be reviewed and regulated by the FDA.

With this in mind, Scott and I were both also working with the Nightscout project (another community-developed DIY tool that helps you share or more easily view your diabetes data). We were able to incorporate some of the key features we had built in #DIYPS, like the visualization predicting where the blood glucose would be based on carbohydrates and insulin activity.

We also kept iterating on #DIYPS and the algorithms I use to predict when my blood sugar is going to end up high or low. By the time we made it to November of 2014, we realized that we had a well-tested system that did an excellent job giving precise recommendations of adjusting insulin levels. If only we had a way to talk to my insulin pump, we theorized that we could turn it into a fully closed loop artificial pancreas – meaning that instead of only allowing my insulin pump to give me a pre-determined amount of insulin throughout the night, a closed loop system would instead take into account my blood sugar and make the automatic needed adjustments to give me more or less insulin as needed to keep me in range.

Components of an #OpenAPS implementation: pump; CGM; Raspberry Pi with battery and a radio communication deviceWith the help of Ben West, another developer we met while working on Nightscout, who has spent years working on tools to communicate with diabetes devices, we were able to take a carelink USB stick and use it to communicate with my insulin pump. Plugged into a raspberry pi (a small, pocket sized computer), the carelink USB stick could pull from our algorithms, read from the pump, write commands (in the form of temporary basal rates for 30 minutes), read back the results, update the algorithm and generate new predictions and action items, and then do the same process over and over again.

And so, with the help of various community members, we had closed the loop with our artificial pancreas. And once I had it turned on, testing, and working, it was hard to convince me to take it off. This was December of 2014. More than a year and a half later, I’m still wearing and using it every day and night.

Dana BGs with OpenAPS

There are definitely challenges to having self-designed a device. There are usability issues, such as the burden of keeping it powered and extra supplies to haul around. But as a patient, and as the designer, I can constantly iterate and make improvements to algorithms or the device setup itself and make it better as I go, all while having the benefit of this lifesaving technology (and more importantly, having the peace of mind to be able to go to sleep safely at night).

And, I have the ability to communicate and spread the word that this type of DIY technology is possible. I frequently talk with others who are interested in building their own artificial pancreas system as part of the OpenAPS movement. Like #DIYPS, I can’t give away an #OpenAPS implementation or build someone else an artificial pancreas. But through #OpenAPS, the community has collectively published a reference design, documentation and code, and established a community to support those who are choosing to do an n=1 implementation, following the reference design we have shared. As of the beginning of May 2016, there have been a total of 56+ people who have decided to close the loop by building individual OpenAPS implementations, with more in progress. You can read more here about the risks and how it is a personal decision to decide to build your own system; each person has to decide if the work to DIY and the risk is worth the potential reward.

For me, this definitely has been and is worth the time and effort. It’s worth noting that I am glad there are traditionally designed devices going into clinical trials and are in the pipeline to be made available to more people. But the timeline for this is years away (2017-2018), so I am also glad that the technology (including social media to enable our community to connect and design new tools together) is where it is today.

You don’t have to be an engineer, or formally trained, to spot a problem with disease management or quality of life and build a solution that works for you. Who knows – the solution that works for you may also work for other people. We can design the very tools we need to make our lives with diabetes, and other diseases, so much better – and we shouldn’t wait to do so.

Feedback on proposed FDA guidance on interoperable medical devices

Our friend Anna McCollister-Slipp first alerted us to the proposed draft guidance recently released from the FDA, covering medical device interoperability. (You can read the draft guidance linked here.) We were subsequently among those asked by Amy Tenderich, and others, to share our initial thoughts and comments in response to the draft guidance. We wanted to publicly share our initial thoughts as a draft comment in response to the proposed guidelines (which we plan to officially submit as well), in hopes of encouraging subsequent discussion and additional commentary submitted in response to the draft guidance. We’d love to hear your thoughts after you read the linked guidance, as well as our comment below, and also encourage you to consider submitting a comment to the FDA regarding the guidance.

Draft comment response by Scott Leibrand & Dana Lewis:

The proposed FDA guidance on medical device interoperability is a gesture in the right direction, and is clearly intended to encourage medical devices to be designed with interoperability in mind. However, in the current draft form, the proposed guidance focuses too much on *discouraging* manufacturers from including the kinds of capabilities necessary to allow for continued innovation (particularly patient-led innovation as seen from the patient-driven #WeAreNotWaiting community).  Instead, much of the guidance assumes that manufacturers should only provide the bare minimum level of interoperability required for the intended use, and even goes so far as to suggest they “prevent access by other users” to any “interface only meant to be used by the manufacturer’s technicians for software updates or diagnostics”.  There is also much note of “authorized users”, which is language that is often currently leaned upon in the real world to exclude patients from accessing data on their own medical devices – so it would be worthwhile to further augment the guidance and/or more specifically review the implications of the guidance with an eye toward patients/users of medical devices.  The focus on including information on electronic data interfaces in product labeling is a good inclusion in the guidance, but it would be far more powerful (and less likely to be interpreted as a suggestion to cripple future products’ interoperability capabilities) if manufacturers were encouraged to properly include interface details for *all* their interfaces, not just those for which the manufacturer has already identified an intended use case.

Specific suggestions for improving the proposed guidance on medical device interoperability:
  • The guidance needs to more explicitly encourage manufacturers to design their products for *maximum* interoperability, including the ability for the device to safely interoperate with devices and for use cases that are not covered by the manufacturer’s intended uses.
  • Rather than designing device interoperability characteristics solely for intended uses, and withholding information related to non-intended uses, manufacturers should detail in product labeling the boundaries of the intended and tested use cases, and also provide information on all electronic data interfaces, even those with no manufacturer-intended use.  Labeling should be very clear on the interfaces’ design specifications, and should detail the boundaries of the uses the manufacturer intended, designed for, and tested.
  • The guidance should explicitly state that the FDA supports allowing third parties to access medical devices’ electronic data interfaces, according to the specifications published by the manufacturers, for uses other than those originally intended by the manufacturer.  They should make it clear that any off-label use by patients and health care professionals must be performed in a way that interoperates safely with the medical device per the manufacturer’s specifications, and it is the responsibility of the third party performing the off-label use, not the manufacturer, to ensure that they are making safe use of the medical device and its electronic data interface.  The guidance should make clear that the manufacturer is only responsible for ensuring that the medical device performs as specified, and that those specifications are complete and accurate.
With these kinds of changes, this guidance could be a powerful force for improving the pace of innovation in medical devices, allowing us to move beyond “proprietary” and “partnership” based solutions to solutions that harness the full power of third-party innovation by patients, health care professionals, clinical researchers and other investigators, and startup technology companies.  The FDA needs to set both clear rules that require manufacturers to document their devices capabilities as well as guidance that encourages manufacturers to provide electronic data interfaces that third parties can use to create new and innovative solutions (without introducing any new liability to the original manufacturer for having done so).  If the FDA does so, this will set the stage to allow innovation in medical devices to parallel the ever-increasing pace of technological innovation, while preserving and expanding patients rights to access their own data and control their own treatment.

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.