My First Hackathon

I was almost afraid to admit it to my co-workers: I had never participated in a hackathon before.

The engineering team at HealthLoop is absolutely phenomenal, and I’m not just saying that because I hired them. Most of them are a generation down from me: to them, hackathons, code competitions, and startup buses are familiar territory, and they’ve been participants and winners. Back in my day, get off my lawn uphill both ways in the snow.

This weekend I attended HealthCamp on FHIR, a code-a-thon around HL7’s very interesting, though admittedly still nascent, FHIR API. Information about the code-a-thon itself was scarce until just a couple of days before the event, when they released the judging criteria, which would help define requirements. In short, an app should benefit “beneficiaries” (which is a way of saying “patients” without any risk of invoking empathy), and it should use a FHIR API and other open health care APIs and data sets to complement the FHIR data. The primary FHIR API that they gave us to work with was one that made anonymized claims data available.

As someone with lots of experience building stuff, but no experience at hackathons, I learned quite a few lessons:

Teams will come prepared

“Come on your own or come as a team,” promises the website. So I showed up by myself, only to find myself surrounded by company teams who had spent the last week or two building out the framework for their project, and had a plan for exactly what they would accomplish during the code-a-thon.

Be brave

One of the organizers asked any solo participants to raise their hands. I was right up front in the middle of the room, and I didn’t see anyone else raising hands, so I stayed still as I looked around nervously. Finally out of the corner of my eye I saw one guy raise his hand.

Turns out, there were about eight people flying solo, and seven of us had the same idea: at the break, go find the guy who raised his hand (in fairness, some of them may have raised their hands too, but I didn’t see them). It’s a good thing he was brave enough to do so, and it’s a good thing the rest of us were brave enough to walk over and say hello.

Choose teammates wisely

As the eight of us discussed our backgrounds, skills and ideas, we quickly discovered who was who. Two of us (Jason, the original hand-raiser; and myself) were coders: if there was any technical collaboration to be had, we had to be able and willing to work together. Two were health care experts, and wanted to build some massive universal solution. These people would be an impediment, with their lack of focus. One guy was quiet but seemed like he wanted to contribute and learn, and ended up shadowing the team part of the time. Three others seemed like they were into building a focused, meaningful solution, but two of the three left at some point, and the other one (Brittany) joined the team.

We ended up with a core team of three. Jason had a lot of experience with FHIR, and so took the role of technical and team lead. I was the other coder, and Brittany was the non-technical problem solver. Under pressure to find a team name, we became The Matchsticks. Because, you know, we arrived as individuals, and created a solution with FHIR.

Constrain what you’re building

Jason was the star here, chopping down ideas until we had something small, focused, and possibly achievable. We decided to build a responsive web app that a beneficiary could log into, get a list of their conditions, and for each condition, get some meaningful education. For example, if my grandfather was diagnosed with hypertension, that would show up on the list (ideally as “High Blood Pressure,” not the medical term), and clicking the link would bring up a page of information about how to manage one’s blood pressure. That’s it…but that’s a lot to build in a total of about 9 hours of official working time.

Figure out your roles / Figure out how to contribute

We did hit a bit of a snag initially. Jason and I were at opposite ends of the technical spectrum; he being comfortable with the Microsoft/.NET/Azure stack, and I with the Linux/Ruby/Rails stack. Not much we could do together. So, Jason’s role was to build most of it: query and parse the claims data, build the display, and query for whatever other information we could put up.

Brittany and I set off to try to find a source of patient education that would be easily queryable by diagnosis code. By the end of the first day, we were convinced that this didn’t exist, and I decided to build a web service to map ICD9 codes to URLs and friendly titles. It was a great way to contribute, using the stack I was comfortable with.

Adapt: Keep finding ways to contribute, even if they’re different

That night, I created a view in HTML/CSS. Not my strength, but it was a way to take some of the work off of Jason’s plate.

The next day, we found MedlinePlus Connect, which does almost exactly what we were looking for a service to do. But instead of just having Jason change his code to query a totally different API (and there would have been challenges there, plus he was extremely busy building literally everything else), I changed the web service to query and cache information from that API. Meanwhile, Brittany created the first version of our presentation deck.

Toward the end, with Jason coding furiously, Brittany and I put together the presentation and scripted the pitch, and handled the mechanics of submitting our project and our deck.

Results

We finished in 4th place out of 12 submissions (we think.. they just read out scores, so it was hard to keep track). That might not sound like anything to write home about (and I doubt my parents will read this anyway), but considering the preparedness of the other teams and all the pre-work they’d put into their projects, that we didn’t have the opportunity to do, I thought it was a wonderful result!