This next NHS Hack Day in London will be our 13th. We’ve been to London, Cardiff, Leeds, Liverpool, Manchester and Oxford, we’ve seen thousands of people come through the doors to collaborate on projects to help make the NHS just a little better.

Throughout that time, we’ve been approached by a number of projects and institutions who have wanted to come to NHS Hack Day, and pitch their particular programme, platform, car boot sale, et cetera. Or perhaps to ask us to steer the projects on the day down one particular technical route. We’ve always politely turned those offers down. Mostly not because we think that the people approaching us aren’t coming with great projects, but because we think it’s important that NHS Hack Day remains a neutral space that concentrates on making connections and the experience of the people who show up. It’s for the same reason that we don’t let sponsors of NHS Hack Day do product pitches on the day.

Because we get asked about it so often, we thought we’d explain why we do this.

Stepping back from just NHS Hack Day for a second, the real reason that I, and Open Health Care are doing work in this space, is that we’re incredibly excited about the opportunity for digital tools to transform the delivery of health care and deliver better outcomes for patients and society generally.

We can do that by providing tools that help people on the front lines to care for patients, and by leveraging high quality data about the way we work. That said, we can’t just build tools and expect the world to change. The tools are useless without adoption - and adoption requires a change in the way people think about digital, in the way they understand it, and the expectations it has. And often, the hard work of winning hearts and minds includes advocacy for specific tools, standards and platforms.

Open Health Care, and NHS Hack Day come right out of the wider Open Movement. That means that we are totally bought into having high quality open standards, and the role that they can play in making people’s lives better. But much like for instance, open data - we’re not particularly excited about them in the abstract. They’re a means not an end in and of themselves.

That means that while for instance, “promoting standards for interoperability” is something that we care deeply about, our main focus is always on delivering services that meet people’s needs in the messy, complicated real world.

In the context of NHS Hack Day, that means that our strategic goals tend to be on building communities of people who are excited about the practical power of digital transformation. About showcasing user centred design and lifting the lid on the applied process of iteratively making inclusive software that doesn’t suck.

We also introduce people whenever it’s appropriate, to Open All The Things. That means Source, Governance, Data, Science, APIs, Policy and Standards - because they’re all crucial tools. But that’s not the main reason we’re here, and it’s not the real value we bring.

Particularly in the context of a Hack Day, we tend not to institutionally advocate particular tools, standards, licences et cetera. It’s a time-pressured environment, and people want to use tools they know to build a thing rather than tools with better philosophical justifications to almost build a thing!

(That said - if your tool/standard/platform/et cetera is good enough and useful enough, then people will vote with their keyboards and use it anyway because it makes their lives easier.)

We don’t expect people to come out of a NHS Hack Day project and immediately give up their day jobs to start companies. What we do expect is to forge connections between the Open Movement, and the digital world, with people who live at the sharp end of health and care in the NHS. We expect to show people a glimpse of a world in which digital transforms their lives for the better, quickly and humanely.

Sometimes, projects that come out of NHS Hack Day have precisely the right mix of participants with spare time and looking for a challenge, and they really do want to take their projects forwards. We’re always delighted when that happens - and we provide support and advice to those teams wherever we can. That includes introducing them to support and funding programmes, as well as offering practical advice, and sometimes logistical support. We’re not optimising for generating health tech startups though. We’re optimising for building a genuinely sustainable movement of people within the system to demand an NHS that is fit for purpose in the digital age.

If that sounds like something you’d like to experience yourself, you still have time to sign up for NHS Hack Day 13 - which is rapidly approaching, and will happen in London on the 14th and 15th of May 2016.

Photo credits: Cléon Daniel

Read more

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

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 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.

From the wards yesterday: "You're actually coming and asking doctors how you can make the IT systems they use better? - That's unheard of"

— David Miller (@thatdavidmiller) September 11, 2015

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

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