Howard Look, CEO of Tidepool, front, second from leftWe recently had an opportunity to interview Howard Look, CEO of Tidepool, an innovative, open source approach to managing data from diabetes devices. Both Howard Look and Tidepool’s co-founder and CTO, Steve McCanne, have daughters with type 1 diabetes, and are pursuing a groundbreaking vision that will offer a range of benefits for people with type 1 and their caregivers. In the open source system, they are developing a “smart meal” bolus app that remembers how you reacted to the same meal last time and recommends trying a different dose this time; the ability for parents to remotely monitor their children’s devices via cell phones; and will also help in artificial pancreas development. In addition, the cloud-based technology will learn to recognize patterns based on data collected from your devices, and provide you with the ability to communicate easily with your healthcare team through social media channels. An ambitious platform, to be sure, and we greatly enjoyed learning about it from Howard!Who owns your blood glucose and insulin pump data?

Most folks, including Tidepool, believe that the patient owns their health data. “It’s your disease, so it’s your data.” As the owner of that data, you should get to decide who gets access to it, and you should get decide how it gets used. If you want to give access to your doctor, your spouse, and your close friend, you should be able to do that. If you want to view it in an iPhone app that helps you with your diabetes, you should be able to. If you want to donate your data to an anonymized research database, you should be able to do that, too.

Of course there is lots of nuance to the question, especially around what data is considered “personal health data,” and that’s why this is a hard question.

What’s a “Master File” and why are you in talks with the FDA about it?

A Master File is a mechanism that the FDA uses to allow companies to establish a set of documentation that can be referred to by other regulatory filings.

It’s often used as a mechanism for a sponsoring company building a system that uses components from other companies. The component company can establish a Master File and ask that it be kept confidential, but the filing refers to it.

In the case of Tidepool, the FDA advised us that a Master File would be the perfect mechanism for us to use for Tidepool Platform. In our case, since we’re an open source project, it won’t be kept confidential. But it will allow other companies to refer to our Master File if they want to submit a filing for a regulated device or software application that uses the Tidepool Platform.

There’s lots more detail on how Master Files work here.

Can you explain the difference between class 3 and class 2 devices in the eyes of the FDA?

It’s a pretty big topic. In general, when it comes to medical devices, it has to do with the level of risk of the device, whether or not it’s new or if it’s similar to something that already exists (a “predicate”), and the type of filing process required.

In general, class 2 devices are lower risk and have “substantial equivalence” to a “predicate” that can be referred to in the filing. Class 3 devices have inherently higher risk or are new technology. Class 2 devices require what’s called a “501(k)” filing, and class 3 devices require a “PMA” or “Premarket Approval,” a much more stringent regulatory control.

The crazy thing in the world of diabetes devices is that for historical reasons insulin pumps are class 2 devices and CGMs are class 3 devices, even though most would agree that an insulin pump is a far riskier device since it is pumping a potentially deadly hormone. What’s even crazier is that an app that just shows you your CGM data from, say, three weeks ago is also considered class 3 because it’s an accessory to a class 3 device.

blip_press_One day view T1D

What’s the difference between open source versus open data?

“Open data” and “open source” are really two different concepts. In the context of diabetes, “Open data” means “open access to your own personal health data”—it’s your data, and you can easily access it and do with it whatever you want. Conventionally, open data means anyone has access to it. But because this is your health data, the word “open” takes on slightly different meaning.

“Open source” is simply a great way of building software where the source code is openly published and available for inspection. It’s a really popular way of building software that allows software developers to collaborate openly and improve and extend the software together. The open source contributor who write the code has the choice to make available for other people to copy and re-use. Tidepool’s code is available for anyone to re-use freely.

What does “cloud-based data” mean?

The “cloud” is really just another name for the internet and all the things you can store and access online. “Cloud-based data” means that your data is stored on servers somewhere on the internet. Lots of things are “moving to the cloud,” which means that instead of software that runs on your home computer and data that gets stored on your local hard drive, the software runs and data lives “in the cloud.”

universal uploader_Universal uploader

How does open data and open source diabetes information improve diabetes management?

This is just the beginning of open source and open data in diabetes, so it’s still too early to say. It’s easier to point to examples in other domains.

Medtronic is very proud of their CSV export. And in 2004, they should have been. But, if you live in New York or Boston, you know how important it is to check the weather in the morning before you decide which jacket to bring with you. Imagine if the weather forecast was available to you in a CSV file with 65,000 rows of data, like what we get from our Medtronic CareLink. You’d have to go onto your computer (no mobile app!), download the CSV, open it up, and search through 65,000 rows to find your neighborhood and today’s date. Finally, you have the weather forecast you’re looking for. But because weather data is open, hundreds of weather apps are available and everyone has one!

But this CSV world is where we are today with diabetes data. There is no great app. And studies show that less than 5% of patients interact with their diabetes data. It’s no surprise why!

The open source community has taken a stand and said this is not acceptable, #wearenotwaiting. We’ve met people who display CGM glucose values on their clocks and their wristwatches. It’s an incredible use case for anyone who’s had a hypo during a run or a bike ride. Just to glance down at your wrist and see you’re at 85 and dropping.

We’ve met people who can monitor their kids’ BG on their iPhone while they’re at school, at swim practice, or on a sleepover. These kids have a lot more freedom to be a normal kid because mom and dad can still do their job as parent without being a helicopter. None of these precedents would be possible without the open source community. They have given the rest of us something to aspire to. They’re taking the mystery out of the question, “What would people do if they really had access to their diabetes data.”

To take these innovations mainstream, we need device makers to open the data. And remember, these are specialized apps made by individuals for their own use cases. We think the biggest game changing software in diabetes is yet to be invented.

Why do some companies not want to share diabetes data?

We’ve heard a few reasons from different device companies:

Sometimes, the company simply sees itself as a closed ecosystem and they have no desire to make it easy for someone to use the data with different brands of devices. They may also fear losing market share.

Some companies have said that they are worried that if they allow open access to data that competitors might get access to it and interpret it in a way that makes them look bad.

Some companies are worried about liability. “We don’t know how people will use the data, and we’re worried that they will do something bad and then blame us.”

Frankly, we find all of these reasons to be short-sighted. In the US, at best only 30% of people with T1D are using an insulin pump and less than 10% are using a CGM, despite clear evidence that these devices can lead to more effective therapy and better outcomes. As an analogy, the smartphone market “hockey sticked,” as we say in Silicon Valley, when iPhone and Android became platforms that supported third party apps. We strongly feel that when diabetes devices become part of an ecosystem that enables better, interoperable software to emerge, it will make all devices more valuable and will grow the market for all device makers. We also feel partnering with software experts will allow the device companies to use their financial resources to invest in their devices instead of software, which isn’t their strength. “A rising tide raises all boats.”


Why do you think it is important to share diabetes data?

The important thing is that people with diabetes get to decide how their personal health data gets used. For whatever devices they’ve chosen, they should be able to use the tools and apps that are most helpful for them in managing their diabetes, including who they want to share the data with.

Some examples:

  • If you choose to use a Medtronic pump and a Dexcom CGM, you should be able to see your data in one place at one time. (You can do this today with Blip, Tidepool’s first application.)
  • If you are a parent of a small child, you should have a choice in how you see the data for your child and what other people have access to that data (e.g., teacher, doctor, etc.).
  • If choose to use a Mac, or use a different browser than IE, you should still be able to get access to your data.
  • Perhaps there’s a specialized app that you’d like to use. You should get to choose that, too. Maybe you are a pregnant mom with T1D, or an athlete with T1D who wants to use an app that integrates your CGM data with your exercise data.
  • If you’re a healthcare provider seeing 10 or more patients each day, each with a different combination of devices, you should be able to choose your favorite downloading software to use for all your patients instead of having to use different software for each device.
  • And finally, if you are a person with T1D, you should be able to choose to donate your data to a research database.

It’s your disease, it’s your data.


Please explain your partnership with Asante Snap and why it is so important.

Asante led the way in the industry by making their Snap Pump device protocol available, which lets Tidepool include their pump in the Tidepool Platform. Asante was the first device company to embrace the concept of open access to data and has set an excellent example for the rest of the industry in doing so.

Dexcom has also publicly committed to making their data protocol available and we expect other device makers to follow soon.

What is #wearenotwaiting?

#wearenotwaiting is the Twitter hashtag for a theme that emerged at the D-Data ExChange event hosted by DiabetesMine and Tidepool in November 2013. It was a gathering of a folks that share a common belief that we can be doing so much more to deliver safer and more effective therapy for people with diabetes, even using existing technology.

The momentum and energy convinced us that as a community, with an organized effort, we could affect real change. That momentum is reflected at wearenotwaiting.org, as well as in all of the work that Tidepool and many others are doing. There are so many great examples: John Costik’s effort as well as the NightScout team a couple of my favorites.

Bonus question: What should be considered “personal health data?”

When it comes to diabetes devices, there is definitely nuance to this question. Everyone seems to agree that data about carbohydrates, insulin delivery, and blood sugar readings is considered “personal health data.” Most folks even agree that all device settings are part of your therapy and therefore are “personal health data.”

It gets a little trickier when you think about data that the device generates but that the user doesn’t directly see or interact with, such as internal diagnostic data or intermediate data such as ISIG values on a CGM. There is strong argument to be made that since safety and efficacy is at stake, that all data, even internal diagnostic data, should be exposed. We may get there someday—someone will build an insulin pump or artificial pancreas where all data, even the internal diagnostic data, is made available for inspection. That device may even be a completely open hardware and software project.

But “open data” is a new concept for most device makers and we need to take incremental steps. From a practical standpoint, we see types of data as a spectrum, and we’ve take a “laddered” approach to thinking about it:

  1. At a minimum, a device maker should allow the patient access to their own personal health data, including data that is initially generated on the device. In the case of diabetes devices, “personal health data” basically means anything that the patient can see on the screen of the device and that is used to understand or make therapy decisions, like basal rate settings, insulin-to-carbohydrate ratio, insulin sensitivity factors, basal rate change events, blood glucose values, “bolus wizard” events, all patient accessible settings, etc.
  2. Next up the ladder, device makers should make it easy for patients to get access to their data, for example to donate their personal data to a research database or make it accessible to other applications that the patient prefers to use.
  3. The highest rung of the ladder is device makers who really, really believes in open data as a way to enable an engaged patient to better understand their therapy, as well as to evaluate the performance, safety, and efficacy of their devices. This may be data that is not typically shown to the user for example ISIG values from a CGM, pump occlusion pressure, internal board temperature, or battery recharge cycles.

Thank you, Howard, for taking the time to talk with us! Click here to learn more about Tidepool.

Bill Woods–GluBill

Share This
Skip to content