My Health2.0 submission goes to eleven

I decided to enter the Health 2.0 Developer Challenge.

My submission is toeleven.org

My goal was to find a way meet one of the challenges using some kind of integration with our new Audio PHR system Your Doctors Advice. (At the time of the writing its in a closed beta… you can sign in, but cannot use it yet) This has been the project that I have been working on for almost a year, with Cautious Patient.  but I let time get away from me, and I could not find a way to get anything interesting done in time, that applied to any of the Challenge categories. Next year we will consider writing our own challenge.

But I discovered that a part-time project that I have been working on for the last month or so actually applied to a contest to re-implement some of the original Project HealthDesign applications. One of those applications was, specifically, an application designed to track Observations of Daily Living (ODLs) for people with chronic pain. I have friends and family with chronic pain, and I actually wrote this application to help one of them keep a pain/food journal more easily.

The contest had two requirements: re-implement one of the original designs from one of the videos, and use a “commercially available PHR service that can securely store the data”.  What is a PHR? It is a personal (or “personally controlled”) health record. What the contest makers meant was to try and get new functionality available in Google Health, or HealthVault or Dossia or the like.

Well Google Health has been, until very recently been incapable of storing ODLs because it insists on the limited data that a CCR can encompass. Even with the new update, Google Health has limited abilities to store arbitrary data. Im not sure if I can easily include pictures of food in a Google Health app (this might have changed recently). HealthVault has famously supported the recordings of arbitrary data, but is so capable in this regard that there is little need to force the data into any standard at all.  If I want to participate in either approach, I have to go through very extensive integration and approval process. Neither platform is truly open. Perhaps that makes them “safer” for patients, but perhaps that just makes them walled gardens with useless inscrutable iphone-app-store-like approval process that stifles true innovation… you know… one or the other….

I much prefer Twitter and Facebook as application platforms, who have far more open application approval processes. These platforms have realized that their success is tied to the openness of their networks. They are acting much more like “Internets with new protocols”.

But Twitter is not appropriate for health data… because it is essentially a public broadcast medium? Right? That is the way it is typically used, and it is certainly a broadcast technology. But it is not necessarily “public” broadcasting. You can change any twitter account into a protected account, that will ensure that only people you want to see it can see it. So Twitter is “commercially available” that can “securely store the data”, but is it a PHR? I think it is if you use it like one. In fact, it is probably one of the most popular platforms for logging health, wellness and fitness information on the planet.

I think an application that relies on Google Health or HealthVault faces an uphill battle, because that is not where people are tracking ODLs. People actually use Twitter and Facebook to track what is happening in their lives. They use it to record their mood changes, their stress levels and details about how their bowels are moving. Most importantly for my purposes people are already using Twitter as a food diary.  If you want to save time you can just take pictures of your food and use that instead of trying to write down anything. If you are interested in finding out what food might cause pain you are more interested in ingredients than calories, and so food diaries that focus on accurately tracking calorie intake are overkill.

So I wanted a way to simply and easily track ODLs of pain, using Twitter, right beside the already smooth process of tracking food intake.

But I wanted to do this in a way that would be easy to data mine, so that I could take the food data, or pictures, and overlay that in a data-mining friendly way with the pain data. Obviously, I needed a good syntax for recording the pain information, and so I did some research on micro-blogging ODL syntax options. I ultimately settled on the grafitter syntax, because its site was actually up and doing cool data mining stuff. But I did not want my friend to need to actually learn any kind of “twitter syntax” to log her pain. Instead I wanted her to have a simple web form that she could use on her smart phone, that would allow her to quickly and accurately describe her pain. Just like the video from Project Health Design on Helena.

So what is Helena doing? In the video, she is recording which medications she is on. But that is one of the few things that doctors have (or should have) accurate data on. Other than recording that medication data, she is simply creating a ODL system that is customized to her world, allowing her to track -when- she takes the medications, which in her world is just “the yellow pill” or “the big pill”. Moreover, she wants to log three specific things that seem to impact her pain: sleep, yoga and the local weather. But the Twitter ecosystem already takes care of all of that. There are devices that track sleep, that can log the sleep quality data to Twitter. Helena could use fitbit which could log her movement during yoga workouts to Twitter. She can even use Twitter to track the local weather.

Helena and my friend, both have the ability to log very different kinds of data to twitter that are difficult and or time-consuming to acquire in any other way. All they need is a method to create and record their own “Pain Tracking Interface” that could be used to describe what they were going through. One of the project health design teams described one such interface, as part of the many things that the teams released.

So I built a new Twitter application to do that. Its easier to understand if you see it in action once, so here it is:

You can try the application yourself at toeleven.org

So this is not only a method for creating a “Pain Tracking Interface” but for tracking anything you want to perform careful date-stamped quantitative analysis. There is little that you could not track using the system, and it will perfectly interface with any other Twitter data stream so that you can perform data analysis on yourself easily, using Grafitter, or something else just like it.

I want to be clear. I did not write this application to win the contest. I wrote this application to help my friend. It is far enough along that my friend can do what she needs to figure out her pain. This idea can easily go farther, but this is not my main priority. I am going to talk about where this should go, but do not assume that I am going to be the one to do this. Competition and collaboration welcome.

I am releasing all of the php sourcecode for toeleven.org as Open Source as soon as I have the cycles. I think the following work needs to be done on the system.

1. Create a replacement data analysis tool for grafitter, with more functionality, specific to ODLs
2. Improve the iphone and android specific interfaces to the ODL forms
3. Build in facebook integration for those that do not want to link twitter to facebook
4. Create much better form-builders that make it more obvious how to build forms for different things, specially targeting HTML5 (I feel doing fancy work in the HTML4 world is a waste of time at this stage)
5. Allow users to share their ODL forms that “standardized” ODL forms might become popular based on some kind of crowd-sourcing approach.
6. The interface is a little sparse, could be improved alot with some good design work.

I also did not submit the application to win the contest, as much as to try and reframe the problem. I want to make a difference in the world of Personal Health Information, and I know I am not alone in this. But we need to stop trying to force people into behaviors that they will never commit to. The largest single “addressable” healthcare issue is compliance. If we all did what we should know that we are supposed to do, then many of the difficult healthcare problems, like Diabetes, Heart Disease and even HIV would become rare events, and manageable for our society.  I am overweight. So I have a compliance problem. I need to focus on losing the weight, which will protect my heart in the long run, rather than interfacing with some software that I have to comply with. Our goal with the Audio PHR, is to create an application that helps people do the right thing more than it creates new user burdens. I am not convinced that our PHR philosophies are simple enough. I am not convinced that toeleven.org or our Audio PHR is simple enough. But they are simpler. That is a step in the right direction.

Normally, I would also talk about how we need to be working together on open systems using open source software at this point. But Project Health Design and Robert Wood Johnson are absolutely the choir when it comes to that sermon. They understand the potential of Open Source. My goal with submitting this application is not to win, although that would be nice. My goal is to completely reframe the problem. I want them to see that their notion of PHR is trying to force people to move against the current. Facebook and Twitter applications, whatever else you want to say about them… are “with” the current. People are there, using those systems, that is where the action is. We need to bring the behavior changing healthcare innovations to the people, not the the people to the innovations. This is a big paradigm shift, but it is at the heart of Open Source. Essentially I am a developer on one of the Health Design projects, and I have made a pretty signifigant problem into what Torvalds calls a “shallow bug”. The bug is “How do we get people to signup to use this stuff?” I have solved half of that problem, people are already signed up to use Twitter, they just have to use Twitter in a new way… as a PHR.

Eric Raymond experienced this kind of paradigm-shift from a contribution with his fetchmail project. I have quoted this before and I will quote it again:

The real turning point in the project was when Harry Hochheiser sent me his scratch code for forwarding mail to the client machine’s SMTP port. I realized almost immediately that a reliable implementation of this feature would make all the other delivery modes next to obsolete.

For many weeks I had been tweaking fetchmail rather incrementally while feeling like the interface design was serviceable but grubby – inelegant and with too many exiguous options hanging out all over. The options to dump fetched mail to a mailbox file or standard output particularly bothered me, but I couldn’t figure out why.

What I saw when I thought about SMTP forwarding was that popclient had been trying to do too many things. It had been designed to be both a mail transport agent (MTA) and a local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA business and be a pure MTA, handing off mail to other programs for local delivery just as sendmail does.

Why mess with all the complexity of configuring a mail delivery agent or setting up lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any platform with TCP/IP support in the first place? Especially when this means retrieved mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what we want anyway.

There are several lessons here. First, this SMTP-forwarding idea was the biggest single payoff I got from consciously trying to emulate Linus’ methods. A user gave me this terrific idea – all I had to do was understand the implications.

underline mine.

I really think the toleven.org Twitter-centric design is fundamentally more effective than the whole Common Platform effort. While I think both the Common Framework, and its top competitor the Indivo X modular architecture, have some value, they are fundamentally fighting a losing fight, trying to turn the masses into using PHR systems to log data. Forcing each application developer to write code to a separate API which does exactly the same thing in a different way is a non-starter. The only time that happens is when developers have a big motivation. An API is only useful when it has users behind it, and lets be honest, HealthVault and Google Health do not have users. Neither do Indivo X (which is still alpha/beta) or any implementation of the Common Platform. The only PHR systems that actually have any users are the MyHealtheVet application from the VA and the Kaiser PHR. Both of those applications are gateways into deep connection into those respective integrated healthcare delivery systems, something Google Health and HealthVault are not (although they might be someday soon.)

My grandfather once advised me “Never play a man at his own game”. I have taken that to heart. I now live by a modified form of that advice:

If I am failing and cannot see why: change the game or change the rules.

That is why I work with Open Source. It allows me to change the rules. I want to thank Robert Wood Johnson for their commitment to Open Source. The information that their project released made the application that I built for my friend more capable. It allowed me to flesh out the design and prevented me from building a special purpose application. Thanks to Michael Botsko for making a good jQuery Form builder. People like him build tools that let people like me try and make a difference.

-FT