Author: Scott Leibrand

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.

#DIYPS findings can help people with type 1 diabetes, regardless of tech, better manage post-meal blood glucose

by Scott Leibrand

Over the past few months, while developing #DIYPS, we have discovered a few things about mealtime blood glucose (BG) levels that we thought would be worth sharing more broadly. Using the insights, tips, and techniques below, it should be possible for many people with type 1 diabetes to more effectively keep their post-meal (post-prandial) BG levels in range. Here’s what we’ve learned…

After an initial carb absorption delay…

When carbohydrates are consumed, as part of a meal or snack, or to correct a low-blood-glucose (BG) situation, it causes BG to rise, but that rise is both delayed and gradual. In developing #DIYPS’s model, we discovered that for n=1, there is a delay of approximately 15 minutes between carb consumption and when BG starts to rise (as measured by a Dexcom G4 CGM, which actually measures subcutaneous interstitial-fluid glucose levels).

Subsequent carb absorption rate is constant…

In addition, we discovered that the rate at which BG rises after carb consumption is fairly constant, both across food types and over time. For n=1, we observed that carbohydrates are digested and absorbed at a rate of approximately 30g/hour (0.5g/minute), and that this rate is relatively constant beginning after the initial 15-minute lag, and lasting until the last of the carbs are absorbed (up to 4 hours later, in the case of a large 120-carb meal).

Regardless of glycemic index…

We also observed that, for real-world meals, glycemic index (GI) doesn’t matter much for carb absorption rate. Our initial testing was performed on high-GI foods used to correct low BG (juice and Mountain Dew) and a milkshake consumed without corrective insulin while participating in an unrelated clinical trial (to try to detect any endogenous insulin production, which was not present). However, in subsequent real-world use of #DIYPS, we’ve observed the same for almost all meal types. It seems that for meals containing at least some sugar, starch, or other highly accessible form of carbohydrates, the body seems to begin digesting and absorbing the most accessible carbs immediately, and is able to break down low-glycemic-index carbohydrates by the time the higher-GI foods are absorbed.

Additionally, insulin activity at mealtime matters a lot…

While developing and testing #DIYPS (and working to bring A1c down a full percentage point), we also observed that the level of insulin activity at the start of a meal matters a great deal in determining whether BG rises significantly as the meal carbs are absorbed by the body.

Pre-boluses can help…

One fairly common technique for dealing with this, among people with type 1 diabetes, is the pre-bolus. This generally means estimating insulin requirements for an upcoming meal, and bolusing or injecting fast-acting insulin approximately 15 minutes before the meal. Such pre-boluses do help somewhat in preventing large spikes in BG immediately after meals, but in our experience an 80-point BG rise (from 80mg/dl to 160mg/dl, for example) is still common for meals consumed “on an empty stomach” with little or no extra insulin on board (IOB) prior to the pre-bolus.

But pre-bolusing can sometimes be dangerous…

Also, pre-bolusing can contribute to dangerously low BG (hypoglycemia) if a meal is delayed or if you end up eating fewer carbs than expected.

And what really matters is not IOB, but insulin activity…

Based on observing the differences in post-meal (post-prandial) BG between empty-stomach meals and those where insulin was already on board and at full activity from small snacks or correction boluses 1-2h prior to the meal[1], it appears that what actually makes the most difference for post-meal BG is not how much insulin is on board (IOB) at the start of meal time, but rather how much insulin has already been absorbed into the bloodstream and is at full activity.

Because the liver needs insulin when the carbs first hit…

When carbohydrates are initially absorbed by the small intestine, they are directed into the portal vein and pass through the liver before reaching the rest of the body’s circulatory system. The liver is designed to absorb any excess glucose out of the blood at that point, storing it for later release. The mechanism by which the liver does so is dependent on two factors: the presence of higher glucose levels in the portal vein than in general circulation (indicative of ongoing carb absorption), and the presence of sufficient active insulin. If enough insulin is fully active, the liver can absorb ingested carbs just as fast as they can be absorbed from the intestine. If not, then the glucose passes through the liver into general circulation, and cannot be subsequently absorbed by this mechanism, but must be absorbed later by peripheral tissues once insulin levels get high enough.

And a 15m pre-bolus doesn’t get insulin active fast enough…

Even fast-acting insulin does not reach peak activity for 60-90 minutes after injection, since it must be absorbed through subcutaneous tissue into the bloodstream. This means that, if no insulin is on board from previous boluses, the pre-bolus insulin doesn’t really kick in for 30 minutes or more after the start of the meal. In the time it takes pre-bolus insulin to kick in, the body might absorb 15-20g of carbohydrates, resulting in a 60-80 mg/dl rise in BG.

So, some insulin is needed sooner…

So we need to get enough insulin active at mealtime to allow the liver to do its job, but not so much as to cause low BG before or after the meal. The best way we’ve found to do this is to do a small early pre-bolus about an hour prior to a meal. We calculate the size of the early pre-bolus based on the current BG, by determining how much insulin we can safely add and still stay above 80 mg/dl for 1-2 hours. In our case, that means assuming that up to 75% of the insulin activity will occur before the meal carbs kick in. So for a BG of 110 mg/dl an hour prior to the meal, and a correction ratio of 40 mg/dl per unit of insulin, it would be safe to bolus 1 unit of insulin. That 1 U then ramps up to peak activity right at mealtime, and largely prevents any substantial rise in BG immediately after the meal.

Finally, we can time mealtime insulin based on carb absorption…

Once we’re almost ready to eat and it’s time for a normal pre-bolus, it’s important not to over-bolus for all our carbs all at once. Doing so (particularly after a successful early pre-bolus for a large meal) risks causing post-meal low BG, as insulin activity can peak before all the meal carbs can be absorbed. For example, a large meal with 90g of carbohydrates would take 3 hours to absorb, but insulin activity often peaks after 60-90 minutes. So what we have developed and incorporated into #DIYPS is a relatively simple meal-bolus algorithm that dramatically reduces high- and low-BG situations after meals. The most important feature of this algorithm can be implemented manually without #DIYPS, either via multiple boluses or via a combo/dual/“square wave” bolus. The key idea is to bolus only for those carbs that will be absorbed by the time the insulin hits peak activity. So if you have a large meal, you might decide to bolus at mealtime for only the first 30g of carbs initially (minus any prebolus), since those will be absorbed over the first 60 minutes. If the meal totals 60g of carbs, you will then want to bolus for the next 30g of carbs over the next hour, possibly via a continual delayed (“square wave”) bolus, or by doing one or more manual bolus(es) after the meal is over. (The latter strategy is similar to what #DIYPS does, in 0.5U increments, as it allows you to react if you eat more or fewer carbs than expected, or if BG rises or falls unexpectedly in the interim.)

Resulting in almost flat BG, even after large meals…

By combining all these strategies, and providing real-time feedback and alerts when boluses, temp basals, or carbs are necessary, #DIYPS has allowed us to largely eliminate post-meal hyperglycemia, while minimizing risk of hypoglycemia. As detailed previously, this has helped reduce A1c by a full percentage point, reduce BG standard deviation, and increase time in range. While such impressive results are hard to achieve without assistance, it definitely should be possible for many people with diabetes to improve their own ability to manage post-meal BG levels by adopting some of the same techniques into their own self-care.

Note: there have been some updated posts since this original post about how to easily do the “eating soon” mode approach. Take a look at these illustrations for more details on it!

Footnote

[1] A few weeks ago, we were enjoying a weekend down in Portland. Normally, Dana eats a fairly low-carb breakfast, small snacks throughout the day as needed, and ends up with a fair bit of insulin activity at lunch and dinner time. That weekend, however, we had two very large spikes in postprandial blood glucose, after a late brunch, and then again after dinner, following a hike at Multnomah Falls. The next day, we saw a much smaller post-meal rise after brunch, as she had corrected a morning low with juice, and then bolused to prevent a rebound, so that insulin was near full activity at brunch time. Subsequently, we have incorporated these insights into #DIYPS’s “eating soon” mode, and have been able to much more consistently prevent large BG spikes immediately after meals.

Initial findings from #DIYPS after 100 days and comparing it to a bionic pancreas

by Scott Leibrand

—

#DIYPS + @danamlewis = as good as a bionic pancreas! Reduced avg. BG & time spent <60mg/dl. Details: http://bit.ly/1qF6qRp @scottleibrand

 —

Recently, diaTribe published a summary of results presented by Dr. Ed Damiano at #ATTD2014 showing how their bionic pancreas closed loop artificial pancreas system (APS) improved average glucose levels and halved time spent <60 mg/dl in patients with Type 1 Diabetes (T1D), compared to when those same patients were not wearing the system.  The numbers are impressive: mean glucose was reduced from 159 mg/dl to 133 mg/dl in the Beacon Hill study (n=20 adults, 5 days data per patient, for a total of 100 bionic pancreas days).  If that were sustained over the long term and converted to an A1c value, that would represent a 0.9% improvement, from 7.1% to 6.2%. As diaTribe points out, “Those results are unheard of for any diabetes drug or device.”

Given those results, we wanted to see how the bionic pancreas results compared to the results for #DIYPS, and the results were equally impressive: 90-day eAG was better than in any of the study control groups prior to using the system (before #DIYPS =146 mg/dl) and eAG was further reduced to better than any of the bionic pancreas treatment groups (after #DIYPS = 128 mg/dl) after utilizing #DIYPS.  Time spent <60 mg/dl was already lower than for any of the bionic pancreas treatment groups (before #DIYPS = 1.2%), but was reduced still further to 0.9% with #DIYPS.

@danamlewis 30 day estimated average glucose values. Note – #DIYPS began in December.

(Note that for #DIYPS, n=1 at the moment.  These results are specific to a single highly motivated individual, who was already doing everything possible to manage T1D.)

The pre-DIYPS control condition included wearing and using both a continuous glucose monitor (CGM) and an insulin pump.  It is not clear from the diaTribe article whether the subjects in the bionic pancreas study under their “Usual Care” or “Supervised Camp Care” control conditions included the use of such technology, or whether they were using the more common methods of fingerstick meters and multiple daily injections (MDI) of insulin.  If “Usual Care” included patients on MDI, much of the benefit attributed to the bionic pancreas could be attainable using CGM+pump therapy as well.  The #DIYPS data, however, shows significant improvements even compared to CGM+pump in the control condition.

While n=1 (vs. n=20 and n=32 in the two bionic pancreas studies), the #DIYPS data shows the effects of much longer term usage of the #DIYPS system.  The total time using the system (90-100 days) was equivalent between our data and the Beacon Hill study. Also, because #DIYPS has been in use for 100 days now, we have now seen the results in actual A1c values, not just eAG-calculated Projected A1c.  The improvement from pre-DIYPS A1c to the first post-DIYPS A1c data point is consistent with the improvement shown by the calculated eAG results. (Note that we plan to validate with additional data from A1c testing to show the actual improvement in A1c attributable to #DIYPS, and hopefully validating the sustainability of using the system).

Differences between the bionic pancreas & #DIYPS

Part of what makes the bionic pancreas so promising is that it is able to dose glucagon (through a second pump) to correct low or falling BGs. Because #DIYPS uses only an existing FDA-approved CGM, relies on the patient to dose their own insulin through an FDA-approved insulin pump, and is not using glucagon, #DIYPS might not be expected to be able to prevent hypoglycemia as well as the bionic pancreas. However, our data show that #DIYPS’ predictive alarms and proactive correction suggestions allow a patient to prevent hypoglycemia (BGs <60 mg/dl) even better than the bionic pancreas can do. (#DIYPS also suggests, when possible, using temporary basal rates, which often reduces the extra carbohydrates that have to be consumed to prevent or correct a low BG).  Less-motivated patients using #DIYPS may not be able to prevent low BGs quite as effectively, but this is still an important demonstration that such improvements in control are possible before new glucagon pump technology is available on the market in the future.

Differences between bionic pancreas, artificial pancreas systems (APS), and #DIYPS

And finally, and most importantly as a distinction of the difference from the bionic pancreas, #DIYPS does not automatically dose insulin.  It is solely an alerting system (with predictive alerting and real-time calculation abilities), which relies on the user to both validate any suggested actions, and to actually dose any insulin, reduce insulin, or consume any carbohydrates required to manage their BGs.  This means #DIYPS is not an artificial pancreas system (APS), and does not provide the ability  for you to “forget about diabetes” that is such a powerful promise of true APS systems like the bionic pancreas. Yet it does reduce the overall cognitive load of diabetes (and provides additional security mechanisms such as alerting loved ones if you don’t respond to alarms over time). And, #DIYPS shows that better software and alerting can result in dramatic improvements in blood glucose levels, even without automatic dosing of insulin.

What’s next for #DIYPS

As you can tell, we are excited about the promise of #DIYPS for helping people with diabetes (PWD) manage their disease.  But, as mentioned above, all of this is currently being done in our spare time, with no funding or institutional support.  We, and a small group of like-minded individuals and non-profits scattered across the Internet, have decided that #WeAreNotWaiting for research labs and medical device companies to develop a full APS system and get it approved by the FDA (which is still probably 5 years away). Instead, we are doing what we can to make progress now.

But the next step is critical: we need to make this technology available to the people whose quality of life – and possibly even whose lives – depend on it. (This is why we originally set out to build #DIYPS – to help people wake up to overnight CGM alerts who sleep through the one-size-fit-all alarms coming from the device).  Recently we received an email from someone in Europe whose MD tells her that her severe nocturnal hypoglycemia is life threatening, and sent her on a mission to find a system that can wake her up from a severe low and contact a loved one if she doesn’t respond.  In order to help people like her, we need to begin working with researchers and doctors, and hopefully even get funding to develop #DIYPS into a scalable system that can help any PWD manage their diabetes better.

If you are someone (or know anyone) who can help with any aspect of that effort, please reach out to us on Twitter or directly by email. Otherwise, please stay tuned for more updates.

–Dana Lewis and Scott Leibrand

 

 

 

#DIYPS and Pizza, and wondering why we judge people with diabetes for how and what they eat

by Scott Leibrand

What’s your reaction if you read that someone with Type 1 diabetes just ate 110 carbs worth of pizza for dinner?

Go ahead, answer the question out loud (or write it down) before continuing.

No, really. Did you say it out loud? Or at least think about it?

Now, what if you find out that their BG never spiked (only rose 10 points) and then glided along in range (80<in range<150) for the rest of the night?

Were they lucky? Was it a fluke? Or was it the way that it (eating food) actually should work?

If you’re like many of us, your initial reaction (the one we asked you to say out loud so you wouldn’t mis-remember it later) was probably something along the lines of “that isn’t very responsible”. It just *makes sense* to judge someone for eating food that is “so obviously bad” for them. But, is the food bad for them? Or is what we’re trying to say (think) that the food is likely to lead to “bad” or out of range BGs, therefore it’s not a good idea to consume (or consume so much)?

Maybe we shouldn’t be blaming people with type 1 diabetes for not eating “right” or “trying hard enough” to get the health outcomes they want (and we all want for them). Maybe we all need to start working on putting together all the technology that already exists, in a way that actually allows people with T1D to live a normal life and worry less about constantly managing their BGs. The way #DIYPS does for me.

We also need to start working on changing the intuitive attitude that the problem is a lack of “compliance” (related – read this great post from Kerri on “compliance”) with diabetes management/treatment. Instead, why don’t we all work with patients to understand what is difficult for them about managing their diabetes, and what changes we might be able to make in the processes, systems, and technology they use to make it easier and more effective to do so.

(You may be wondering where this blog post came from. It’s related to #DIYPS – I tested the system one night by eating several slices of a frozen gluten-free pizza, which while convenient is often higher carb than the already-high-carb food. And, my instinct was not to talk exactly about how much and what I ate, because I’ve experienced so many times over the years a judgement from observers (with or without diabetes) about what I personally choose to consume – whether it’s a bite (or a correctly portioned serving) of dessert, pizza, or whatever someone thinks is not acceptable for someone with diabetes. Scott was surprised by the guarded way I was choosing to document and characterize this test, and this post is the result of our discussion.)

Thanks to #DIYPS, I’ve found (several times, the above scenario has proved not to be a fluke!) that I can eat large meals full of carbohydrates, and have no or minimal spike in my blood glucose. It doesn’t matter if it’s high protein, high fat, a mix, or lots of sugar (like a milkshake). And that’s changed the way I feel about talking about large-carb/”non-diabetes friendly” meals.

There’s a well-known stigma related to food for people with diabetes, but no one seems to know a way to remove the stigma. We’re wondering if tools like #DIYPS (and being able to see the data and more outcomes when someone DOES eat pizza and *is* ok BG-wise) will help change the conversation?

–Dana Lewis

#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