#wearenotwaiting

12 years & counting – are we there yet?

by Dana Lewis

Today marks 12 years of living with diabetes. (Like everyone else, I wonder what to do on yet another diabetes anniversary – celebrate? Cry? Eat gluten-free cupcakes? All three things?) And interestingly, I’m almost at the one year mark of living with diabetes powered by #DIYPS.

When I was diagnosed, my blood glucose meter was bigger in all dimensions than the iPhone 6+.  Luckily, that’s changed, and my meter is now about the size of my Pebble smart watch – and that watch actually shows my my blood glucose readings from my CGM every 5 minutes.

Even better, in the last year, we’ve built a system that will not only give me a number, but help me track changes and push alerts so I can pay attention when needed…but otherwise live my life and not let diabetes get in the way of the things I actually want to be doing (running marathons, reading marathons, saving the world, etc.).

What hasn’t changed, though? My insulin pump. I’m pretty sure it’s a slightly different purple color than it was 11 or so years ago, but not much else has changed. For 11+ years I’ve been wanting:

  • To be able to see (on the pump) a HISTORY of any temporary basal rates
  • To be able to have “days of the week” programmable basal rates. (As you can imagine, my Tuesdays and Saturdays look a little different!)
  • To be able to have “net IOB” calculated and displayed to reflect the true amount of insulin in my body

For 11 years, I didn’t question the lack of progress, much, though. That’s just the way it was. I imagined it would probably be this way until we got a cure for diabetes in (5 or insert your magical number here) years.

I’m glad this is no longer the way it is and that I have tools like #DIYPS. But I hope that medical device companies will get out of their rut and the way they’ve been doing innovation and business for eons and do better. Because what they’re doing right now is not good enough. And #wearenotwaiting.

How and why we are working with the FDA: background and a brief summary of the recent meeting with the FDA about the Nightscout project

by Scott Leibrand

On Wednesday, October 8, 2014, I accompanied several other individuals active within the CGM in the Cloud community (John Costik, Ben West, Bennet Dunlap, and Ping Fang), and an invited guest observer (Mark O’Donnell from Medtronic) to meet with the US Food and Drug Administration (FDA) to discuss the Nightscout project. Our goal was to begin a dialog with the FDA, in which we hope to educate the FDA on the Nightscout system and the open source development methodology behind it, to learn what concerns the FDA might have about the project, and to determine which efforts need to be prioritized to address those concerns and ensure the safety of everyone using the Nightscout system.

As most of you are aware (and as outlined so well in the recent front-page WSJ article), the Nightscout project started with John Costik’s early efforts to improve safety for his son going to kindergarten, by using the USB interface of his Dexcom G4 Continuous Glucose Monitor (CGM) to obtain up-to-date glucose readings, and make that data available remotely. After John and a few others released their code, many other interested developers began improving and extending it using an open-source development model.

Since that time, the CGM in the Cloud Facebook group has grown to over 7,000 members, and the open-source Nightscout project has been developed into the system used regularly by most of the over 1,100 individuals who have made their own copies (forks) of the source code on GitHub. Recognizing that this rapid growth indicated something so important to so many people living with diabetes, the FDA has reached out over the last several months to a number of us at events like the D-Mine D-Data Exchange.

We all recognize that this kind of open-source patient-driven project has the potential to greatly improve patient safety, quality of life, and quality of treatment. Furthermore, this bottom-up innovation also represents a new way of developing potentially life-saving mHealth systems: it falls somewhat outside the way medical devices have traditionally been developed and regulated, both in the open-source nature of the project and the #WeAreNotWaiting-inspired speed of software development, testing, and release.

In light of all this, the FDA encouraged those of us working on Nightscout to begin working with the FDA through their pre-submission process, so they can better understand what we are doing, and so they can work with us to make sure that we are doing everything possible to accomplish the shared goal of maximizing patient safety. We also saw it as an opportunity to work with the FDA to help them develop a model for regulating patient-driven open source mHealth software, which ensures the aforementioned focus on safety without unnecessarily slowing things down. So Ben West did exactly what the FDA suggested, documenting a number of details about how the Nightscout software and project currently work, and formally submitted them to the FDA along with a request for Wednesday’s meeting.

This meeting represented an excellent start on the dialog required to reach those goals. The FDA asked a number of questions about how Nightscout’s open-source development model works. From our perspective, they seemed particularly interested in learning about the (currently largely informal, yet effective) processes we have in place for ensuring that new features and code are well reviewed and tested before being made available to the general public, and for making sure that any reported issues that might represent a safety issue can be appropriately triaged, prioritized, fixed, and the fix distributed back to the people using the software. They also expressed an interest in making sure that there is a core person, group, or entity that is responsible for making sure nothing falls through the cracks and that any modifications or new features are well-tested and work as designed, and who will take responsibility and take appropriate action if something goes wrong.

Prior to Wednesday’s meeting, some people had expressed concern whether formally engaging with the FDA would put the Nightscout project at risk, and possibly even result in the FDA “shutting it down” and taking away a tool that many people find invaluable in helping ensure the safety of themselves or their loved ones. Given the FDA’s desire to work with us, we did not think that would be a significant risk. In fact, we felt that failing to engage the FDA would be irresponsible, because it would not only put the project at risk, but it would mean that we were not doing everything we could to ensure safety.

Now that we have actually had our first meeting with the FDA and heard what their major concerns are, I am even more confident that we are on the right track. The FDA’s initial questions were mostly focused on making sure that we have good processes, procedures, and systems in place to make sure Nightscout is safe as it can be, even in rare and challenging circumstances. We share their focus on safety, and while we have already put in place systems to address most of the things they are concerned about, we are also committed to working with them to identify and close any gaps. The FDA has not yet indicated to us that they have any problems with what Nightscout is currently doing, but rather indicated they want to learn more, discuss internally, and keep communications open.

We are currently in the process of writing up formal minutes based on the notes I took at the meeting and getting those over to FDA so they can review them for accuracy. Once they approve the minutes, we plan to post them, along with the raw notes, for everyone to review.

Over the next few weeks and months, we will be undertaking an effort to document (and in some cases improve) our processes and systems. That is partly so the FDA knows we’re doing the right thing, but it’s even more importantly so that all of you, the CGM in the Cloud community, can be confident that we’re all doing everything we can to keep our loved ones safe. That is the primary goal that we all share, and #WeAreNotWaiting to make it happen.

An artificial pancreas may not be good enough – #DIYPS perspective

by Dana Lewis

I didn’t expect to end up with #DIYPS when Scott and I first started building a system that would make louder CGM alarms. (If you are new to #DIYPS, read this post to learn more about it!)

But, as we added ‘snooze’ features for the loud alarms; the ability to input carbohydrates and insulin into the system; figured out that knowing your carbohydrate absorption rate is critical for managing diabetes as is the timing of the insulin activity in your body during mealtimes; and realizing that net IOB (factoring in temporary basal rates) matters…we ended up with today’s version of #DIYPS.

After the first 100 days, we knew #DIYPS was as good as the bionic pancreas was performing in clinical trials. And after several more months, I’ve had sustained results that show the value and impact of this type of system.

But, as more news and attention lately is focused on the “bionic pancreas” and APS (artificial pancreas systems), I have started to wonder… will those be good enough (for me)?

APS/bionic pancreas will not be a cure – it will not take away diabetes. It will make managing diabetes easier for many people.

But since I have #DIYPS, those systems may not be good enough (initially, for me).

The big difference between #DIYPS and APS is automation. With #DIYPS, I make all decisions and push all buttons to add or reduce insulin. There is still a “human in the loop”.

My hope would be able to add the ability for DIYPS to automatically set basal rates to zero temporarily overnight in advance of predicted low BG, to help prevent lows without having to wake up from a deep sleep and take that action myself. (And as Medtronic’s Low Glucose Suspend (LGS) technology has shown to the world and FDA, the risk of stopping insulin delivery for up to two hours while someone is sleeping is lower than it would be to continue providing insulin to them if they are not waking up and are low.)

If we’re able to make that happen with #DIYPS, I may be one of those people who doesn’t want to jump on board for day 1 of the first market available artificial pancreas system or bionic pancreas. (Although I reserve the right to change my mind :D). After all, at this point it would be a battle of the algorithms to see what system might work best for the most people. (And since I have my own algorithms that Scott and I developed, they might be better than the alternative for me.)

I also can imagine that there will be many people who won’t implicitly trust the/a system to make decisions for them all the time. They’ll still want a “human in the loop”.

#DIYPS-type systems that are “decision assist systems” may play an important role as a stepping stone platform for people to get comfortable with this new generation of technology that can predict lows and highs and make recommendations for them to take action.

Eventually, maybe everyone will be on an APS or bionic pancreas. Even setting aside the difficult questions of cost, availability, and insurance coverage, I know that one technology will not fit every person with diabetes (like how CGM in the Cloud is not for everyone); one system will not meet the needs of everyone; and none of us will be ultimately satisfied until we’ve prevented and cured all types of diabetes and eradicated the impact of any complications from diabetes.

But until we get there, #wearenotwaiting.

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

by Dana Lewis

#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 hashtag, Dana 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

#DIYPS, pathways to Artificial Pancreas Systems, and diabetes technology for all

by Dana Lewis

—

#DIYPS=on path to artificial pancreas but not limited to those using newest diabetes tech. http://bit.ly/1mMS7LA @danamlewis @scottleibrand

—

Like many others, we’ve been reading the latest in the New York Times about the impact of diabetes technology innovation on the cost of managing the disease – not to mention the reactions to the piece, the response to the reactions, the reactions to that, etc.

We believe there is a better way forward, and #WeAreNotWaiting to make it happen.  Innovation can happen in a low-cost way, and can be scaled to support a broad patient audience, without contributing to or requiring significantly increased healthcare costs. #DIYPS for example (check out these results) was developed by two individuals, not an organization, with the goal of solving a well-known problem with an existing FDA-approved medical device. As recounted here (from Scott) and here (from Dana), we 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 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

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 #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

We think this type of device-agnostic software/technology is critical as we work on pathways to the artificial pancreas systems (APS). While we hope APS is out on the market soon (10 years ago would’ve been nice :)), we know it will take several years to a decade. And, even when it comes out, APS will be expensive. It may not be covered by insurance. Even with insurance, people may not be able to afford it. And even if everyone could afford it, some people may prefer not to use it.

—

We believe technology like #DIYPS can, and must, scale to take advantage of real-time data from CGMs, insulin pumps, and any other new diabetes technology, and help patients achieve the best possible health and quality-of-life outcomes while waiting for APS systems to become available.  But at the same time, we want to build these types of tools so that anyone with any combination of diabetes tools can use them to better self-manage their own particular condition. For example, availability of bolus calculator tools is often limited to those with pumps.  #DIYPS can be used as a simple bolus calculator, with the added benefit that it can keep track of carb absorption and allow the user to calculate correction accurate boluses while still digesting a meal.  Packaged into a simple web or app interface, this would allow people to do the same type of quick data input and calculations to be able to verify/support their mental math.

While #DIYPS is a very effective prototype, we don’t expect it to be the only interface that everyone with Type 1 diabetes uses.  Rather, we hope to integrate it with projects like Tidepool that will allow anyone, with any kind of meter, pump, or CGM, to easily upload their data, and then use any number of tools like #DIYPS to interact with their own data and get both real-time and historical insights from it that will let them improve their own diabetes self-care.  However, to make this possible, we need all medical device makers to open up their devices to allow patients real-time programmatic access to their own data. (A good example – there’s no access to temp basal history on Medtronic pumps!)

We need people and companies with innovative ideas to focus on making those ideas available as device-agnostic software, not solely as a proprietary feature on a single non-interoperable medical device.  And most of all, we need everyone to focus on making the fruits of innovation available as widely as possible, even to patients without the financial resources to buy cutting-edge hardware.

After all, #DIYPS is proof that low-cost innovation can have big results.

#DIYPS goes mobile

by Scott Leibrand

We’ve made progress to enable #DIYPS for on-the-go use.

Previously, we’ve only been able to use it when at home and able to plug the CGM in to an old laptop running Windows. Now, we can get real time predictive alerts anywhere, thanks to an unlocked Moto G that we plug the CGM into. Thanks again to John’s help and his code, the data from the CGM can now be uploaded to the cloud from the phone. We originally planned to use the Moto G on WiFi only, but because of other phone upgrades we ended up finding a cheap way to get data on the Moto G, and will be testing it with data for the next ~6 months.

One challenge for #DIYPS going mobile is that this is another device and more “stuff” a PWD has to carry around. For now, I’m using this case so I can easily drop it in or pull it out of my larger bag that I carry around on most days, while keeping the cords secure. (I’ve found the Moto G’s charger and cords don’t plug in as securely as other devices that we’re used to.)

diyps_goes_mobile

Next steps for #DIYPS mobile testing include using the Moto G and #DIYPS while out running, since I don’t have to rely on WiFi for #DIYPS. It’ll take a few more weeks before I can run regularly due to the cold, rainy Seattle weather, but this will be the most effective road test (pun intended) of the mobile capabilities, and will enable me to test #DIYPS for the first time during intense exercise.

We are also working with Brian, who’s helping us test the system and clean up the #DIYPS code.  We want to get it modular enough for more people to install and use the code more easily, and figure out a better UI (with graphs!). We also want to plug into the frameworks John and Tidepool are using, so we can take advantage of all the great work they’re doing as well.

Stay tuned for more updates.  And if you have some interest and expertise and want to help out, please reach out to us on Twitter or directly.

–Dana Lewis and Scott Leibrand

A DIY Artificial Pancreas System? Are we crazy?

by Scott Leibrand

The Do-It-Yourself Pancreas System (#DIYPS) is a tongue-in-cheek name that recognizes a serious fact: people with (type 1) diabetes (PWDs) have been acting as their own pancreas for years.  What a healthy pancreas does using subcellular machinery in islet beta cells, and a full closed-loop artificial pancreas system (APS) attempts to do automatically using medical technology, are the same things that PWDs have been doing, on their own, with whatever help they can get.  We recognize that for many PWDs the available help is not yet enough, so we are not waiting.

Medical device companies are working on new Artificial Pancreas Device System components, and researchers are conducting clinical trials of artificial pancreas systems incorporating various levels of closed-loop technology to do anything from automatically suspend basal insulin when BGs are below a pre-set threshold (available now in the Medtronic MiniMed 530G) to a fully closed-loop bionic pancreas system that automatically doses insulin (and even glucagon, in one trial) to provide full 24/7 BG control.  However, full closed loop systems are still years away, so there is a serious unmet need for better tools to help people with diabetes manage in the meantime.

The #DIYPS is designed for immediate deployment, using a device-agnostic web-based interface, and optionally ingesting data from any of a user’s existing medical devices using commodity off-the-shelf hardware (such as a Moto G Android phone connected to a Dexcom G4 via USB).  In fact, interactive use does not even require automatic data upload capabilities: once the system is configured for their insulin sensitivity and other user-specific parameters, a user with any sort of CGM or meter can manually enter BG levels, boluses/injection amounts, and carb counts and get an immediate estimate of their resulting BG levels.  In addition, the system will estimate insulin on board (IOB, meaning insulin still working in the body) and unabsorbed carbs, so a later follow-up assessment only requires updating the BG data to figure out if any additional action is required.

The #DIYPS can be used immediately to empower PWDs to prevent many instances of out-of-range BG levels.

The #DIYPS is not a substitute for a true closed-loop Artificial Pancreas*.  It is not a medical device, and does not dose insulin.  However, it does fill two currently unmet needs.  Firstly, none of the CGMs on the market currently support robust enough alerting features to awaken many patients when they experience low BG while sleeping.  Such nocturnal hypoglycemia unawareness is a serious risk for many people with diabetes, and better tools are required to deal with it.  The MiniMed 530G’s Low Glucose Suspend feature is a huge step forward there, but even it doesn’t help with the converse problem: at other times users will end up going an entire night with high BG, and never wake up to their CGM’s high BG alarms.  The #DIYPS’s alert system certainly cannot replace a CGM’s alarms (it’s not a medical device, and various interruptions in connectivity can prevent it from alarming), but it does have the ability to send notifications that can trigger alarms (i.e. on an iPad or phone) loud enough to wake the deepest sleepers. It can also function as a de facto remote alert or monitoring system, allowing family or loved ones in different locations to check and make sure a PWD is responding to alarms. Until device manufacturers get FDA approval for loud enough devices, this alone is enough reason for many people to want to put together their own alerting system like the #DIYPS – and was the original reason for building it.

Secondly, it is currently completely up to patients (with occasional help from their doctors) to determine how much insulin is required at any given time, and decide when additional carbs are required to prevent a low.  Performing such calculations manually every few hours, without ever being able to take a break, is a major problem for the quality of life of many people with diabetes.  There are very few effective tools available today to help, so such calculations are usually done in the user’s head, and are very prone to human error.  (The few tools available are also often not in one system, creating barriers for effective use.) In addition, many factors such as stress, sickness and varying activity levels can impact BG levels.  This combination of factors often results in frequent (often daily) instances of low or high BG levels.  The #DIYPS system provides a framework to support the user in making the best decision in every situation, while reducing the cognitive load on the user, and reduce the risk from harder-to-calculate factors like stress or varying activity levels.  It also helps the user to pay more attention and take action when they are at risk for hypoglycemia (predicted based on CGM, IOB, and carb data input into the system), while allowing them to continue living their life normally, with less worry about managing diabetes.

Finally, the #DIYPS system is designed to be device and data source agnostic, and to integrate with frameworks like Tidepool to allow users to do things that have never been possible before.  As new and better medical devices are released, our hope is that all of them will support methods for allowing a user to export their own data, so that users can truly take advantage of all the innovation we are starting to see in this space.

But today, the #DIYPS is just a prototype system, and has only been development tested with a single user.  In order to determine whether it can truly fulfill the unmet need described above for a wider population, additional development and testing are required.  At this point, we are looking to begin collaborating with anyone who has the skills and interest required to move the project forward.  We are not yet ready to begin allowing (and helping) a large number of users to begin testing the system themselves, but hope to open it up (and hopefully integrate it with the efforts underway at Tidepool.org, among others) in a manner that will allow as many people as possible to begin safely using the system as soon as possible.  However, this is currently only a 2-person side project, so if you think it’s worthwhile to move forward more quickly, I would encourage you to get involved (if you have technical or other skills that would be helpful) or pass along the word to others who might be interested and able to help.  (And if you haven’t already, you might also want to read How I Became a DIY Artificial Pancreas System Builder.)

P.S. A special thank you to John Costik, who graciously provided the drivers we’ve been using to pull data off the Dexcom CGM to a Windows PC, and who is working on perfecting the Android (Moto G) drivers as well.  We wouldn’t have done any of this if it wasn’t possible to get data off the Dexcom CGM in real time.  We’d also like to thank members of the diabetes online community for their support, encouragement, and feedback: we know y’all will be pivotal in driving this forward.  :-)

–Scott Leibrand and Dana Lewis

*Update in December 2014: We wrote this post in February, when #DIYPS was truly a “human in the loop” decision-assist system. However, as of December 2014, we closed the loop with #DIYPS, and also have a version of #DIYPS that is essentially a closed loop artificial pancreas. You can read more about our work on the closed loop artificial pancreas version of #DIYPS here.

How I Became a DIY Artificial Pancreas System Builder

by Scott Leibrand

As some of you may know, I’m a Network and Systems Engineering type who works in the Internet industry.  I have a B.S. in Cell and Molecular Biology, but I have been working in computer networking and for Internet companies for the last decade and a half (since I was still in school), and have had the privilege of working on a number of different types of systems in that time.  Nine months ago, I met a wonderful person who happens to have Type 1 Diabetes, and began learning just what was involved in managing the condition.

On the one hand, I was impressed at the level of data available from her CGM (glucose readings every 5 minutes), and the visibility that provided into what was going on.  But I was also very surprised to find that the state-of-the-art medical technology she uses is, in many ways, stuck in the last century.  Data is not shared between devices; her pump looks and acts like it came straight out of the early 1990s.  (But at least it’s purple!) 😉

Most importantly, it is completely up to the person with diabetes (PWD) to collect all the relevant data on their current state, do a bunch of math in their head, and decide what to do based on the data, their experience, and how they’re feeling.  And as a PWD, that’s not something you just do once in a while: it is a constant thing, every time you eat anything, every time your blood sugars go high or low (for dozens of reasons), every time you want to go exercise, etc. etc. etc.  As a PWD, you’re dealing with life-and-death decisions multiple times a day: Too much insulin will put you into hypoglycemia and can kill you.  No insulin for too long will put you into diabetic ketoacidosis and kill you.  Overreacting to a high or low blood glucose (BG) situation and correcting too far in the other direction can completely incapacitate you.  So as a PWD, you never get a break.

So, very early on, the obvious question was: why can’t we integrate all this data and make this easier?  There were promising signs that it could be done: Artificial Pancreas Systems developed by various research groups and medical device companies are in clinical trials, and are showing promising results.  In fact, she had just signed up for such a trial, and I was able to go with her to the clinic and watch just how a fully automated APS system works.  But despite these brief hints of a better future, day to day we were (usually, she was) stuck doing everything manually.

It was very clear from the beginning that the primary bottleneck to doing something better was the ability to get blood glucose (BG) data off her CGM (a Dexcom G4) in real time.  We knew it was possible to do so manually using Dexcom Studio, a Windows-only software package that is actually quite good for analyzing historical BG data, spotting trends, etc.  But unless we were going to create a Windows macro to open up Dexcom Studio, import the data, export it to CSV, and then close Studio every 5 minutes, we couldn’t get our hands on the data to do anything in real time.

Then, we discovered that John Costik had figured out how to use the Dexcom USB driver’s API to get data off his young son’s CGM in real time, and display it remotely, even on his Pebble watch, and even when his son was at day care or kindergarten.  This was the breakthrough we needed, so we contacted John, and he was able to provide us a copy of his script.

So now we were off to the races.  I cobbled together a system using Dropbox for uploading the BG data from a Windows laptop (that ended up in a bedside drawer), and once I was able to get the data onto a VM server, got working on putting together something that would actually make a difference in her quality of life.

So we worked through a number of ideas.  First off, we needed something that could wake her up at night when her BGs got too high or too low.  The Dexcom G4 is supposed to do this, but even its loudest alerts are still not loud enough to wake a sound sleeper.  People recommend sticking the G4 in a glass or in a pile of change, but that doesn’t work, either. She also had used Medtronic’s CGM system; but even its loudest, escalating “siren” alert isn’t all that loud, even if awake.  We also needed something that would allow me to see the alerts remotely, and see whether she is awake and responding to them.  This is a big deal for many people, like her, who live alone.  So, I started coding, and she started testing.  We ended up using my cracked-screen iPad (it got into a fight with Roomba) as a bedside display (it’s much easier to glance over and see BG values than to have to find the CGM and punch a button), and also to receive much louder push notification alerts.

After we got basic notifications working, we also started trying to enhance them.  We ended up with a prototype system that allows the user to enter when they bolus insulin or take carbs, and snoozes alarms appropriately.  (This enables a de facto remote alert monitoring system, especially handy for individuals living alone.)  With that info, we are also able to do the calculations required to determine how much insulin is needed at any given point (the same calculations PWDs do in their head every time they eat or have to correct for high BG), and by doing those every 5 minutes as new data came in, we were able to provide early warning if she was likely to go low, or if she needed more insulin to correct a persistent high.  Since getting all of that working, we have also developed a meal bolus feature, which takes advantage of an (as far as I know unique) ability to track how fast carbs are likely to be absorbed into the bloodstream to give the user better estimates of how much insulin is required now, vs. how much will likely be required later as the rest of the meal is digested.

Since she started began actively testing the #DIYPS (Do It Yourself Pancreas System), we have seen a decrease in average BG levels, with less time spent low, and less time spent high. It also enables her to execute “soft landings” after a high BG and prevents “rebounds” after a low BG.  We are very encouraged by what we’ve seen so far, and are continuing to iterate and add additional alerts and features.  But today, the #DIYPS is just a prototype system, and has only been development tested with a single user, so lots of additional development and testing are required.  We are not yet ready to begin allowing (and helping) a large number of users to begin testing the system themselves, but hope to open it up in a manner that will allow as many people as possible to begin safely using the system as soon as possible.  However, this is currently only a 2-person side project.  We are looking to begin collaborating with anyone who has the skills and interest required to move the project forward, so if you think it’s worthwhile to move forward more quickly, I would encourage you to get involved (if you have technical or other skills that would be helpful) or pass along the word to others who might be interested and able to help.

If you’re interested, you can also read more about why a #DIYPS is needed now (and how it compares to true closed-loop automated Artificial Pancreas Device Systems).  We’ll also be publishing a full description of how the #DIYPS prototype works shortly, so stay tuned.

–Scott Leibrand