So I finally participated in my first Hackathon and despite having read accounts of other people’s experiences, it was a whirlwind of emotions that I wasn’t prepared for and has left me exhausted.

First and foremost, I want to give a shoutout to my team: Graeham, Gubing, Yassen, and Keval. Way to hustle. I think my favourite part of this group was that every single person contributed an integral component to the final pitch and without each individual’s contribution we’d have been hooped before the competition began. I’m thrilled to have the opportunity to have worked with all of you.

Secondly, I want to thank the sponsors and mentors available during the weekend. Specifically, the lad from Cambridge Consultants going above and beyond when it came to debugging our hackjob arduino code and the two designers from Havas Lynx who saved our asses from the brink of implosion no fewer than three times.

Thirdly, another shoutout to Cambridge Consultants. I don’t think it’s normal to have the opportunity to work with a rival firm’s engineers in a collaborative capacity but these guys were standup and able to offer key advice when needed. Mad respect for them sacrificing their weekend for this (apparently they get two additional holiday days from it but I’m not sure that that’s suitable compensation for what we put them through…).

Anyways. To the story.

DSC01029

The lovely Breathe Hackathon logo

The Breathe Hackathon was the world’s first three-way global hackathon, held September 19-20 at Imperial College (UK), MIT (USA), and Technion (Israel). It brought together designers, technicians, engineers, patients, physicians and entrepreneurs to investigate solutions to the challenges faced by those with respiratory conditions. We had a weekend (technically we had from 9am-10pm Saturday, and 9am-4pm Sunday, more on this later) to cobble together bits of hardware to address some of the challenges we learned about during the introductory talks.

I know what you’re thinking – “Jeremy, why the hell did you think spending the weekend inside doing the same thing you do for a job was a good idea?” I don’t actually have a direct answer for that. I guess I wanted to play in the same field as I’m employed. As a consultant, we bill the client hourly so there’s next to no time to actually “play” with cool pieces of technology in an exploratory fashion (Because I’m being responsible with your investment). I figured this hackathon would give me the chance to stretch my legs a bit and see more of the world than ISO 14971, bill-by-the-hour environments permit. It didn’t but I’ll explain why later.

Before I launch into my overview of the event, I want to take a moment to expand on the respiratory conditions that the event focused on. The hackathon had two title sponsors, Novartis and the COPD Foundation, so it’s fair to say that it had a heavy COPD focus despite claiming to be open to all respiratory conditions. Usually this would bother me but I really didn’t have an appreciation for the complete mismatch between the severity of COPD and the support available. Funding for COPD research in the UK is next to nothing, yet there are over 25 000 deaths per year as a result of it. Havas Lynx did a great job of humanising the problem by playing a recording of a COPD sufferer struggling to breathe. Sounded just like my grandma, and I’m still haunted by it. Furthermore, there’s compelling evidence to suggest that a large number of COPD sufferers fail to adequately manage their symptoms because they’re ashamed and think they brought it on themselves due to their current or previous smoking habit. I mean, if their COPD was caused by smoking they kind of did but think on that for a second – The biggest contributor to a reduction in smoking rates, social stigma,is now resulting in people failing to seek/receive appropriate care, leading to them becoming socially isolated, depressed, and worsening their condition. That’s fucked up. Even worse, there isn’t really any mechanism for treating the condition, so your lung function erodes at an accelerated rate compared with non-COPD sufferers, to the point that you eventually sound like you’re on the verge of suffocation. Oh and it tends to bring on a whole host of complications, so in the later stages of the disease you’re probably suffering from two or three other conditions as well. And no one is funding research to find mechanisms to help those with the condition…

So after getting fired up by a few presentations outlining the disease-state fundamentals of COPD, there was a Q&A session with an expert panel of researchers, industry professionals, and even a patient advocate (as the panel member with COPD became too ill to attend at the last moment). I could have anticipated how the Q&A went – A bunch of engineery-types immediately asking technical questions that no one but them cared about. I had to do something, so I stuck my hand up and waited patiently until I was called.

“Hi, thanks for being here today” I said. “My question stems from a problem I’m having with grasping the personal side of COPD. I’m wondering if each of you can tell me what you think sucks about COPD?” And from that came some of the most valuable insights (in my biased opinion) from the entire panel. We learned that Physicians are frustrated by their treatment options, the lack of compliance with treatments, the uncertainty surrounding the onset of exacerbations, and even how one lady gets really upset when she can’t answer the phone after walking up three flights of stairs because she’s breathless for 8-10 minutes afterwards. Imagine having an answering machine message that says something like “Hello, I’m sorry I can’t answer the phone right now, I’m probably out of breath. If I don’t suffocate before I catch it again, I’ll do my best to call you back when I’m able to speak.” *BEEEP*

Team CO2 (as the name Cambreathe didn’t manage to stick during the registration process) consisted of myself, three PhD students from Cambridge University (I’m approximating here, as one of them is a baller MD and has ties to UMichigan and MIT but I can’t quite remember the specifics.), and a third year Mechanical Engineering student from Imperial. I was brought into the team through Graeham who I accidentally followed around the world from Calgary and now live just around the corner from in Cambridge (it’s a long story…). First challenge – They were kicking us out of the hackspace at 10pm and we’re all staying in different parts of London while every other team was local. We were going to really have to hustle to make up for not being able to work through the wee hours.

DSC01000

Havas Lynx saving our backsides. Again and again.

Now we aimed to get our idea set in stone pretty quickly so we could deliver a promising solution but I was still struggling with my comprehension of COPD as I hadn’t had a chance to do as much background research as I had wanted (something about a full-time job, travelling to clients, Netflix, more excuses, etc.) and while we all seemed like we were on the same page from preliminary emails, I still wasn’t convinced that anything we wanted to create was worthwhile.

We batted around a few ideas mostly centring on patient compliance, treatment in low resource settings, and spirometry, but the one that fascinated us the most was the idea of being able to predict the onset of exacerbations through regular monitoring of FEV1 (forced expiratory volume in 1 second). An exacerbation is a sudden, acute worsening of COPD symptoms and can result in hospitalization or worse if not handled properly. In theory, an exacerbation could be predicted by detecting a decrease in FEV1 performance, in a manner similar to Peak Flow monitoring for Asthmatics. Literature on the topic was limited as no one has really tried to monitor FEV1 on a more than annual basis due to the challenges associated with getting accurate spirometer readings. I was further motivated by this idea because I was having a further chat with the patient advocate during the hackathon and learned that she had an exacerbation once that was so bad she couldn’t talk to the paramedics to explain her condition and almost received improper treatment. Seriously. You can’t even speak to the people trying to save your life. We HAD to do this.

And so we did. Until it was swatted out of the sky by a physician. You see, we needed to validate our proposal with one of the respiratory clinicians in attendance before we went too far down one path to make sure that we delivered something relevant, and he really didn’t like the idea. It’s tough to interface with clinicians directly, as I find they’re too quick to jump to discussing solutions rather than really fleshing out the problem that’s being explored. It’s even harder to have an objective discussion when you only have one data point (clinician) to test your hypothesis against.

In the consulting world we never go by a singular opinion, and try to gather as many as possible prior to moving forwards with a project. You can save yourself a whole lot of trouble and money if you make sure you design the RIGHT THING from the beginning. Many people get this wrong and it makes me sad because there are tools out there to almost ensure a successful product. They just take time, and that was our most valuable resource at this moment.

So without access to additional Key Opinion Leaders, and insufficient data to rebut his assertion that our idea didn’t have clinical significance, we needed to pivot. After 9 hours of work.

I was super humbled at this point in time. I mean, I do this shit for a job. How hard can a hackathon be? Why are we struggling so much right now? What if I’m actually a pretty shitty engineer and I’ve made it this far in life through dumb luck? Do I have to come back tomorrow? I was having all these thoughts and more, so it was time to switch into crisis mode.

Reassess the situation. Our original idea had some pretty good elements – integration into a toothbrush to ensure regular measurements, consideration for the user’s preferences and capabilities, cloud integration to support telemedicine efforts. We had really just missed the mark clinically. Right. Time to play to our strengths and apparently COPD wasn’t one of them.

Graeham and I both have asthma, so we went back to the idea of Peak Flow monitoring for asthma control since we could draw on our past experiences. See, if you have asthma chances are pretty good that your doctor gave you some kind of peak flow meter and a paper diary to record your readings in, so you can share them next time you visit them. And chances are you probably lost either piece or never took reliable readings because you didn’t see the point and it was a pain in the ass to actually perform the peak flow test. We figured that we could filter out the information from our COPD research that didn’t apply to an asthma user group, and not have to completely scrap the day’s work but we needed to make sure that we didn’t have a localised bias in our user group.

Sure enough, there was a body of compelling data that showed horrendous compliance rates with peak flow monitoring, even in clinical trials where there’s a ton of handholding and patient monitoring. Excellent. We had an idea and a direction and even managed to get buy-in from one of the reviewers despite obvious resistance. Cue the montage music.

DSC01009

Innovation requires at least three packs of sticky notes and the sacrifice of 20 trees.

I don’t quite remember what happened over the next few hours but I think I launched into full “user-centred designer” mode and rallied the team behind an app spec and user needs which we translated into some initial technical requirements. Our Mentors from Havas Lynx were also helping us in our time of need and helped plot some ideas out to see how we could better integrate them into the product. Some of the team started on the ID of the device in an effort to get a “looks-like” model onto the 3D printers before we got kicked out at 10pm, while others started hacking together the arduino interactions for the integrated patient diary and the cloud-based data review system built on IBMs Bluemix platform.

DSC01020

Some ID sketches of the proposed device

We ended up missing the 3D printing deadline and had to leave the building before security got mad at us. End of day 1.

DSC01012

Good night Imperial.

My sister graciously offered me a spot to sleep at her flat, which I figured I could walk to since I had been cooped up inside all day. This is now the second time I’ve been inconvenienced by Hyde Park being locked up at night, so I took the long way home. I remember going to sleep wondering if I should even show up the next day. It seemed like every other team had ideas which were far more fleshed out than ours and we had barely made it through the day without tears. Or maybe I barely made it through the day without tears. I was exhausted. I got a few texts from Graeham shortly after midnight while I lay awake contemplating my doom. If he was still awake, psyched, and working on the cloud platform, I had to rally myself. I couldn’t let this thing beat me.

I woke up before my alarm, showered, and tip-toed out the door the next morning. I figured that if I showed up an hour early, there were pretty good chances that the Hackathon coordinators would already be there and I could snake a 3D printer since most of the prints would finish overnight. Sure enough, I got the print on before the coffee arrived, grabbed a mug and started working on the behavioural aspects of our product.

Day two was different. The atmosphere was different. The smell was different (Showers people, c’mon). But the team was different as well. One by one we all arrived, sanity checked our approach, made sure we knew the deadlines, and started hammering away on the pieces of work we had carved out for ourselves.

DSC01024

The “Looks Like” Cambreathe Peak Flow Monitor

Again, time went by in a flash but the folks from Havas Lynx again came to make sure we were surviving (have I given them enough love yet?), in addition to the previously mentioned electronics engineer from Cambridge Consultants helping debug our arduino code, going above and beyond what was required.

Before I knew it, we were working on the 4 minute (!!!!) pitch deck while praying that the previously working arduino model could be fixed prior to the “wizard of oz” portion of our presentation.

I hadn’t really anticipated going through Tuckman’s stages of group development in a single weekend but at this point in time I’m pretty sure someone could write a case study on our team. Just replace the storming with utter misery at (almost) wasting a day on a failed concept.

Our USP was that we developed our concept from the ground up with the user in mind, and this is really where the title of this article came from. If you’ve read my blog before you’ll know that I’m a big fan of front-end user research, so I made sure to hammer this home in the pitch. We didn’t start with costs or facts, we just started with one of our asthmatic group members telling his story about struggling to use his peak flow meter and how his struggles weren’t unique. No existing product really addressed how to integrate itself into the user’s lifestyle, increasing the number of triggers to take a measurement, while decreasing the hassle of recording the information, making it easier to comply with the trigger. We based this on BJ Fogg’s behavioural model, which was fairly well received by the experts we asked, and kept the user at the centre of every design decision we made.

When it came to pitch, we didn’t talk about patients and dollars. We talked about people and their problems. I think if we’re truly going to make a difference in the world we need to stop ignoring the “softer” side of problems, particularly as engineers. Human Factors isn’t pesky. The user isn’t stupid (well, this one is debatable). Your design sucks and you can do better. Humanize the problem you’re trying to solve and I’m pretty sure you’re going to come up with an ultimately more appropriate design.

Unfortunately, not many other groups grasped this idea and approached the weekend with a clinical coldness/detachment that engineers and physicists are stereotypically associated with. However, every single team we lost to completely embodied the emotional component of the problem and I couldn’t have been happier to lose to them.

While our pitch went over brilliantly, we (I…) made a few mistakes and missed a few key points in the presentation that would have put us on the podium. We ended up taking home the IBM sponsor prize of an expenses-paid trip to their IOT/cloud computing facility (they have a pub, amazing) for the most innovative use of their Bluemix platform, and were told several anecdotes of how we delayed the judging process because they were busy arguing about the commercial potential of our innovation.

Our amazing team, with Havas Lynx mentor on the side!

Our amazing team, with Havas Lynx mentor on the side!

So an unofficial 4th place at my first hackathon, paid trip to IBM’s pub (and the rest of their facility, I guess), and the knowledge that with the right team one can spin up a commercially viable product in a weekend. Not too shabby. Maybe I’m an alright engineer. Maybe I had a great team.

Mad props to the winning team (whose names I forget) for creating a game that simulates COPD breathlessness that can be brought to schools to raise awareness of the disease while targeting at-risk youth. Additional props to the third(?) place team for creating a mail-out advertising campaign to aid in the early diagnosis of COPD.

My apologies in advance for all the events and people and sponsors and mentors I’ve forgotten to mention. That whole weekend is a memorable blur.

But to answer the lingering question of why I feel like I didn’t get as much out of the weekend as I wanted, I think it’s because of a few different factors:

  • I’m competitive, there were prizes, and the atmosphere in the hackspace encouraged this mindset. In doing so, I didn’t get to unplug and play, instead I leveraged my strengths.
  • Limited prototyping equipment. I’m not high maintenance (ok, maybe a bit) but there was a really limited supply of raw materials. Combine that with industry representatives on hand to help you integrate their equipment/software, I’m left wondering if creativity is encouraged from the support of these resources or hampered by implying that my innovation needs to take advantage of them.
  • A lot of teams focused on spirometry. Building on my previous point, I can’t help but think that there was a subconscious bias introduced somewhere to make a majority of people focus in on a single aspect of the whole COPD picture.

Having not been to another hackathon, I can’t speak to the structure imposed by this one or how a lack of structure may influence things.

As for the future of the Cambreathe peak flow monitor, lets just say that we need to spend a bit more time on front end research first. And sleep.