I had a blast today at my first Health 2.0 code-a-thon. These are held regularly in different cities; today’s was in Washington, DC. Another one will be held on the weekend following (please pardon the plug) O’Reilly’s Open Source Convention. Today I kibbetzed and occasionally probed teams’ decisions with questions without trying to code (or get in the way), and this participation was completely consistent with the wide range of things people were doing. A code-a-thon is a place where people with data in search of ideas meet people with ideas in search of data.
Health 2.0 leadership and staff: Matthew Holt, Lizzie Dunklee, and Shelle Hyde
At the furthest corner of the open space generously given to us by Kaiser Permanente Center for Total Health, one team of three to four people sullenly huddled around a table and pounded their laptops for hours, never saying a word at any time I was there to notice. Two meters away from them sat a clump of voluble health care developers producing nothing concrete at all, but visibly enjoying their conversations around the general theme of “what seniors want.”
Cristian Liu at opening session
I talked to two coding teams about their projects. The first was taking data generated by an agency in Washington, DC about HIV-positive residents and trying to produce visualizations of important trends and variations. The other took records from the Department of Veterans Affairs’ Blue Button site and mashed them up with information available about medications from the National Cancer Institute’s thesaurus through their LexEVS tool. The goal was simply to let a veteran position the mouse over the name of the medication in the Blue Button output and have a description of that medication pop up.
Choice of technology is a central task in any programming project. At a code-a-thon, agile soon morphs into quick and dirty. The HIV team had data in spreadsheet format, so the leader tried at first just to stuff it into a Google Doc and use Google charts to make the visualizations. The Blue Button project leader managed to load the plaintext format into an XML schema, and planned to use Greasemonkey to add the popup. This choice was based on privacy concerns: he wanted to confine data to the screen of the veteran, and didn’t want anything that could potentially send the veteran’s information to a remote system.
Both projects started with three coders, but the HIV one soon attracted another group of three who worked intensively on it through lunch and during the whole afternoon. Although the HIV project ended up with two or three times the number of coders as the Blue Button project, the HIV team remained two separately, loosely coordinating teams. This was even reflected by their positions at opposite sides of the room.
I soon noticed two other handicaps the HIV team(s) had to grapple with. The first consisted of problems with the input data, starting with from the date format (it was simply strings such as 6/11/2011, not a true date in the format Google Docs supports). A second handicap was absolutely classic and has derailed many projects of a bigger scale than this one: the team wasn’t sure what data to select and how to visualize it. Confusion reined over which demographics would be of most interest to the agency who gave them the data, and how to handle complex relationships such as different risk factors for getting HIV. The project leader was familiar with the agency and probably could have enunciated a vision, but for some reason it was hard to get across to the teams.
Turn-out was low for this hack-a-thon. Attendance shrank to about 15 for the presentations of projects. But the tension built as six o’clock approached. At the last minute, I was asked to be one of the judges.
There’s a happy ending to all this: every team overcome its essential difficulties and annoying blocks.
Team Avanade, the quietly intense team whose activity was totally opaque to me, pulled off a stunningly deft feat of programming. They are trying to improve patient compliance by using SMS text messaging to help the patient stay in contact with the physician and remain conscious of his own role in his treatment. A patient registers his cell phone number (or is registered by his doctor) and can then enter relevant information, such as a daily glucose reading, which the tool displays in a graph. Next steps includes adding notifications so the system can remind patients to participate or give them advice. The ability to compare physicians is also a goal. This project, named aether, won first prize today.
The Blue Button team achieved its basic goal of mashing up the NCI thesaurus with medications on a veteran’s display. The output is crude (a lot of XML tags come out in the display, and the inserted text currently overlays the screen instead of being a hover-over), but the proof of concept succeeded. This was a big achievement for two coders with self-described rusty skills. Next steps include hooking up with other data sets and augmenting other fields such as allergies. This team won second prize today.
SeeDC, the HIV team, succeeded in curating their data–which they estimated to take up half their time today–and ultimately stored it in a relational database while using the project leader’s favorite platform (Django) to generate visualizations. Another team member stuck to Google Charts and also produced some very nice displays. One of the team’s goals is to make it easier for their agency not only to view the implications of their data but to generate reports for higher-level agencies. They also plan to work with the agency to help them collect and store cleaner data. This includes moving from paper forms to the web or a mobile interface.
SeNeSo (Senior Network Social) aims to improve the elderly’s social life and their enjoyment of available activities. The proposed platform (no coding was done) includes a calendar, notifications of events, and event invitations. The platform could be integrated with some larger social networking site like Facebook. I could tell, by watching the team’s discussions throughout the day, that these helped the team dramatically focus and scale down their goals to something achievable and clearly of value.
A final project used Google Refine to filter, sort, and check data from FDA product labels (mashed up with some privately collected data) on drugs submitted by firms.
For the Health 2.0 organization, the code-a-thons form a sequence leading up to an annual San Francisco event. The points I want to draw from this event are that 1) joining a code-a-thon for a day is lots of fun, 2) you can meet really fascinating and talented people at code-a-thons, 3) great ideas can really take off at these events, and 4) you don’t have to have domain-specific knowledge (health care in this instance) or even be a professional developer to contribute.