“Making” and “DIY”ing – continued

I had a conversation this week with someone in the CGM in the Cloud Facebook group, after they indicated they wouldn’t be (or maybe weren’t interested in) joining the “dev” group for #OpenAPS – and it’s a conversation I find myself having often. Here’s what I usually end up saying, when someone says they’re not a “dev” or “not an engineer” or something similar:

“I’m not a formally trained developer/coder/engineer, either… but I keep telling people, many people in this project aren’t- it’s a passion project where we learn what we need to learn to do the things we want to do. It’s fine if someone chooses not to do something, but I encourage everyone to not let labels or perceptions of traditional roles stop them from jumping in and giving it a try to see what they can learn and thus do! Especially with this awesome supportive community of people willing to help you as you go.”

This also came up when we were discussing what it takes to be a “maker” on TEDMED’s #GreatChallenges live panel today. One of my excellent fellow panelists (Cole) pointed out that pretty much everyone is a maker – whether you tweak a recipe, work with wood, or find any kind of workaround of any sort to make things work. (Which in my mind makes every single person with diabetes a “maker” and probably anyone with any disease or health care condition that they live with.)

I previously wrote about what it takes to DIY from a DIYPS and #OpenAPS perspective (and why that’s important), but I think it holds true across any aspect of diabetes or any other disease state – and definitely beyond healthcare:

Passion, persistence, and willpower needed.

So please, don’t let labels stop you from DOING. You can learn whatever tech skills you set your mind to. You can find numerous ways to solve a problem, whether it’s on your own or by partnering with someone else – and there’s plenty of people with the skills who are willing to help you learn, too.Remember, we started building #DIYPS to make louder CGM alarms. Scott and I have both learned numerous new things and new programming languages and skills along the way as we went from alarms to an alert and recommendation system to a closed loop artificial pancreas (and now people who own 4 Raspberry Pis). We didn’t come to the table with knowledge of everything we needed to know to do what we first wanted to do – and we’re definitely still learning a dozen or more things (programming languages, new software, etc.) along the way as we continue with #OpenAPS. We also didn’t know anything previously about working directly with the FDA – and now we are, on a number of projects, in order to help scale from n=1 of a DIY artificial pancreas to many n=1s around the world.

You can do this. Bring your passion, and go do great things!

#WeAreNotWaiting, are you?

Why the DIY part of OpenAPS is important

I had the chance to talk about DIYPS and OpenAPS during a demo session in DC last week. (Thank you to Gary from Quantified Self and Marty from the National Academy of Sciences for making this possible!)

I walked away with several insights:

  1. Many people don’t know about diabetes; fewer have a realization of current diabetes tech. In several cases as I was describing the closed loop artificial pancreas, people stopped me and were wowed – but not by the closed loop. They were impressed by the CGM.
  2. Others think that this type of technology is already out on the market.

So, I believe we have a long way to go in communicating and advocating for this type of technology. We know it’s behind where it should be – and we want it to catch up. That’s a big part of the OpenAPS goals to help the FDA, device companies, and everyone involved move a little faster than they might otherwise, because #WeAreNotWaiting.

But here’s the other question I was often asked: “How many people have you given this to?”

I frequently embarked on an explanation of how we can’t “give” away #DIYPS or the OpenAPS implementation – in fact, we can’t and won’t give away the code, either. Some of that is because the FDA says no – and some of it is common sense and principles that both Scott and I hold.

Here’s why I think it is so important to keep the DIY in DIYPS and each OpenAPS implementation that is in progress:

  • You need to have a deep understanding of the system before even considering using it on yourself. You need to know what it’s trying to do in all situations, including the fringe cases (the “this is unlikely to happen but if it does…”), so that you know when it’s working – and when it’s not – whether it’s 3pm in the afternoon at work, or 3am and you wake up and find something is not right and the system is not working.
  • You need to go step by step and test and ensure at each stage that it is working as expected – both in a “this is what it should be doing” and “it is giving out the correct amount of insulin”. Remember, insulin is a lethal drug. It’s also a lifesaving drug. It’s important to remember both of these things and balance the risks accordingly.

From the conversations I’ve had with people interested in learning more or getting a DIYPS-type system for themselves, they fall into two categories:

  1. “How can I buy it from you?”
  2. “What do I need to do to make one?”

Given my above reasoning, the second question is my favorite. The first one scares me, if someone does not then switch to the #2 question. Many people do go from #1 to #2, which is great.

DIYPS, for me, and OpenAPS implementations, for others, are works in progress. They’re not perfect. They’re better than what’s out there (like sleeping through alarms when you’re low at night), but they also have big risks. And it’s important to know, and respect these risks, and understand the limitations of the system, before being able to take advantage of this type of system – and to build the system with appropriate safeguards. (This is one of the reason we have OpenAPS, for example, designed to accept multiple failure points – like walking out of range, loss of connectivity, etc.)

The ability to buy a “black box” type system where you don’t know exactly how it works, but you trust that it works? That will be coming from the major device manufacturers in several years – hopefully sooner rather than later, and that’s something that OpenAPS will hopefully help make happen more quickly.

So to answer the #2 question, what do you need to make a DIYPS or OpenAPS of your own?

I’ll answer the technical aspects of this question in another post, but the first thing I always say is: “The willingness to build and test and test and test some more before ever considering using it on yourself.”

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

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.