Big problems in health tech that get us excited

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.

Read more

Happy Birthday to OPAL!

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:

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

Read more

NHS Hack Day 13 - London

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

Read more

How we manage risk when we use open source in health

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

Read more

Why we don’t do product placement at NHS Hack Day

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

More Posts:

Talk to us.

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

Get in touch