How to make a great hack day pitch

We’ve been running Hack Days for quite a while now. NHS Hack Day has seen thousands of enthusiastic volunteers through our doors, and hundreds of project pitches.

One of the questions that we get asked a lot, particularly by people who are new to hack days is

What makes a good pitch at a hack day?

… so we thought we’d share a few tips for people coming to hack days on how to make a great hack day pitch

1. Tell a story

People love stories. Pitches with a story in them almost always go down better. So give it colour - explain how your life is broken because of this problem, explain the frustrations of a life without the thing you’re pitching.

Particularly when the person who would benefit is some kind of specialist, most of the people listening to the pitch won’t understand what what life is like for the people that your pitch is about. So help them empathise by telling a story about their experiences.

2. Explain the change you want to see

Hack day projects that capture the imagination are mostly the ones with the potential to make a real impact in the world. That means that when you’re pitching, you should make sure to explain just how the world will be better once you’ve made your project.

Sometimes that’s a bold vision of the future that brings about the end of global capitalism, injustice, hunger, and human suffering generally. More often, it’s a story about how you can help lots of people in a small but meaningful way.

3. Make it achievable

While we’re on the subject of your grand vision for changing the entire world, it’s important to keep in mind that the hack day you’re at probably only lasts a day or two. Once you’ve taken out time for pitches, presentations and lunch, the time you have available for building things is limited.

Because of that, pitches that seem to be too wildly ambitious can be greeted with scepticism - a sense that they’re simply unachievable in the time available. Thankfully, just like the journey of a thousand miles, huge projects can always be broken down into a sequence of smaller ones.

If your idea seems huge and overwhelming, you should still talk about it - because it probably scores big on the “have an impact” scale we were just talking about. But you should also make sure to break off an achievable chunk of it, and explain that this is what you want to build today.

4. Make it clear

You’re only going to have a very short time for your pitch. Probably no more than a couple minutes.

Keep it snappy.

(Note, this section has been heavily edited down in the name of brevity and minimal irony.)

5. Problem first, not solution backwards

The most powerful hack day experiences come from ideas that are genuinely co-created, in response to problems or needs that actually exist in the real world. (Hence starting with the story/impact).

A common pitfall of hack day pitches is to skip right over the process of actually problem solving, and start pitching the detailed solution that first occurred to the person doing the pitching. Unsurprisingly this tends not to excite the creative problem-solvers in the room. (Hint: those are exactly the people you want to be working with )

The two particularly common cases of this are “Let me tell you the specific screens my app will have” and “I have this library/Raspberry Pi/Google Glass… please make it relevant to someone.”

6. Practice

Just like most things in life, pitching is something you can get better at with practice! Luckily, when you arrive at a hack day, you are often sat around in a big room with a bunch of other people who you don’t know, just waiting for something to happen.

Why not say hello to one of them who you don’t know, and ask if you can practice your pitch? Ask for feedback - what did they like about it? Was there anything that wasn’t clear? It’s a good way to make friends in the inevitable down time at the start of the day, and you’ll end up with a better pitch.

For NHS Hack Day, we organise meetups before the event, and invite attendees to come and meet one another. We make sure that we have some hack day veterans on hand, and we give friendly constructive feedback to anyone with a project they want to pitch. We also encourage people to post their ideas to our mailing list.

7. Try to find some collaborators beforehand

We’ve found that as well as helping to polish ideas, sharing your pitch on the mailing list beforehand can result in teams that start to form before the day. It gives potential collaborators a chance to mull the project over in the weeks and days running up to the event, and come with more fully formed ideas.

These teams often work really well together. They come prepared and already excited, and when the time comes to start working, they often have the most structure, and the clearest understanding of what needs to happen. The process of discussing your idea with them will give you a better idea of what excites people about it and make your pitch better.

8. Don’t make it exploitative

Hack days are often attended by volunteers in their free time. They’re a great space for creative collaboration, idea generation, skill sharing, and building communities.

They are not free labour for your startup/church fête/government department.

Ask yourself if this is something that might be interpreted as asking someone to just do free work. If you think it is, consider paying someone to do it instead of pitching at a hack day. If you’re not sure, have a chat with one of the organisers - they’ll normally be happy to give you a steer about what’s appropriate at their particular event.

9. You don’t need a mobile app

Apps. They’re great. But… you almost certainly don’t need one. Pitching “An iPhone app” is a special case of “Don’t come with a solution” from above. But this one comes up a lot.

The percentage of problems to which the best answer is a native phone app is so close to zero as to be indistinguishable. Starting with the problem will make your project better.

Related, you might like to read this blog post from some nice people at the government about why you don’t need an App. Even if you’re not the government, most of that probably still applies.

10. Bonus points if you avoid Hack Day Bingo.

There are some kinds of things that come up quite a lot at hack days. They’re perfectly excellent hack day projects. They tend to be the kind of thing that works well in an environment where you’re trying to ship something in a limited time.

That said, primates are suckers for novelty, so you’re likely to score bonus points with the room (particularly the grizzled hack day veterans) if you come up with something that’s a little bit new. Examples of things that have probably been done at least once before are:

  • Something that hits the Twillio API and phones the judges
  • Taking some data and plotting points on a Google Map
  • Tinder for dogs/asteroids/_____
  • Top Trumps for verses of the bible/DNA/______

(Note: Particular thanks to Alex and Lilly for their additions to this list.)

Enough listing already

So, now you know how to pitch, come join us at the next NHS Hack Day and try it out.

Photo credits: Paul Clarke

Read more

How we’re helping respond to the Zika outbreak

The last few months have seen an explosive spread of the Zika virus, which has been potentially linked to thousands of birth defects in Latin America. The Zika virus is a mosquito-transmitted infection that was previously sporadically reported in Africa and the Pacific, but has recently started spreading rapidly in South America. Patients usually have a mild flu-like illness consisting of a low fever, headache, muscle and joint pain, red eyes and rash.

In the UK, many patients who exhibit symptoms related to Zika and have recently travelled are referred to the specialist Hospital for Tropical Diseases in London, which has resulted in a large increase in their workload.

The Hospital for Tropical Diseases uses our elCID software to manage their clinical workflow, so as soon as we heard this, we tried to understand what we could do to help. At Open Health Care we believe the digital tools clinicians use to do their jobs need to be iterated and improved on a frequent basis. That means we deliver services that are flexible enough to adapt to changing clinical needs, and we’re on hand to help make those improvements.

Working closely with clinicians from HTD, we quickly developed a prototype Zika “pathway”. This enables users to record extra information of particular importance to patients they were treating for Zika, as well as extra quick ways to enter the very specific set of tests that are most relevant to such patients.

Because we have an electronic clinical pathway specific to the particular condition being treated, we were able to provide lots of contextually relevant information and notes for its treatment. This guidance was written by the local consultants, and helps to make sure that every patient is given the very best care possible.

All the information about patients that gets entered on elCID is stored as high quality structured data. That means that we are also able to generate a summary of their interaction with the patient at the click of a button, complete with symptoms, travel history, investigations and results, and the specific extra Zika information we are now recording.

Documenting clinical activity in this way - on digital tools that understand the clinical domain - means that it is also available subsequently for audit and analysis purposes. Extracting data on the management of Zika patients at the hospital is now something that can be done in a few clicks, rather than requiring a laborious manual review of clinical documentation.

In many ways this is one of the real opportunities of the NHS’ move to paperless working - when you move to using tools that allow you to analyse and learn from data generated by routine clinical work. We look forward to finding out what the team learn about their response to the Zika outbreak.

Crucially, this new module involved just a couple of days prototyping, iterating and testing the new Zika pathway, before deploying to the live system. Over the next few weeks we’ll be checking back regularly to gather feedback from the users of the service so that we can be sure that we’re meeting their needs.

Updating the systems that underpin the delivery of care should be this simple all the time - they should be designed with flexibility and iteration in mind, and be supported by teams who have the capability to iterate them responsively.

If you’d like to know more about how we could help you by delivering services like this, or more about the services we offer, do get in touch with us at hello@openhealthcare.org.uk.

Photo credits: John Tan

Read more

2015 - Annual review

2015 was a big year for us - so we thought we’d take a moment and share some of what we’ve been up to:

Delivering Digital Services for direct care

We believe that the digital tools used to deliver patient care should be of the highest possible quality. Not only do we believe it, we work hard to deliver them as well!

Last year we launched two new services - for managing OPAT care at UCLH (patients who need regular IV drugs but aren’t so sick that they need to stay in hospital all the time), and for the returning traveller walk in clinic at the Hospital for Tropical Diseases.

We’ve also been working to iteratively improve the services we run - conducting user research interviews, observing clinicians using our tools on the wards, and generally trying to establish robust feedback loops and processes for users to tell us how we can make things better for them.

Based on this research, we’ve made lots of improvements to the UI of our services, coming up with new design patterns for building applications for direct care in the process.

Code

Lots of this work invovles us writing, maintaining and improving code.

During 2014 We made 3 major new releases of OPAL - our framework for building digital services for clnicians, not to mention many other smaller releases, making up 2,416 individual commits across all our Open Source projects.

Throughout the year we’ve been focussing on making our projects easier for new developers to pick up - improving the documentation and refactoring things to provide better APIs for people to build on.

Hackdays

2015 was as busy as ever for NHS Hack Day, with three events bringing together hundreds of clinicians, academics, designers, developers, and patients to help make the NHS just a little better.

We kicked off the year with another trip to Cardiff, before coming back to London in May, and then heading up to Manchester in the Autumn.

UK Health Camp

2015 also saw the first UK Health Camp - a community unconference for people interested in digital and data in health and care. We were proud to sponsor the event, and glad to have a community space to discuss the pressing issues of digital transformation within the NHS.

We’re already looking forward to next year, and have started plotting how to make it even more of a success with the rest of the team!

The Future

Looking forward to to this year, we’re excited to be working on lots of new projects, with new partners, as well as continuing to develop and improve our existing services.

If you’ve got a project you think we could help with this year, do drop us a line at hello@openhealthcare.org.uk - we’d love to hear all about it!

Photo credits: Paul Clarke

Read more

OPAL 0.5 released

We’re happy to announce that we’ve just released a new version of OPAL - our framework for building clinical facing digital services.

So - what’s new in this release?

Search

We’ve completely re-designed our search pages to help clinicians find the patients they’re interested in more easily. We also default to having a search box in the navigation of every page.

In addition, we’ve been working hard to make search backends pluggable, so that in the future you’ll be able to drop in alternative backends of your choice as your application scales.

Patient List view

We spent a lot of time over the past few months collating feedback from users and doing research to understand how we could improve the core Patient List views. As a response to that we’ve updated the list interface - making it clearer which patient is currently active, and removing some of the features that weren’t actually helping our users to care for patients.

Subrecord metadata

We added four new utility fields to Patient and Episode subrecords - created_by, updated_by, created, updated. This gives developers easier programatic access to high level audit trail information, without having to navigate the low level Django Reversion API - which is still there for when you need more detailed audit trail information.

Select2 and List fields

This release introduces Select2 to OPAL - which provides us some nicer widgets - particularly for fields associated with lookuplists, and has also enabled the development of list types as Subrecord fields. For example this means that your travel can be to a list of countries when you take a backpacking trip through Southeast Asia!

What’s Next?

Just because this release is out, we’re not resting on our laurels - in fact we’re already gearing up for the next releases. We’re planning to look at the information architecture of Episode detail views, including a new Notes view that’s currently being tested by some users of the elCID project.

We also plan to refactor some of the core data models back into OPAL to provide them there by default rather than implemented over and over again in individual applications.

As ever, because OPAL is an Open Governance Open Source project, you can follow our progress over on our public Waffle board where we’ll be organising our work.

More about OPAL

If you want to find out more about OPAL or how Open Health Care can help you to run high quality digital services for doctors in your institution then do get in touch!

Read more

Launching a new Clinical Digital Service for returning travellers

Just a couple of weeks ago we launched a new service at the Hospital for Tropical Diseases in London to help the doctors and nurses who run their Emergency Walk-In Clinic. At the clinic, travellers who have returned from the tropics and are acutely unwell turn up without requiring an appointment to get treated by specialists in tropical diseases. The service tracks patients on their journey through the clinic, from initial triage to following up on lab results that arrive after they’ve left.

We worked closely with the staff who run the clinic, making sure that we met the different needs of different types of user - in this case admin staff, the nursing staff, doctors, as well as the service managers who wanted data on what activity was happening. Just like we do with all of our services, we brought them into our agile development process as we iteratively developed the service based on research and their feedback.

Clinical digital services too often fail to take into account the experiences of the people on the ground who have to use them in practice. At Open Health Care we don’t think that’s acceptable for something as important as delivering health care.

Because of that we will continue to regularly meet with users of the service to conduct usability testing and actively seek feedback so that we can continuously improve the service. That feedback loop needs to be a part of the ongoing operation of digital products and services in hospitals - not just something that happens as part of an initial design phase - and we’ve seen before just how useful it can be as we’ve been able to respond to changing user needs and changes to the context and processes that surround users experiences of our services.

Use data to design services.
It makes things better

One of the key goals of the project was to allow the team at HTD to gather high quality data about the cohort of patients that they treat. This data is hugely valuable, both academically for research purposes, and because it enables the team to understand their workload.

When the tools that are used for routine day-to-day clinical care don’t collect usable data, the cost of analysing what you’ve been doing become huge. With the new Walk-in service however, all of the information that the institution knows about a patient, from demographics to observations, travel history to treatment, gets stored as high quality structured data.

That means that anyone can get an accurate answer to a question like “How many patients did we see with Dengue fever in the last year” in seconds, rather than it taking hours or days of painstaking work reviewing case notes, or manually curating and maintaining their own databases.

We’re excited about the possibilities for service redesign and research that this new capability has opened up for the team, and we’ve already been brainstorming ideas - so watch this space!

How it all came together

The service was built as a plugin for OPAL - our open source framework for building high quality digital services in a clinical setting, and is deployed as part of elCID - an existing service that we run for UCLH to manage patients with infection.

We love delivering high quality digital services for doctors. If you’d like to explore how we might be able to help you out at your institution, get in touch - we’re always keen to meet people with interesting problems to solve as we try and make sure that the digital services that clinical staff in the NHS use in their day jobs is as good as the services they use in their personal lives.

Read more

More Posts:

Talk to us.

Something you think we could help with?
We’d love to hear from you.

Get in touch