But, unexpectedly, it was only terrible on the norovirus symptoms front. My BGs were astoundingly perfect. So much so that I didn’t think about diabetes for 3 days.
Showing the net basal adjustments made on day 2 of my norovirus – the dotted line is what my basals usually are, so anything higher than that dotted line is a “high” temp and anything lower is a “low” temp of various sorts.
When I first started throwing up over the first 8 hours, as is pretty normal for norovirus, I first worried about going low, because obviously my stomach was empty.
Nope. I never went lower than about 85 mg/dl. Even when I didn’t eat at all for > 24 hours and very little over the course of 5 days.
After that, I worried about going high as my body was fighting off the virus.
Nope. I never went much higher than a few minutes in the 160s. Even when I sipped Gatorade or gasp, ate two full crackers at the end of day two and didn’t bolus for the carbs.
The closed loop (as designed – read the OpenAPS reference design for more details) observed the rising or dropping BGs and adjusted insulin delivery (using temporary basal rates) up or down as needed. I sometimes would slowly rise to 150s and then slowly head back down to the 100s. I only once started dropping slowly toward the 80s, but leveled off and then slowly rose back up to the 110s.
None of this (\/\/\/\/\) crazy spiking and dropping fast that causes me to overreact.
No fear for having to force myself to drink sugar while in the midst of the worst of the norovirus.
No worries, diabetes-wise, at all. In fact, it didn’t even OCCUR to me to test or think about ketones (I’m actually super sensitive and can usually feel them well before they’ll register otherwise on a blood test) until someone asked on Twitter.
Why this matters
I was talking with my father-in-law (an ER doc) and listening to him explain how anti-nausea medications (like Zofran) has reduced ER visits. And I think closed loop technology will similarly dramatically reduce ER visits for people with diabetes when sick with things like norovirus and flu and that sort of thing. Because instead of the first instance of vomiting causing a serious spiral and roller coaster of BGs, the closed loop can respond to the BG fluctuations in a safe way and prevent human overreaction in either direction.
This isn’t what you hear about when you look at various reports and articles (like hey, OpenAPS mentioned in The Lancet this week!) about this type of technology – it’s either general outcome reports or traditional clinical trial results. But we need to show the full power of these systems, which is what I experienced over the past week.
I’m reassured now for the future that norovirus, flu, or anything else I may get will likely be not as hard to deal with as it was for the first 12 years of living with diabetes when getting sick. That’s more peace of mind (in addition to what I get just being able to safely sleep every night) that I never expected to have, and I’m incredibly thankful for it.
(I’m also thankful for the numerous wonderful people who share their stories about how this technology impacts their lives – check out this wonderful video featuring the Mazaheri family to see what a difference this is making in other people’s lives. I’m so happy that the benefits I see from using DIY technology are available to so many other people, too. At latest count, there are (n=1)*174 other people worldwide using DIY closed loop technology, and we collectively have over half a million real-world hours using closed loop technology.)
I have now lived with diabetes for more than half of my life.
That also means I have now lived less than half of my life without diabetes.
This somehow makes the passing of another year living with diabetes seem much more impactful to me. Maybe not to you, or to someone else with a different experience of living with diabetes and a different timeline of life before and after diagnosis…but to me this is a big one.
I’m happy to have context, though, to help me keep things in perspective. For example, I’ve now lived with a closed loop artificial pancreas (or automated insulin delivery) system for almost two full years.
(That’s almost as significant a marker of a “with” vs. “without” comparison as living “with” vs. “without” diabetes.)
And because I ended up with type 1 diabetes, I found out that doing things for other people and the communities you’re a part of is a powerful way to help yourself, both in the short term and the long term. That’s what drove me to figure out a way to take #DIYPS closed loop and make it something open source. And by doing that, I learned so much more about open source, and have been able to partner with incredible people innovating in hardware and software. These collaborations have resulted in an incredibly rich community of passionate people I like to call #OpenAPS-ers.
While #OpenAPS is by no means a cure, and no artificial pancreas will be a cure, they provide an immeasurably improved quality of life that a lot of us didn’t realize was possible with diabetes. Someone told me he can get the same results for his child living with diabetes, but with #OpenAPS it requires about 85% less work. And given the enormous time and cognitive burden of diabetes, this is a HUGE reduction.
And now doors are opening for us collectively to make even more of a significant impact on the diabetes community, and our fellow patient communities. Yesterday, while at the White House Frontiers conference, NIH Director Dr. Francis Collins was in the audience during my panel. At the end of the day, he stopped me to ask questions about my experiences and perspective on the FDA and what we need from the government. I was able to talk with him about the need for FDA & other parts of the government to help foster and support open source innovation. We talked about the importance of data access for patients, and the need for data visibility on commercially approved medical devices.
This is not just a need of people with diabetes (although it’s certainly very applicable for all of the manufacturers with pipelines full of artificial pancreas products): these are universal needs of people dealing with serious health conditions.
Given what I heard yesterday, it’s working. The #WeAreNotWaiting spirit is infusing our partners in these other areas. We are planting seeds, building relationships, and working in collaboration with those at the FDA, NIH, HHS in addition to those in industry and academia. I know they were working toward these same goals before, but social media has helped raise up our collective voices about the burning need to make things better, sooner, for more people.
So if I have to live the rest of my life at a ratio where more than half of it has been spent living with diabetes, I look forward to continuing to work to get to an 85% reduction in the burden of daily life with diabetes for everyone.
You probably heard that a commercial hybrid closed loop (the 670G) has been approved by the U.S. FDA and, like everyone else, are wondering what that means for #OpenAPS.
First, here’s our initial reaction:
And here are some longer form thoughts:
Yes, this is exciting. FDA moved months more quickly then expected (hmm, we are sensing a theme when the #WeAreNotWaiting community is involved ;)) to get this tech approved. And as we’ve experienced (check out this self-reported outcomes study with better outcomes than the pivotal trial for this new device), the results of using a hybrid closed loop are outstanding. It’s disappointing that they won’t be ready to ship until Spring 2017, but…
…This means the company has time to work on user guides and usability. As we’ve told every device company we’ve encountered, we (the #OpenAPS community) are happy to share everything we’ve learned. And we have learned a lot, including what it takes to trust a system, how much info is needed to help determine if additional human action is needed, what to do in all kinds of real-world situations, and more. We hope the companies continue to work with people with diabetes who have experience with this technology from both clinical trials and the DIY world, where we’ve racked up 350,000+ hours with this type of technology. Because setting expectations with users for this technology will be key for successful and sustained adoption.
This doesn’t really mean anything for #OpenAPS, though. The first generation of AP technology is similar to #OpenAPS in that it’s a hybrid closed loop that still requires the human to input carbs into the system, but it unfortunately has a set point that can not be adjusted below 120mg/dl. For many people, this is not a big deal. But for others, this will be a deal breaker. For DIYers, that lack of customization will likely be frustrating. And for many families, the lack of remote data visualization may be another deal breaker. And, like with all new technology and devices, getting this stuff covered by insurance may be an uphill battle. So while optimistically this enables many people in the U.S. to finally access this technology (yay) without having to DIY, it won’t necessarily be truly available to everyone from a cost or access perspective for many years to come. So #OpenAPS and other DIY technology may still be needed from a cost/access perspective to continue to help fill gaps compared to current status quo with basic, non-connected diabetes devices (i.e. standalone pump and CGMs).
I also know that many of the parents of kids with T1D are disappointed, because the initial approval is for kids 14+, and it even notes that the system is not recommended for kids <7 or those taking less than 8u of insulin every day (usually young kids). I asked, suspecting it was related to occlusion, but it sounds more like they just don’t have enough data to say for sure that the system is safe with that small amount of insulin, and they’re working on additional studies to get data in that area.
Ditto, too, for more studies allowing different set points. They stuck with a 120mg/dl set point in order to speed to approval, but fingers crossed they get other studies done and new approvals from FDA before this device ships in the spring – that would be awesome. And I was glad to hear that they do have an “exercise” target of 150. That’s a bit of good…but I’m still hesitant that it is enough. From my personal experience knowing net IOB (here’s why net IOB matters) an hour before and when starting exercise is required information to help me decided whether or not I will need carbs to prevent lows during exercise. I don’t think this device will report on net IOB, but I admittedly haven’t seen the device and hopefully I’ll be proved wrong and the data available will be good enough for this purpose!
So in summary: this is good news. But we still need more FDA approved commercial options, and even with a single “commercial approved option”, it’s still ~6+ months away from reaching the hands of people with diabetes…so we as a #WeAreNotWaiting movement continue to have work to do to help speed up the processes for getting enhanced diabetes technology approved and available on the market, with access to view data the ways we need it.
—
*(Yes, in the title of the post I called it a commercial hybrid closed loop artificial pancreas system. It’s a hybrid closed loop, as is #OpenAPS, but it’s also on the road/part of the suite of more complex artificial pancreas technology. I realize to many PWDs “artificial pancreas” means a lot of different things. Quite certainly, regardless of definition, an artificial pancreas or hybrid closed loop still requires a lot of work. It’s not a cure by any stretch of the imagination. But it’s easy for the media to describe it as an AP, and I also find it a lot easier to describe the small device accompanying my pump when strangers ask as an “artificial pancreas” followed by an explanation rather than saying “hybrid closed loop”.
If anything, I think having the media broadly categorize it as an AP will encourage the diabetes community to ask more questions about what exactly this tech does, leading to greater understanding and better expectations about what the device will/won’t be able to do. So this may result in a good thing.)
My newest #OpenAPS rig is roughly the size of two sticks of Chapstick.
Think about that, especially in context of my earliest rig of a Raspberry Pi, Carelink stick, battery with enough power to last a full 12 hour day (or more), and the bulk that it added to my bag. I was happy to carry it, but once Oskar started working on a smaller rig with better range, for many people it was a game changer!
And now we have another option with a new open source hardware board called the “915MHz Edison Explorer Board“. It’s a board designed to hold an Intel Edison (the ‘mini computer’), and it also has a 900MHz antenna on it – which means we can use it to talk to the insulin pump. This eliminates the need for a separate ‘radio stick’ – like the Carelink or a TI or similar. This is a huge improvement!
What carrying the new rig looks like:
This is what a full rig setup looks like:
Insulin pump
CGM
Explorer Board rig
…and that’s all that’s strictly required. You can use openxshareble to read BG data from the receiver directly, but that’s currently the flakiest part of my setup, so I still recommending hotspotting your phone to pull BG data down from the cloud – and more importantly, so you can use Nightscout or similar to visualize what the loop is doing.
So, today’s post is about the new, shiny, smaller rig, and I know everyone wants to know how to get the parts to build their own!
**Update** – You can order an Explorer Board here. . Keep in mind Edison and battery are not included, so if you don’t already have an Edison, you’ll want to order one of those, too.
Improved #OpenAPS docs in the works, too!
Also, stay tuned – we have a new setup script and guide being developed and tested to streamline the setup of an OpenAPS implementation using this board or any of the previous hardware. These new docs will streamline the installation and configuration of the components required for anyone to build a new OpenAPS implementation for themselves, so they can more easily focus on testing the algorithm and decision making process that’s a critical part of DIY looping.
“You should post that question in Gitter.” –something @DanaMLewis says a lot
I realize it’s not always obvious to those who are newer to #WeAreNotWaiting or #OpenAPS why I am often pointing people to ask their questions in Gitter.
Let me explain:
There is a Gitter chat channel where most of the #OpenAPS and other DIY development conversations happens. (There are several other channels, so if you pop onto the main OpenAPS one, we’re happy to point you to another if there’s another one already built for another or related project.)
Gitter connects with Github, so you can use the same username to log in and ask a question. And very importantly, it’s public, so *anyone* can see the conversations in channel – even if you decide not to log in. See for yourself – click here to view the chat channel. This is very key for an open source project: anyone can jump in and check things out.
Transparency & archiving community knowledge
It also means that questions can be asked – and answered – openly, so that when someone has the same question, they can often find an existing answer with a little bit of searching.
(Tip: there’s a Gitter app for your phone, and for your desktop, both of which I use on the go – but for searching back in the channel, the web Gitter interface has a better search experience, or you can also use Google to search through the archives.)
Faster responses from a smarter, broader, worldwide community
There’s another key reason why asking a question in an open channel is helpful for Q&A. Two words: time zones. There are now (n=1)*104+ people around the world with DIY closed loops, and a lot of them pay it forward and provide guidance and also help answer questions.
If you send one individual a question in a private channel, you have to cross your fingers and hope they’re a) awake b) not working and c) otherwise available to respond.
But if you ask your question openly in a public channel, anyone out of the large community with the answer can jump in and answer more quickly. Given that we have a worldwide community and people across many time zones, this means faster answers and more “ah-ha’s” as people collaboratively work through new and already-documented-sticky-points in the build process.
So if you ask an individual a question in a private channel, you might get a “You should ask that in Gitter!” response. And this is why. You’re welcome as always to ping me across any channel, but often when there’s a good question, I’m going to want you to re-post in Gitter, anyway, so people can benefit from having the knowledge (including any answers from the community) archived for the next person who has the same or similar question.
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.
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:
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.
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”
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?
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.
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.)
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.
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.
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!
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.)
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.
Diabetes 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.
(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
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.
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.
With 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.
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. (And today, you can see the latest community count of DIY closed loopers here.) 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.
You’re welcome as always to ping me across any channel, but often when there’s a good question, I’m going to want you to re-post in Gitter, anyway, so people can benefit from having the knowledge (including any answers from the community) archived for the next person who has the same or similar question.
Recent Comments