OpenDatabetes

I’ve started a Github project called Opendatabetes in an attempt to get some of my goals into reality. OpenDatabetes will be an open source data model for storing and exchanging diabetes treatment information, as originally dreamed about here.

The Current Model

Do you log your sugars in a personal logbook you made yourself or you write? That’s the only way to really keep it as your data. But you can’t do a lot with the info if you do that.

A more and more popular choice for diabetics is to use some kind of management software, often one that comes bundled with an insulin pump or glucometer. These allow some awesome things like: creation of reports, automated data collection from your devices, sharing information with healthcare professionals, etc. Part of that model is definitely the way forward.

But, caveat time!!: A lot of these systems aren’t great for one reason or another, and many of them are also locked into disappointingly slow release cycles (either because it’s not a key to a large pharma company’s overall income strategy, or because it’s a lot of work for an independent software developer who already has a full-time job). And once all your data is in one of these proprietary systems, changing to a different one isn’t easy because you can’t normally bring your data with you. (changing meters, pumps, or just trying out new management software)

There’s little or no standardization between these proprietary systems. It’s almost like if every website you went to required you to install a new plugin to view it.

How We Ought to Do It

To continue the website analogy: The internet is based on standards set out by the W3C (World Wide Web Standards Consortium). The browser makers defer to the W3C on how the underlying website code (HTML and CSS) works, but they can also contribute to it to help keep the platform evolving.

That’s what we we need for diabetes. Well, not exactly that, but something where there are at least connecting lines between the silos.

Having a central, open standard for diabetes data exchange would empower anyone interested to work with different ways of interpreting or displaying the data and it would free diabetics to experiment with different services without being locked into one. It would allow diabetes tools to be modular and work with one another.

Chart illustrating that with homebrew system you have ownership of data but little ability to use it. With proprietary system you have no flexibility but can get many insights. With Opendatabetes you get best of both worlds.

Are you getting the most out of your diabetes data?

What Does it Look Like?

So just what is OpenDatabetes, practical-deliverable-style?

It is an open data format for recording diabetes treatment information. Basically a file-type, so that if you have a *.dbts file it can be read by any program that supports the format.

It has to be flexible enough to cover various types of treatment: injection, pump, CGMS, etc. It must accommodate for metric and imperial measurements. It must be designed for maximum usefulness and efficiency when integrating with other systems.

Once I have a satisfactory data format, the goal of the project will be to create scripts to convert from proprietary formats to opendatabetes.

The idea is to provide a standard for anyone to use, encourage them to use it, but also make conversion tools so that companies when don’t use them, you can still own your data.

So that’s the genesis of my idea for Open Databetes, and I’ve put some things (mostly my attempts at data-modelling from the Sanguine prototype) on Github. Would love to hear any thoughts on how useful is this project, things to look out for, etc

Let’s make this happen

I’ve let this project languish for a while, but it’s still something I’m quite keen on. And still something that could really help people.

Since I built the Sanguine prototype last year I’ve learned a lot and changed some ideas about how I’d like to approach Sanguine.

1. Focus on the Web

I originally envisioned Sanguine as a desktop application with online syncing and an eventual mobile app. My reasons for this were that it would bring increased security, speed and reliability. My teachers bought my reasoning for this, but I was wrong. Not that those three things aren’t important! They certainly are.  But a desktop application just won’t cut it. The web is becoming faster and more reliable and  it’s just more places, which makes it more accessible. The basis of the new Sanguine will be a mobile-optimized web application that will work from most locations. I’d love to use local storage as much as possible so that it’s still usable when an internet connection can’t be found (this was my biggest reason for putting it on the desktop originally). Eventually there may be room for desktop applications or apps in various app stores, but that’s far down the road.

2. Doing it myself

I don’t really believe that I have the intelligence, skill or time to do all of this myself. I didn’t really before, but I’m more sure of it now. To that end I want to look into what ways I can leverage the community to help me build this. I don’t know exactly how I’m going to do that. I’m thinking about GitHub and open-sourcing the project entirely, or at least parts of it. A lot of this is a bit of a question mark, but it’s something.

3. An Open Standard

Related to the point above, I’ve become preoccupied with the idea of making a system that will be worth something even outside of Sanguine itself. Something that will help other diabetes software makers and companies work together and get more done themselves. Having the desire to be as flexible as possible and interact with as many other devices as possible made me think about trying to find or create a format to facilitate this.

I envision an open standard or data-interchange format that is built to efficiently and accurately store diabetes treatment information and can be used by any system taking into account mg/dl vs mmol/L, standards for storing bolus and basal information, blood sugars, meals, etc. It might consist of a JSON-based data exchange format, as well as a language agnostic database structure for storing this information. I think this is a necessary foundation to build Sanguine on if it’s going to be the best it can. It’s going to be the first thing that gets fully open-sourced; or maybe something like this already exists.

4. Division of Labour

I have determined a few completely separate areas that will comprise Sanguine, that different people or different versions of me could work on completely independently: Collection of data, storing of data, viewing and interpreting data.

Collection of data is the creation of interfaces to retrieve data. The most complex one is from user input through a GUI, but other ones include importing from various devices like insulin pumps and glucometers. There is one main collecting process to be built (first), and then one for each input method. The GUI will be less separate from the other systems.

Storing of data and the generic data collection method are related, possibly should be the same thing. It’s a central sort of database to house all the information.

The viewing and interpreting layer have to do with getting the data back out of the database and how best to do that. With ‘interpretation’ I hope to facilitate some kind of ‘query wizard’ that will allow complex reports to be built and shared without too much difficulty.

Still a fair bit of batting ideas around right now, but I want to put this out here and also invite input from any interested parties.

What’s in a name?

I know the name ‘Sanguine’ confuses people a bit, both in terms of pronunciation and in terms of ‘why the heck are you even here you silly name what are you what’. Some people would call this a terrible marketing decision. But then I’d explain what the name is all about, and they’d be like ‘OHYA’. So here goes:

SANG-gwin.

  1. cheerfully optimistic, hopeful, or confident: a sanguine disposition; sanguine expectations.
  2. reddish; ruddy: a sanguine complexion.
  3. (in old physiology) having blood as the predominating humorand consequently being ruddy-faced, cheerful, etc.
  4. bloody; sanguinary.
  5. blood-red; red.

So:

It’s all about blood, but rather than indicating wounds and dismay it represents cheerfulness and optimism. All the good connotations of bloodiness. And that’s why I think it’s great.