A few weeks ago we were excited as NHS Hack Day visited Newcastle for the very first time.

As ever, we brought clinicians, patients, and other NHS staff together with developers, designers, researchers and others to share experiences, and spend a weekend working on short projects that address some of the frustrations and problems faced by patients and NHS staff every day.

After an initial session pitching potential project ideas to the group, the attendees gradually formed into teams and started work, exploring the spaces around the problems they’d chosen to work on, making new friends, and examining potential ways to address them.

You can see all of the teams that formed on the event page of the NHS Hack Day website, but a special mention here goes to a couple of our favourites:

Recording consent preferences

The “North Share” team spent much of the weekend exploring the thorny issues around consent, privacy and data sharing in the context of the NHS. Recent experience with a range of national and local projects suggests that there is plenty of work do be done in this area, and contributions in the form of tangible prototypes that help people to tell stories about and think through the issues involved are particularly helpful.

You can take the prototype they made for a spin yourself and see what you think - try asking questions like:

• do I understand what this means?
• what do I think this should do?
• what the consequences would be?
• how would I change this to make it better?

Managing consent, and doing the right thing around privacy and personal data is something we spend lots of time thinking about at Open Health Care, so it was great to see others in the community engaging with the issues in such a constructive, positive way.

Locating Community Dentistry

Highlighted on the NHS Hack Day mailing list beforehand was how hard it is for people with complex needs to locate appropriate community dental services via the NHS Choices website. (You’re likely to be able to find a general dental surgery, but no information about specialist services for people with complex medical comorbidities, physical disabilities, dementia etc)

Not for the first time, we find a situation where a lack of available complete, canonical data about the Physical NHS (the services on the ground across the country) makes it harder than is acceptable for patients to get the care they need.

At the event the team built a prototype of a service that would help people locate dental services appropriate for their situation.

This prototype allows the team to tell the story of how the world should work for people trying to access dental services even though the data is unavailable (in fact, doesn’t exist).

One of the really interesting classes of hack day projects is the ones that go on to become campaigns on a particular topic - which is exactly what caught the eye with this one. This information is really something that should be rolled into the services developed by NHS Digital like NHS Choices, or the up-coming NHS.UK.

Having a (semi) working service to show people makes it much easier to tell the story of why this should exist, and helps to lobby the institutions who should be providing this data.

We’re sure this story isn’t over here and look forward to the time when these services are easy to locate.

Thanks and the future

Thanks to everyone who turned up over the weekend and helped to make it such a welcoming, friendly event. Particular thanks to the volunteers who helped make things run smoothly, and the sponsors without whom we wouldn’t be able to carry on running these events.

A particularly large thanks goes to Becky for leading the organization and cat-herding this time, and doing by far the lion’s share of dealing with suppliers, venue and sponsors.

If you want to come to a future NHS Hack Day then you can follow us on Twitter, or sign up to our mailing list and we’ll let you know as soon as we schedule the next one - likely early in 2017.

One of the great things about working in health is that there are no shortage of exciting, and potentially impactful problems to work on. At Open Health Care, we spend a lot of our time working to ease a couple of the big headaches around usability and data that the current state of health care technology gives clinicians.

Usability

First is the usability problem.

We’re hardly the first people to suggest that many, if not most of the digital tools that are provided for doctors, nurses and other key front line NHS staff struggle with usability. By default these tools tend to be overwhelming and unfriendly. They are hard to use, and at times downright dangerous.

At Open Health Care we believe that medicine is important enough to deserve the very best in terms of high quality usable software. In an environment where the costs of making mistakes is so high, clinicians deserve tools that help rather than hinder.

The great thing is that technologists understand how to make tools that are highly functional and even delight their users. It requires time, focus and a willingness to change the way things are done - but the design and development techniques are increasingly widespread and available to us.

There is no reason why we can’t do this for medicine - and indeed, the biggest part of what we do as Open Health Care is delivering that.

In the UK, our reality is that we are looking to streamline and improve the efficiency of our clinical services in the name of yes, better care but also saving the NHS money. Having usable digital tools that genuinely support the day to day work of those services with the capability to be frequently iterated will be a key plank of any successful transformation strategy as we look to re-design those services.

Data

The second big area that gets us excited is clinical data.

If we get sick, then the people and institutions who care for us know a huge amount about us. But that information is rarely available as data. It’s either literally on paper notes, or it’s in electronic systems that may as well be paper - stored in closed systems in unstructured formats that we can’t subsequently analyse or do computations over.

The opportunity cost of throwing away this information is huge. The truly revolutionary technologies and techniques that the digital age has provided us are fuelled by data. Those techniques work best when you can feed them with structured, high quality, granular data. Yet even at many world-renowned institutions in the NHS, the data infrastructure underpinning clinical activity is distinctly 20th century.

Access to high quality clinical data by default has a transformative potential for the NHS. Improving patient care and optimising our clinical services requires a real understanding of what we’re doing now - and that can only be obtained with data. Without that data, we have no idea whether we’re even making things better.

And that’s before we even start with the promise of driving research and science by providing them with easily accessible, high quality, computable clinical data.

How do we help?

What we’ve found at Open Health Care, is that when you get the usability right for the end user - the person caring for a patient, you can improve the efficiency and safety of patient care, while also capturing high granularity, research quality data as a part of routine clinical care.

This is one of the reasons we created OPAL - our Open Source platform for building clinical software applications. It pulls together the results of years of usability testing with real clinicians, along with all of the hard thinking that we and others like us have done about how to build robust digital tools for a health care environment.

Also built in to OPAL is the ability and the data modelling to collect the granularity of data required to enable us to provide high quality data through extracts or Open APIs. We’ve explored how to balance the clinical user need of speed ease of use with the system needs of quality data capture. Through a combination of pragmatic design, and frequent iteration, we’ve arrived at a range of design patterns that give us the opportunity to design systems that work in the real world yet still enable subsequent analysis.

For instance, we’ve built elCID - the first major application built using OPAL. It’s designed to help manage the care of patients with infections, and it has been in use at University College Hospital London for the last two and a half years in the inpatient and outpatient services they run for patients with infections. It is used by clinicians day to day to manage the care of patients, integrating with other hospital systems to pull key data from elsewhere in the trust, and it supports both clinical audit and service development.

During that time it has improved the efficiency of clinical practice - saving time every single day by reducing work required in the handover process for inpatient teams, and reducing significantly, the time required by Microbiology consultants to run their liaison service to other parts of the trust - while providing robust documentation of that process for the first time.

It has supported the development of the OPAT service - freeing up beds by allowing patients requiring IV antibiotics to be treated as outpatients, saving the trust £1m per year. It also allows us to provide clinic managers realtime dashboards and management reports about their activity, enabling them to make decisions with data that was previously unavailable to them.

In addition to this, data from the system has supported many clinical audits - making the process of collecting data to analyse significantly faster, as well as one published academic paper, two more in peer review, and six conference abstracts.

How does it work?

Open Health Care provide digital tools to NHS institutions that help clinicians to deliver better care. We charge for support, customisation and integration work, but we don’t charge for a license fee - all of our software is Open Source.

We provide either installations of existing products we have developed, or build bespoke solutions for the needs of the individual organization we’re working with.

If you are interested in fining out how to get elCID at your organization, or have a project that involves clinical usability and data then do drop us a line - we’d love to hear from you.

Last Saturday 28th May 2016 marked the third birthday of OPAL - the Open Source framework we created to help developers create high quality clinical applications. We’ve come a long way since the very first commit back in 2013 so to celebrate we thought now would be a great time to take a look back over everything we’ve achieved.

Early days

For the first few months the lead developer on OPAL was the awesome Peter Inglesby, who made that very first commit, and worked with Drs Pollara, Marks and Noursadeghi to craft a Patient List system for infection patients at UCH. We met each week in the old Library room at HTD for a show and tell and figured out what the next sprint would look like.

The interface changed almost weekly back then as we tried to figure out how best to replace the menagerie of Word documents, T-Cards, Access databases and Excel spreadsheets that the teams were currently using as patient lists. As you can see below, even three years on, the Patient List components of OPAL are still recognisable from those first few months!

Making OPAL a Framework not an Application

Even at the beginning we knew that we wanted OPAL to be more of a framework than an application. By October 2013 we started moving the UCH specific elements out of OPAL, refactoring it for reuse. We set about moving application specific business logic into elCID (the first OPAL application), allowing OPAL to be the generic platform for the services we build.

OPAL would provide a sensible robust default configuration along with a core data model, reusable common components, UI components, and a clear path for integration with other systems and standards. Meanwhile individual applications built with OPAL would provide specialised domain logic for particular tasks, clinical specialties, or customisation for individual installations.

Deployment to an actual NHS Hospital

In January 2014 we were ready to deploy elCID to a real NHS hospital - just eight months after starting the project. Since then it has been used to manage inpatients and outpatients for HTD and the Infection and Microbiology teams at UCLH.

Digital services are never finished though - and we’ve iterated and improved both elCID and OPAL frequently. OPAL alone has racked up 19 releases and almost 2,500 commits since we began. During that time we’ve worked to turn our vision for a robust Open Source framework for building clinical web applications into a reality.

Taking OPAL to NHS Hack Days

One of the big tests for how far along that path we are is how OPAL has performed as a tool for building projects at NHS Hack Days. Hack days are a great way to stress test developer tools. They reward well-thought-out APIs and good documentation, giving you a great insight into how much they help or hinder developers.

The first OPAL project at a NHS Hack Day was back in May 2014 when Dr Gabriele Pollara brought a team together to try and add some extra features to OPAL and elCID. Even though the changes from their fork of OPAL were never merged back into the main codebase, it gave us plenty of insight into where we had the coupling wrong between framework and application, and places where could improve the APIs or make the documentation clearer.

Four months later when the 8th NHS Hack day rolled around in Leeds the codebase had improved significantly - with a project to design a handover tool for Renal teams coming joint first:

Renal project team collect T shirts for coming joint first at #nhshd pic.twitter.com/D6EUkAUDdg

— Alison Cameron (@allyc375) September 28, 2014

This was the first time we had built a brand new application from scratch using OPAL, and it gave us a clear head start over hackday projects that had had to start from nothing.

Over the next year, projects like eCDR and travelalerts were a great benchmark of how OPAL was progressing. New developers were able to get to grips with it and start building on top of it over the course of just a weekend. The framework was obviously maturing.

In the most recent London NHS Hack Day we saw two projects building on top of OPAL - A digital anaesthetic chart that pulls and displays observation data from a anaesthetic monitors, and the eventual winner - a Raspberry Pi based EPR in a box.

It was particularly exciting to see two brand new - and completely re-skinned OPAL projects built over one weekend and to get lots of feedback from all of our friends in the NHS Hack Day community.

The last few months

The last few months have seen OPAL leap forward in terms of code quality and depth of features. In large part this is thanks to the hard work of Fred Kingham - who has taken over as lead developer for the project. The upcoming 0.6 release will see many improvements. We’ve refactored form helpers to make it easy to embed forms. Added new Patient detail views and a new Patient List module to make OPAL even more customisable. We’ve also added in an integration layer for connecting to other hospital systems. All this coupled with even greater performance.

We’re not done yet though! We’re looking forward to improving the documentation to make it easier for new developers, we’re updating our core clinical models, improving the way in which we guide users through complex clinical pathways, adding further UI improvements for mobile devices along with much more as we move towards a 1.0 release.

If you want to know more about OPAL, or about the work that we do at Open Health Care building digital tools for clinicians, drop us a line - we’d love to hear from you.

Photo credits: Will Clayton

This weekend saw the thirteenth NHS Hack Day, this time held in London at KCL. At NHS Hack Day, technologists, medics, patients, and anyone else with enthusiasm and curiosity come together for a weekend to build prototypes of things that can make the NHS run just a little better. Most often these are digital tools that solve problems that staff or patients encounter in their lives.

Early on the Saturday morning we saw a huge range of ideas pitched - looking for better ways to understand and visualise information, improved systems to manage processes in health and care, and explorative projects trying to look for untapped opportunities afforded by new technologies.

One of the interesting dynamics of NHS Hack Day is the fact that most of the projects involve real collaborations between domain experts (e.g. Doctors) and digital experts who have to find a way to communicate and work together. At Open Health Care we believe that diverse multidisciplinary teams are better teams - and NHS Hack Day continues to showcase what can be achieved by small groups of passionate people given a space to collaborate and experiment.

On the Sunday afternoon, we gathered around to see what everyone had achieved over the weekend - you can see details of the fourteen teams here, or watch the whole thing (warning - it’s about an hour long). Some of our favourites are here:

The Daily Pollute

The brilliantly named Daily Pollute pulled together live sensor data about air quality in London (via the London Air API ) with location data from your mobile phone - their initial prototype giving you information about pollution levels on your regular routes.

Digital Anaesthetic Chart

Anaesthetists agree that the way they are recording information about patients under their care needs to change.

At the moment that often consists of taking numbers from a machine, and writing them by hand onto a piece of paper. The team (involving OHC’s own @fredkingham) automated the process of extracting numbers from the machine - reducing errors and increasing the number of readings you can take, as well as creating a new UX for displaying the information in line with the new AAGBI guidance for anaesthetic charts.

The potential benefits in terms of efficiency and error reduction here are huge - this is one of the many routine practices in the NHS that can be made dramatically safer, quicker and cheaper with high quality digital tools. In 2016 we shouldn’t have humans copying numbers off of a computer screen onto a paper chart.

Outbreak

The outbreak team designed a health record system in a box, optimised for resource strapped (no network, no power, little infrastructure) environments. With a single crate containing a Raspberry Pi server, Android Tablets for users, and a Patient management system, optimised for emergency responses, and ruggedised against failure in a situation where IT support could be hundreds of miles away.

The Outbreak team (including yours truly @thatdavidmiller) were crowned the eventual winners of NHS Hack Day 13, and are excited to find partners who can help take the project forwards.

Thanks & Looking Forwards

This was the second time that NHS Hack Day London has been organised by the amazing @DeckOfPandas, and we’d like to thank her again for all the hard work in the months beforehand and over the weekend in making sure that the event went brilliantly.

NHS Hack Day will be back in another four months in Newcastle, tickets will be released shortly - follow us on twitter and sign up to the mailing list to find out when they’re out - we hope to see you there!

Photo credits: Paul Clarke Photography

In the last couple weeks, many thousands of words have been written about a small piece of open source code called left-pad which was suddenly un-published by its author. (If you’re not up to speed on this, then you might like to read a narrative overview, or some interesting analysis.)

Perfectly understandably, this has caused lots of people to re-consider the risks of building on open source, and how the actions of unaccountable external developers halfway around the world could have an effect on how your software operates.

When we work with digital tools for health, risk can be particularly profound. The failure mode of a digital service that supports clinicians delivering direct care is the risk of IT failures causing harm to patients, not just a website being unavailable for a while. This means that we need to make sure that our attitude to risk is appropriate to the harm that failures can cause.

Thankfully, there are plenty of people using open source, and lots of them using it for mission critical applications that have exacting uptime expectations. That means that the path to processes and tools to mitigate these risks is well trodden, and we can learn from the wealth of cultural knowledge in the open source movement.

Taking a straw poll of the table I’m sat at, there are people who’ve written code using open source for investment banks, power stations, government departments, and yes, NHS hospitals.

The story of how all those places avoid their production systems being broken by code that has been altered by unknown open source developers is basically identical.

Software Dependencies at Open Health Care

A dependency is a broad software engineering term used to explain the relationship when a piece of software relies on another one. When programmers install and run software from other sources, they will most often use a package manager - software that automates the process of installing and upgrading code.

Before we install a new package or module of open source code, we carefully evaluate it. We look at the code, we look at its user base, we look at how actively maintained it is by the open source community and we look at the risk that it presents to the rest of our code base. The decision has to be signed off by at least two people in our development team, and it’s not one we take lightly. (Explaining how this review and evaluation process works in detail is probably a whole post in itself.)

Once we’ve taken that decision, we have to update our code to incorporate the new dependency. Every major open source package manager includes the concept of software versions. When we use external code, we “pin” that code to a particular version. The exact mechanism we use to do that varies, but always means that we end up explicitly defining the exact version number of a piece of code in our application.

That means that every time we re-install, we get the exact same software. Our automated test suites are run against the exact same software. When we deploy to a staging environment to do testing and quality control, it’s the exact same software. When we deploy to production… you get the picture I’m sure.

If the author of that code releases a new version, we’ll hear about it from the project mailing list, or from blog posts about it, but that code doesn’t automatically find its way into our applications.

When we decide to upgrade a dependency that’s a task that’s assigned to a programmer as part of a sprint. That task will consist of a number of things:

• They have to review the changes to the library.
• They have to change several pieces of configuration management code.
• They have to run all of our automated test suites and make sure they pass.
• They have to get the upgrade accepted by a peer review process (another programmer has to OK the decision).

And that’s just to change the latest version for a fresh install. It is nowhere near production yet. To get there you have full change approval and acceptance testing processes that are in place for individual deployments.

So how did left-pad affect us?

The short answer is, it didn’t.

By the time the applications we support are deployed, they safely include all of the code that’s required to run them, and that code is carefully managed.

The real disruption caused by left-pad was to the working life of programmers. It would have meant that new installations failed, or perhaps automated test suites didn’t pass. If we’d been working at 22:30 PM last tuesday, then during the two and a half hours that the whole affair lasted, it might have made us a little less productive. If we’d been doing a planned upgrade or deployment of one of our applications, we might have had to postpone it. (Although we likely would have been just fine with the specific left-pad issues.)

What it has meant, is that we’ve taken the opportunity to review our processes to make sure that we’re following established best practices for open source development in domains where managing risk is as important as health. And we welcome that opportunity - we’re always striving to make sure that our engineering standards are as high as possible.

Open Source or just good software engineering?

One of the great things about the open source movement is that we’re able to have high quality conversations about things like risk and failure in the open. When things go wrong, we’re happy to talk about it. The open movement shares its knowledge from the tough times as well as the good times. The open movement means that the stakeholder involvement and the responsibility is shared. If a solution needs to be found, it can often be found quicker and to a higher standard because it is being required and reviewed by such a large body of individuals.

More broadly, every software vendor, produces applications that depend on code they haven’t written themselves - regardless of licensing. Managing dependencies is a part of all modern software engineering. The most important factor here is not the licence under which that code exists. What does matter, is having an approach to risk that’s appropriate and responsible.

If you’d like to know more about the processes we use to make sure that we deliver the highest quality service to the clinical teams who use our products, or if you’d like to know more about how we might be able to help you, then do get in touch.

Photo credits: Paul Clarke