We’re excited to announce that we’ve just released Opal 0.10.0.

With more than 450 commits from 8 authors, what’s new in this version?

Windows support

This is the first Opal release to officially provide Windows support (more details to follow) which we hope will be particularly helpful to developers within the NHS looking to use Opal at work.

Although we don’t actively develop Opal applications on the Windows platform, we’re now running all of our tests on Windows as a Pull Request status check. This gives us a minimum level of assurance going forwards that we’re not introducing things that cause issues, and a strong basis to investigate any platform specific bugs that may get reported.

Particular thanks goes to the NHS Digital Innovation Fund for supporting this work.

Default reference data

As an Opal maintainer, one of the interesting things about attending NHS Hack Day events is that it’s highly likely that at least one team will be building their project on top of Opal. That means that we frequently get to observe developers starting a journey with Opal. Mostly they’re creating new Opal applications and battle-testing our project scaffolding, often they’re also using the platform in anger for the first time.

One of the things we’ve observed is that the step of importing or creating clinical reference data for a new application is something that hasn’t always been as slick as we’d like. (Until recently the tutorial suggested running wget on a bit of JSON on the internet and then feeding it into a database.)

This clashes with our batteries included design philosophy of optimising for programmer happiness. With our wrappers around the Django startproject command we try very hard to make the first hour of development exceptionally productive — and this was obviously somewhere we could do better.

Starting withthis release, new Opal applications come with the module opal.core.referencedata installed by default. This means for instance, that when you open an ‘Ethnicity’ dropdown in a freshly scaffolded application, rather than being an empty dropdown, you get the list of ethnicities from the NHS Data Dictionary.

API enhancements

Most of the work that went into Opal 0.10.0 was focussed on enhancing the programming API for building applications. New helper functions, new commandline options, and other enhancements to improve the developer experience.

There are also lots of enhancements and expansions to our documentation to help you along your way. You can read the full change log to get further details.

What next ?

If you already have an Opal application we’d recommend you upgrade as soon as you can. This release also requires an upgrade to a number of our upstream dependencies and some Opal migrations. You can read our upgrade guide here, and feel free to post to the mailing list if you run into issues with your upgrade.

Many thanks to the following people for their contributions to this release:

• Carl Reynolds
• Chris Lamb
• David Miller
• Fred Kingham
• George Hickman
• Marcus Baw
• Matt Stibbs
• Tom Ormiston

Dan Gold

Our friends at Open Odonto are working to make sure that NHS dentistry gets to take advantage of the internet era.

They are demanding better digital services, processes and data, fit for the Internet era as well as building communities of practice that help to raise the expectations of clinicians and patients, and conducting user research to help understand the needs of people receiving and delivering care.

One of the areas that they’ve discovered is particularly painful is dental referrals.

What are dental referrals?

Sometimes patients who go to see a high street dentist need specialist care. That might be because they need a procedure that the high street dentist isn’t able to deliver, or because they have particular needs requiring specialist training, expertise or equipment - for instance patients with reduced mobility, chronic dental phobias, or other complex health conditions. Those patients are referred to a specialist dental service appropriate for their needs.

In theory, that sounds simple enough - you simply need to book a patient an appointment with the right clinic, and make sure that the clinic has the patient’s notes and x-rays.

In practice however, dental referrals are often anything but simple. We post and fax partially completed, badly designed forms around, and then frequently rely on nursing staff to spend time phoning around trying to find the additional information they need in order to even understand if they are able to help the patient. At the end of all this the patient is sent a letter in the post informing them of the date and time of their appointment.

This referral process is slow frustrating for everyone involved, and can leave patients waiting around for weeks without any update at all - because we haven’t managed to iterate on the information infrastructure that underpins our health system.

In 2017 we shouldn’t be having to wait around for a letter in the post that is delayed because we’re phoning someone up about information that was missing in the fax where they wrote basic information about patients by hand.

Making things better

As part of their work, Open Odonto have been researching how they might transform the dental referral process so that it worked better for patients and clinicians.

Earlier this year we spent some time working with their team to build a prototype referral service that would reflect this research. Building prototypes like this helps people to imagine a future where the world is better and realise that it is possible for us to get there. It also helps to validate ideas and designs with potential users and make sure that our ideas might actually work and that we’re working towards a future which is actually better, not just digital.

In our initial prototype we’ve focussed on referrals of patients who require Special Care Dentistry - the kinds of patients who have complex health issues which require specialist equipment or training. This approach allows us to design for the furthest first - a referral system that can work for the complex cases seen by Special Care Dentistry is more likely to have the capacity to work for everybody.

We started with a referral form - where a dentist would enter details of the person who they were referring to another service.

In line with recent commissioning guidance on how to manage dental referrals from NHS England, we designed for a system which includes a regional hub that triages referrals to decide where the patient can be helped best.

That meant that in our prototype a different user can review the details of a referral, and has the ability to add or update information, before making a decision about where to refer them.

One of the major issues with the current processes is that it is almost entirely opaque - once a referral has been sent it’s impossible to understand what is happening to it until a letter eventually arrives on the doormat of the patient.

We wanted to ensure that there was transparency throughout the system of referrals in progress, and completed. This means that when patients call up their high street dentist asking for an update on when they might get help for their painful tooth, they might get an answer better than “I have no idea”.

Although we didn’t explore it in this project, managing referrals in a joined-up manner would make it trivial to send notifications or text messages to patients informing them in real time when there was progress on their referral.

There has been positive feedback from users in the initial user research sessions with the prototype referral service.

It’s really good - when can we have it?

I’d much rather do this than pen and paper

I would like this!

This has been a hugely enjoyable project - many thanks to the people without whom it wouldn’t have been possible: Becky Wassall and Lucille Valentine for their expertise and domain knowledge, Newcastle University who provided funding for the work, and Fred Kingham who wrote the code.

What next?

After the research and prototyping we’ve done on this project, we’re more convinced than ever that there is a need for a better dental referral process, and that we can build digital tools that support that better future.

We still need to conduct some more research, test and iterate our prototypes further with more users before we look to build a working service that can be used to replace the faxes and paper forms, but we’re excited to do that work and move to a world where patients aren’t left in the dark about their care, and NHS staff don’t waste their time plugging gaps in broken processes instead of caring for patients.

If you would be interested in working with us or Open Odonto on a better dental referral system, or finding out more about the prototyping work we do at Open Health Care, do get in touch.

Photo Credits: Bob Harvey & Matt Jiggins

A few weeks ago now we released Opal 0.8. It’s quite a large release, so we thought we’d walk you through some of the highlights.

Forms - now with added sugar

We’ve been spending lots of time working to make forms easier to work with. Sometimes it seems that 95% of designing services is making forms that aren’t frustrating and difficult to use - and having good tools to quickly build and iterate the forms you’re working with can make that process much easier.

We made sure that some of the features from Django models, like choices and defaults now flow through seamlessly by default to our form widgets, and that the client side Angular code will use these by default without you having to do anything. This was all possible before, but required more typing. Nobody likes extra typing.

For instance, if we had the following model:

class TableClothPreference(EpisodeSubrecord):
        COLOUR_CHOICES = (
          ('P', 'Purple'),
          ('R', 'Red'),
        )
        favourite_colour = models.CharField(max_length=200,
                                            default='Purple',
                                            choices=COLOUR_CHOICES)

We would be able to render a dropdown widget for the field that used the default and restricted the choices by simply using the following in our code:

{ % select field="TableClothPreference.favourite_colour" % }

We’ve also spent time making sure that form validation is much easier to work with. By default we now validate forms on submission - making sure that we respect max length of form fields for instance.

As well as the improvements to forms in Opal itself, we’ve also been working hard on the Opal Pathway library. This library makes it significantly easier to work with complex forms - particularly ones that need to save data to many different models. Although Pathway is still considered alpha software, we fully anticipate that we’ll be incorporating it into Opal itself as the recommended way to build forms in Opal applications later this year.

Python 3 support

Responding to an issue raised on the mailing list, we’ve refactored Opal to work on Python 3. Thanks to the hard work and excellent tooling in the Python community this was a relatively painless task, but hopefully it puts us in a good position to move towards Python 3 deployments moving forwards.

Common patterns for customising Patient Lists

We’ve made it much easier to implement some of the common patterns we see when working with patient lists, by explicitly adding APIs.

You can now customise the ordering of patients on a list-by-list basis using the comparator_service attribute of PatientList classes. A comparator service is an Angular service that returns a list of comparator functions that are used in order to determine how we should compare and sort two episodes - for instance:

angular.module('opal.services')
        .factory('MyComparatorService', function(){
            "use strict";
            return [
                function(e){ return e.category_name },
                function(e){ return e.id }
            ]
        });

We also introduced an easy way for you to group lists into tabs that display in the default template.

Goodbye Angular-Strap

Until Opal 0.8 we had not one, but two UI libraries which wrapped Bootstrap components in Angular compatible code. We’ve been uncomfortable about that for a while - it’s confusing to have to remember which widget comes from which library! As of Opal 0.8 however we’ve picked a winner - UI Bootstrap, and we removed all references to Angular Strap completely, both in Opal and in all the applications and plugins we could find on Github.

We’re planning to update the UI Bootstrap library to a more recent version in the next couple of releases, but the re-naming of their modal component could potentially make this transition slightly tricky, so we’re waiting to make sure we can do so as smoothly as possible.

Finding out more

If you’d like to find out more about Opal, then you might like to try the documentation or the mailing list. There are more details about some of the other smaller features and bugfixes in 0.8 in the release notes, and you can also read about how to upgrade from 0.7.x in the documentation.

If you have a project that you think might be suited to Opal, please do get in touch - we’d love to hear from you.

Photo credits: Jay Springett

Last year we were commissioned by NHS England to research the needs and experiences of people using open data about health. NHS England wanted to have a strong evidence base from which to develop their open data policy and programme agenda. We conducted a series of formal interviews and informal conversations as well as some desk research before writing up what we learned as a report.

Today we’re publishing that report online. We believe that our two key recommendations would go a long way to addressing the most pressing issues that we discovered. We’ve also included summaries of individual user interviews for those who want to really understand the detail of life as an open data user.

If your organization is interested in this kind of work, we’d love to talk with you and see if we can help - do get in touch.

It was fascinating to hear stories from a wide range of people who use open health data. Many of their experiences mirrored what we found when working on projects such as Prescribing Analytics and what we hear from people working on open data projects at NHS Hack Day.

Although some specific datasets or teams are excellent, many issues remain with the quality of data publishing in health. Data publishing is precisely the kind of problem that the phrase It’s not complicated; it’s just hard could have been coined about. Many of the issues people face are entirely tractable if we take the time to understand their needs and respond to them thoughtfully. It’s great that NHS England is conducting this kind of research, and we hope that they can use this evidence to move forwards with open data in health along with their colleagues from other organizations.

One of the other features to emerge from our research was the lack of data routinely used as part of clinical practice in the NHS. In our work building digital tools for clinicians we regularly find that they don’t have access to basic data about their activity. The Wachter report recently highlighted the lack of digital capability at many institutions in the health sector. There is also an equivalent lack of capability to make better use of data, and this is likely to make it significantly harder for clinical services to adjust well in the face of a changing population and the current aggressive financial environment.

Although it was decidedly out of scope for this report to address these challenges, we would argue that in order to “exploit the information revolution” as NHS England put it in 2014’s Five Year Forward View much work needs to be done to capture better data, make it available at the point of service delivery, and to build the capability to use that data routinely to make better decisions.

Many thanks to all of the interviewees, everyone who talked to us or provided feedback on drafts, and especially to Giuseppe Sollazzo who did the majority of the real work on this report - conducting interviews, and analysing the common issues.

If you have any feedback on the report itself, do let us know what you think at hello@openhealthcare.org.uk

The health system in the UK publishes a lot of data.

A quick trip to Data.gov.uk reveals 1,897 health related datasets. At the same time both NHS England and NHS Digital publish official National Statistics, not to mention the various data portals (NHS England, NHS Digital, NHS Digital again), and data published on Gov.uk.

And this is before we get to stray web pages related to specific pet political projects that contain “Download and take away data”, in some obscurantist dialect of almost-but-not quite CSV that doesn’t “just work” with any standard tools. (Yes MyNHS, I mean you.)

Data however, is incredibly boring to most humans. Which makes it really hard to understand the value of all of that data, by just looking at a list of data.

Even more so than data in general, Open Data is an abstract concept that can be hard to grasp.

For years, Open Knowledge and the Open Data Institute (and others) have worked hard on the valuable job of finding ways to make these concepts clear and accessible.

Our experience at Open Health Care is that clarity often isn’t enough - you need to make things tangible for people to really understand them. That’s the main reason that we believe in Showing The Thing - that practical demonstrations have vastly more power than descriptions or abstract concepts.

That’s why we so often build prototypes of things to help us tell stories about how the world could be better, and why we encourage communities grappling with digital and data to learn by doing.

Earlier this year, we spent some time with the Open Data team at NHS England working out how we would go about applying Show The Thing to the world of Open Health Data.

We started by doing some desk (Google and Twitter) research collecting examples of interesting projects that had used Open Health Data to build a product or service, to tell a story or start a campaign.

This turned up some old favourites - like our project from a from a few years ago visualising issues with the prescribing of non-generic Statins - as well as some interesting projects that were new to us - like the Royal College of Paediatrics and Child Heath campaign “Why Children Die”.

We then gathered these together and built a single directory website that showcases these projects in one place.

This directory helps to point people at stories and examples of things that have used open health data - and in doing so, helps to show why that data is valuable in a way that they can grapple with and kick the tyres for themselves.

For instance - one of the great things about the Open Prescribing project made by our friends at EBM Data Lab is that is has buttons you can press.

People like pressing buttons.

We’re still looking for more great examples though, so if you’ve worked on a project that uses Open Health Data that you think might be suitable for the directory, you can submit your project here.

Because it’s always great to have more things to show…

Photo credits:
Redjar

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

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

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

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

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

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!

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.

UK Health Camp - it’s happening.

Some great things have happened to digital in the NHS over the last few years - and we’re excited to have played a part in it. We’ve seen a wonderful community blossom around NHS Hack Day - catalysed by their desire to make NHS IT less bad. We’ve seen high quality, user needs focussed, open source clinical facing digital services launch in an increasing number of NHS trusts. We’ve seen open data used to demonstrate huge potential cost savings to the NHS - helping to reinforce the commitment to transparency and openness throughout the system.

And those are just the pieces that we’ve been involved with - there are so many more happening all through the NHS.

One of the great strengths of the NHS is its decentralization - although it’s a public sector institution, much decision making is devolved to a local level - which means that you see pockets of innovation springing up all around the country as its remarkable staff strive to deliver better services to patients. The downside of decentralization is that sometimes those innovations and best practices don’t spread as quickly as we’d like - which is how we end up with variation in services.

We believe that local excellence is not good enough - we need scalable excellence if we’re to deliver digital services in health care that are fit for purpose in the twenty first century.

Which is why we’ve been working with a super team of friends from across the health system to create a space to help connect people doing great work in this space with people who understand that we need to do better, faster, wider. A space to connect, share ideas and make things happen.

That space is UK Health Camp.

UK Health Camp is a free unconference for everyone interested in digital, design, technology and data for health and care. It’s happening in London on the 28th November, and it’s going to be the most exciting conversation around for people who want to understand how we can deliver better services to patients by using better digital, better data and better design.

We haven’t released tickets just yet, but we expect them to go fast when we do release them - so sign up to the mailing list to get notified when they do become available.

We look forward to seeing you there!

We’re delighted to announce that NHS Hack Day is coming to Manchester on the 12-13 September. This is the first time we’ve taken the event to Manchester, and we’re all very excited to be doing so with the help of the super Marcus Baw!

NHS Hack Days are weekend events that bring together “geeks who love the NHS” to have fun, build community, and work on digital projects that promote health.

The format is that we begin on a saturday morning with people pitching real-world problems they’ve encountered in the NHS or in health care generally. Anyone can pitch. We end on Sunday afternoon with a competition for the best solutions made over the weekend. In between people pick projects to work on, work on them, and have lunch (provided).

Previous NHS Hack Days have looked something like this:

Do check out some of the projects that have come fom the event and read our summary of the previous NHS Hack Day

Why should I come to NHS Hack Day?

You’ll meet bright people from different disciplines you wouldn’t usually meet You’ll play a part in making NHS IT less bad You’ll have fun

We especially want people who aren’t sure if this is for them to come, a lot of the value of the event comes from the diversity of the participants, we need you! Imposters are welcome

How do I get involved?

• By attending the event, tickets will be released this evening from www.nhshackday.com
• By sponsoring the event - email hello@openhealthcare.org.uk
• By becoming part of our community - joining the mailing list, coming to pre event meet ups or talking to us on Twitter
• By spreading the word, tell your friends!

This post is the prose form of a workshop we recently ran at the Department for Business, Innovation and Skills about hack days.

So, you want to run a hack day?

A hack day is an event in which domain experts with user needs collaborate with people who have skills in delivering digital products and services including developers, designers, user researchers and product specialists. Hack days typically last between a day and a week. Some hack days are intended simply for educational or social purposes, although in many cases the goal is to create usable software.

Hack days are a great way to get multidisciplinary teams working together to create creative tangible solutions to real world problems.

Why are you doing this?

The first thing you’ll need to figure out is why you’re running a hack day.

There are broadly five reasons people run hack days.

1. To build community
2. To educate people
3. To get focussed fast paced R&D
4. For PR
5. er hack days are cool, what do you mean why?

You should make sure you have a clear answer to why you’re doing this before you start running a hack day - because this maximises the likelihood that you and your attendees will have a great time and get lots of value from the event.

For instance, with NHS Hack Day - the events that we run around the country for “Geeks who love the NHS” - we have a few reasons. We’re aiming to:

1. Build community and friendships between members of the clinical and technology sectors
2. Show front line clinical staff just how good Digital Services can be, empowering them to demand better from their institutions when they go back to work
3. Showcase Open Source, Open Governance, and the power of collaborating in small heterogeneous teams of domain experts.

That’s reasons 1, 2 and a little bit of 4.

You might be looking to build the cross-disciplinary skills of your teams, introducing people to Digital ways of working, thinking and approaching problems, you might be looking to provide concrete examples of products and services aligned with your policy goals - understanding that showing is more powerful than telling. Whatever your reason is, make sure you can explain it clearly so that you remain focussed on that throughout.

What do you need to do?

So, you want to run a hack day ?

Great!

There are lots of documents out there that will take you through the low level details, we’re not going to go through those again in detail, but you basically need to put five things in a room:

1. User needs
2. Wifi
3. Power
4. Coffee
5. Technologists who know how to deliver Digital

Start with needs

The value that comes from the event is directly related to the quality of the ideas for projects that are in the room. The best hack day projects address specific real world user needs. It’s well worth thinking about these before the event, and seeking feedback from others - particularly from people who’ve attended hack days before.

With NHS Hack Day, we encourage people to discuss their ideas on our mailing list, on Twitter, and in person at meetups so that we can help people come with well formed ideas that inspire our attendees. For more focussed commercial hack days we work with people to frame and present their ideas in such a way that they work well within the context of a hack day.

Basic logistics

Hack days have some slightly special logistical requirements of the room that you’re going to be in. The most frequent problem is that the Wifi isn’t good enough. As the Hack Day Manifesto says:

Don’t just trust anyone who tells you that “it’ll be fine”. People from the venue or their commercial partner will tell you all sorts of things you want to hear but keep in the back of your mind that they may not have any clue what they are talking about.

In addition to this, you’ll also have lots of people wanting to plug in their laptops, so try to make sure that there is good access to power points. Providing tea, coffee and other beverages as well as lunch and breakfast is always appreciated by attendees, as are easily accessible whiteboards, flip charts, post-its & sharpies.

Making your ideas a reality

At the end of your hack day, you’ll have a wrap up session where everyone presents what they’ve been working on. There will be lots of excitement and energy in the room, you may even have judges and prizes! If all has gone well, several prototypes of new Digital products or services will exist that didn’t at the start of the day.

If your aim was to build community and educate people, then you should already have gone a long way to meeting your goals! Sometimes though, you will want to find a way to take promising projects forwards and make them genuine products or services.

If you’re looking to do this, then it’s worth thinking about that path before the event. This might involve providing investment or support for teams who want to go forward with their idea, promising people time to work on their project, or giving projects marketing and promotion. The details are often dependent on who you are, and what kinds of user needs you’re looking to meet.

Still want some more help?

If you’re still unsure about how to run your hack day, Open Health Care UK provide strategic and logistical support to organisations in healthcare and the wider public sector looking to run great events - so drop us a line at hello@openhealthcare.org.uk to see how we can help.

For the past couple of years, Open Health Care has been working in collaboration with UCLH and the Hospital for Tropical Diseases on elCID (the electronic Clinical Infection Database) - an Open Source clinical Digital service for managing inpatients and outpatients with infections.

elCID solves two key clinical problems - first it provides an interface for recording day-to-day clinical care. We’ve developed this interface in close collaboration with clinicians with a strong focus on usability, using user centred design techniques, and frequent iterations, to make sure that we meet the real needs of our users.

Second, elCID captures structured data about clinical activity, and features advanced interrogation and extract capabilities. This enables data driven feedback loops in the design of clinical services, by enabling high quality audits to be conducted much faster than was ever possible before.

Working with some of the academics who’ve been instrumental in developing the project, we recently published an analysis of the early findings from this process in the Journal of Infection.

As the paper outlines:

elCID brings together disparate silos of clinical data collection into a single, rapidly searchable database resource permitting unprecedented interrogation of our clinical practice.
However, the benefits of the system go further, having vastly improved the quality and transparency of communication between the Division’s teams, audits of day-to-day clinical practice are now rapidly and routinely performed using high quality prospectively collected data, and research study data collection can be conducted within the main database, facilitating improved integration of the clinical and academic arms of the Division.

elCID is an Open Source, Open Governance project built on the Open Source OPAL framework. It is available to infection services and comes with full support and customisation from Open Health Care. You can find out more information about the software on the elCID website.

If you’re interested in seeing how elCID might help at your organisation, or if you’d like a copy of the full paper, don’t hesitate to drop us a line at hello@openhealthcare.org.uk

Last weekend saw us reach a milestone as we brought NHS Hack Day back to London in our tenth event in just three years!

NHS Hack Days are weekend events that bring together patients, healthcare and technology professionals and other “geeks who love the NHS” under the banner of making NHS IT less bad. It’s always a pleasure to see so many talented people come together to share their time, skills and experience to create something together, and this was no exception.

The event started with clinical staff, patients, and anyone else who felt they had a way to make the world a little better pitching ideas that they wanted to work on. Pitches start with a User Need - for instance the surgeons who need a way to track their continuing professional development, or the doctor who wants quick and easy offline access to formulary information. The attendees then pick what project they want to work on, and form teams to try and build a prototype over the weekend.

At the end of the weekend, we gathered together to share what we’d learned and what we’d built over the weekend.

Some of the stand-out projects from the weekend were The Locumator - an app which helps hospital schedulers and doctors to fill vacant slots with bank staff, and Take Your Meds - a low-tech phone reminder application that sends a configurable audio message via phone call to a patient, reminding them to use the mouthwash, or take their medication.

You can see the whole list here.

Locumator’s presentation

More information on Take Your Meds is available from their Github account

This time, our cat-herder in chief was the amazing @deckofpandas - and we’d like to thank her again for all of her hard work in making the event such a great experience for everyone involved.

Next time looks like being Manchester in Autumn 2015 - although the venue & exact date are yet to be confirmed. We’d love it if you joined us though - so do sign up to the mailing list to be kept in the loop !

Photo credits: Cléon Daniel

At Open Health Care we believe in Evidence Based Medicine.

Which is why we create digital health services that support research.

Unfortunately the current infrastructure supporting evidence based medicine has some shortcomings. One of these is that when a research paper is retracted because, for example, the author made up the results, there is little or no means to propogate this update in the wider medical literature.

Supposing, as a doctor, I look to a systematic review on the management of heart attacks to inform how I treat my patient, I sadly have no assurance that the systematic review does not rely on research papers that have been retracted. This is suboptimal.

Open access, post-publication peer review, and better version control would be three useful features that a modern scientific publishing model optimized to enable good science should support.

In the meantime, inspired by a lunchtime conversation with our friend and director Ben Goldacre (it was all his idea), we pondered the question:

What is the most cited retracted paper?

It turns out PubMed already has a nice API that can return a list of PubMed ids for papers that have been retracted. Next we needed a means of knowing how many times each retracted paper was cited. There are a few ways of doing this but we went with using google scholar after Alf Eaton told us about it on twitter. It’s possible to search google scholar for the articles citing a particular pubmed id, here’s an example.

Finally, we used wget to download all of the google scholar search results. This infamous paper ‘Ileal-lymphoid-nodular hyperplasia, non-specific colitis, and pervasive developmental disorder in children.’ was the winner with 2070 citations!

Here’s the top ten:

You can reproduce our results or view our workings over on Github.

There are of course many reasons other than the author making up the results for a paper to be retracted. There are also many circumstances in which citing a retracted paper is legitimate. For a more nuanced discussion of retractions there’s a nice Comprehensive Survey of Retracted Articles from the Scholarly Literature in PLOS and the excellent Retraction Watch covers the details of individual retractions as they happen.

Anyway, it was fun to examine retractions. We’d love to explore this further so if we can be of service to you do get in touch.

Perhaps a project for NHS Hack Day?

Calling all friends of NHS Hack Day:

We’re having a meet up on Thursday 16 April, and we’d love to see you there !

We’re going to be in the George Inn near London Bridge from 18:00, and we’d love to talk to people about not just the upcoming NHS Hack day, but also any of the other ways that technology and data can make the NHS better, make new friends, & even start planning how to make some of those ideas a reality!

Where: The George Inn

When: Thu 16 April 2015 18:00-21:00

Who: Anyone & everyone ! All welcome, no specialist skills or knowledge required…

How: Just turning up is fine, but you can also add yourself to our event page.

If you’re thinking of attending NHS Hack day, have a good NHS related problem that you want to see solved, or are just curious as to what all this is about, this is a great event for you! We’ll have the @NHSHackDay team on hand, and we’re excited to hear your great ideas ahead of the event next month!

Photo credits: Andrew Smith

NHS Hack Days are weekend events that bring together “geeks who love the NHS” to have fun, build community, and work on digital projects that promote health.

NHS Hack Day began in 2012 when Carl (a doctor) complained to his friend Tom (a developer) that things were really very broken in NHS IT. Tom who’d recently had a good experience at a Cabinet Office GDS Hack Day said the NHS should have a hack day. So we did.

The format is that we begin on a saturday morning with people pitching real-world problems they’ve encountered in the NHS or in health care generally. Anyone can pitch. We end on Sunday afternoon with a competition for the best solutions made over the weekend. In between people pick projects to work on, work on them, and have lunch (provided).

Previous NHS Hack Days have looked something like this:

Do check out some of the projects that have come fom the event and read our summary of the previous NHS Hack Day

Why should I come to NHS Hack Day?

You’ll meet bright people from different disciplines you wouldn’t usually meet You’ll play a part in making NHS IT less bad You’ll have fun

We especially want people who aren’t sure if this is for them to come, a lot of the value of the event comes from the diversity of the participants, we need you! Imposters are welcome

How do I get involved?

• By attending the event, tickets will be released this evening from www.nhshackday.com
• By sponsoring the event - email hello@openhealthcare.org.uk
• By becoming part of our community - joining the mailing list, coming to pre event meet ups or talking to us on Twitter
• By spreading the word, tell your friends!

This is a guest post by Nicholas Tollervey

The purpose of this post is to explore openness in government technology. I’ve been asked to advise on this subject for NHS England. I shall be directing the civil servants I have been working with to this article.

To many people much of this post will be old news. Unfortunately we are in the minority. Hence the need for this summary.

As always, feedback and comments are most welcome; in fact, comments will be quite useful given the readership will include civil servants who can make changes within NHS England. Think of it as an unofficial opportunity for engagement with the unelected arm of the government.

The moral argument for openness in government is simple: it is a fundamental requirement for a democratic society. Without the ability to observe what and how the government is doing, how are citizens to evaluate politicians come polling day?

Yet openness is too broad a term - in this sense it is perhaps a virtue of a good political system. Therefore I will simply state three practical embodiments of the virtue of openness:

1. Open data - data should be freely available without restrictions of copyright, patents or other controls;
2. Open media - data generated by the government should be in a format that is accessible to everyone;
3. Open processes - what the government does should be transparent, recorded and accountable.

The UK Government has been vocal in the promotion of open data (point 1). Yet it is not good enough to simply publish data. The format and structure of the data is critical (point 2), as is its provenance (point 3).

Regarding point 2: what’s the point of publishing data if there’s no way for people to make use of it? After all, when data is read, analysed and interpreted it becomes useful information. Publishing data in a medium that only works with a single piece of software (such as releasing tabular data that can only be read by Excel) makes it frustratingly difficult use. While I welcome the publication of data I’d much rather it were in a friendly open format (such as releasing tabular data as a CSV).

Regarding point 3: what’s the point of publishing data if there’s no way to discover how it was compiled, by whom and with what intention? It should be possible to independently check the reports published by government through access to the raw data and (crucially) the algorithms, processes and pipelines used to aggregate, transform and generate the end result. Furthermore, an open process allows people to examine, test and improve the methodology involved in generating data. It will no longer be the case that compiling some-report-or-other is only understood by a couple of government statisticians - this essential organisational information would be available to all.

While this sounds like an onerous task for civil servants it is important to note that these three practices actually make life easier for all involved, including civil servants.

From a technical point of view, it’s impossible to work effectively in digital walled gardens where opaque solutions don’t quite work properly and are too expensive to migrate away from. Open standards allow anyone (including civil servants) the flexibility to use their own choice of tool for the job in hand as illustrated by the diagram below.

As the Cabinet Office minister Francis Maud states,

Government IT must be open - open to the people and organisations that use our services and open to any provider, regardless of their size.
We currently have many small, separate platforms operating across disconnected departments and IT that is tied into monolithic contracts. We need to have a platform for government that allows us to share appropriate data effectively and that gives us flexibility and choice.

Contrast this vision with the incumbant alternative (based on real life experiences working with statisticians within NHS England):

• No-one wants to work in a world where the data they need for their report is held within a complex Excel spreadsheet with meaningless column names generated by a team who never answers email.

• No-one wants to work with a spreadsheet that is subtly different each time it gets published causing doubts about its reliability and provenance.

• No-one wants to work with a spreadsheet hosted on a website created in 2005 where the only way to get at it is to download a Java applet (the technical equivalent of the ruins of Ozymandias ) and manually press a button on a computer logged into the very special VPN that never works when you need it to.

Such a chain of opaque technology comes at great cost in terms of time, efficiency and job satisfaction. Highly trained NHS statisticians do not enjoy spending hours downloading, revising, copying, pasting and re-uploading shonky spreadsheets.

They want to work with data, not push it around.

They want to access the data, not spend hours clicking buttons.

They want to understand their colleagues’ work and know who to contact if there’s a problem.

Happily, there are signs of hope.

In the first instance civil servants should be following the Open Standards Principles from the Cabinet Office

It is a simple and easy to understand guide for using open standards in government. If you’re a civil servant working with data you should be following this checklist:

1. We place the needs of our users at the heart of our standards choices
2. Our selected open standards will enable suppliers to compete on alevel playing field
3. Our standards choices support flexibility and change
4. We adopt open standards that support sustainable cost
5. Our decisions about standards selection are well informed
6. We select open standards using fair and transparent processes
7. We are fair and transparent in the specification and implementation of open standards

It is no longer acceptable to say things like, “but the needs of our legacy system mean you should use <closed technology X>”. If you hear such a remark, point the perpetrator at the checklist above. If they claim it would be too expensive to migrate, explain that it’s because it is so expensive to migrate that such a system needs changing (such expense only ever grows over time, change things sooner rather than later). If they assert that it’s not organisational policy to use open process Y ask them to justify themselves within the framework described in the policy document above (that became active on 1st November 2012). Cabinet Office advice when choosing technologies is that one should express requirements in terms of user needs and capabilities not incumbent institutional needs. Furthermore, when considering the choice of technology, they state,

All things being equal, picking technologies that developers and operations staff like will typically result in improved productivity.

A second positive is that there appear to be politicians of all affiliations who understand and have the political will to promote open standards.

Consider the following exchange between myself and Meg Hillier MP:

.@Meg_HillierMP, given ubiquity of closed formats (MS Office etc), will Parliament switch to publish w/open data formats? #digitaldemocracy

— Nicholas Tollervey (@ntoll) March 10, 2015

.@ntoll yes..that's the plan. New head of Parliament Digital Service @Rob_Greig is already working on this

— MegHillierMP (@Meg_HillierMP) March 10, 2015

.@Meg_HillierMP motivation for my q is current work w/@NHSEngland stats / data in messy, non-machine readable Excel spreadsheets & PDFs. :-(

— Nicholas Tollervey (@ntoll) March 10, 2015

@ntoll @Meg_HillierMP @NHSEngland "non-machine readable Excel spreadsheets" –> cold shiver in my spine

— Giovanni Idili (@John_Idol) March 10, 2015

.@John_Idol @ntoll @NHSEngland and that's not the worst of it! sometimes they are not even readable in paper form

— MegHillierMP (@Meg_HillierMP) March 10, 2015

@Meg_HillierMP @John_Idol @NHSEngland good point - demonstrates accountability/evidence: confusing data=confused understanding perhaps?

— Nicholas Tollervey (@ntoll) March 10, 2015

.@ntoll @John_Idol @NHSEngland yes. We are coming from same place on this issue. Open Up! #digitaldemocracy

— MegHillierMP (@Meg_HillierMP) March 10, 2015

@Meg_HillierMP @John_Idol @NHSEngland quite… so having evidence is one thing - but how does a citizen hold publisher accountable?

— Nicholas Tollervey (@ntoll) March 10, 2015

.@ntoll @John_Idol @NHSEngland we need to make it either embarrassing for them or in case of Govt manke it mandatory

— MegHillierMP (@Meg_HillierMP) March 10, 2015

Here’s hoping NHS England leads the way in open standards. After all, they were born from a disparate collection of existing governmental organisations, each of whom did things differently. Openness is a way for NHS England to integrate, collaborate and work more effectively towards making the NHS the world class healthcare system it needs to be.

This is an opportunity that applies to the whole public sector. The cost of inaction would be to deny the government tools and processes essential for working effectively in a world in constant flux.

Panta rhei!

Photo credits:
Opensourceway
Pol Sifter

At Open Health Care, we believe in User-centered design.

Which means that we focus on meeting the needs of our users, and is why we always work in close collaboration with them. Whether that comes in the form of making sure that our clinical champions are present at every sprint meeting, or working hard to get clinical staff and patients along to NHS Hack Day we work by putting users first, building and testing in small chunks.

Working this way means that generally when we work on a project, we identify clinical champion(s) for that project. These are the kind of people who will use the service we end up building in their day-to-day work. In order to get them as involved as possible, we introduce them to Agile, and we often find ourselves teaching doctors to github. (Yes, that’s a verb now).

The great thing about working in multidisciplinary teams, is that everyone learns new things, all the time. For every medical three letter acronym like say, CAP that gets explained to a developer, there’s an explanation of what API stands for that goes the other way.

But it’s not just terminology that gets shared - often we try to share our tools. We promote online collaborative document editing above email attachments and naming conventions. We encourage users to take up better web browsers. We get them to try out modern team communication tools, and recommend Open Source alternatives to the proprietary default incumbents.

But wait - it gets better

Not only does this help us all understand one another better, which is so vital to delivering high quality digital services, but it also often introduces clinicians to tools that reward power users with advanced functionality. Once you’ve learnt markdown once, typing information into text boxes that will get rendered in a web browser is never quite the same again. You start expecting that the web based clinical digital services you use in your day job let you use markdown there too.

Possibly the best feature we’ve implemented that came about this way is the OPAL Macros from late last year. Directly inspired by Github issue mentions, OPAL Macros let the user define blocks of commonly used text, and then insert them with shortcut Macros - (names preceded by the # symbol).

For instance, for Staph advice, the user enters #st:

… which then expands to the (institutionally defined) standard advice for this case:

This is the kind of user need that only even comes up when users are digitally literate enough to be able to express it - something along the lines of:

As a Doctor
I want to avoid repeatedly typing out standard advice
So that I can spend more time with my patients

The existence of this kind of power-user functionality encourages users to master their tools, by offering them time savings and efficiencies but crucially, doesn’t interfere with the user experience at all if you don’t know it’s there. As Dr Marks, who had originally explained the need on Github said:

Absolutely stunning.
I would say this is one of the most incredible things I have seen on a piece of NHS software ever.

If you’re interested in starting an OPAL project at your institution to take advantage of this kind of feature, or in seeing how we can can help you by providing clinical facing digital services, don’t hesitate to Get in touch!

Photo credits:
Jacopo Romei

Last week saw us excited to launch our new OPAT (Outpatients Parenteral Antimicrobial Therapy) service delivered via the elCID platform at UCLH.

This is the first deployment of the specialist OPAT module for OPAL - our Open Source framework for building transactional digital services. It covers the whole range of an OPAT service - from initial referrals and assessment, through ongoing care, post-treatment follow up and review. All of the workflows capture high quality data at the time of use, and allow analysis and extraction, both for reporting in line with national guidelines, and individual service audits.

As ever, we worked closely with clinical champions, who were deeply involved in the agile development process, weighing in on GitHub, attending sprint meetings, and providing their expertise to our development team. The whole project is released under an Open Source (GPL) license, and was developed in the open.

This was a project we loved delivering, and not just because of the high praise from Dr Jon Lambourne, UCLH’s clinical lead on the project, who said:

The Open Health Care team have been super, the things they can get the OPAL software to do regularly leaves me slack-jawed!

While we like to think that we’re pretty good at executing on the technology side of things, it’s really the collaboration between us and the clinical users, along with our focus on their needs that makes it possible for us to deliver new user-focussed digital services into the world.

Accordingly, we’d particularly like to thank Dr Sarah Logan (Our consultant sponsor), Steve Collins (OPAT Nurse extraordinaire), and Dr Jon Lambourne (Clinical lead on the project) for all their efforts.

If you’re interested in seeing an OPAL project at your institution, or in seing how we can can support running clinical OPAT services, don’t hesitate to Get in touch!

Photo Credits: Lydia

Last weekend saw us return to Cardiff for the 9th NHS Hack Day - once again, with organisation headed up by the life affirming Anne Marie Cunningham.

NHS Hack Days are weekend events that bring together patients, healthcare and technology professionals and other “geeks who love the NHS” under the banner of making NHS IT less bad. It’s always exciting to see people discover how digital products are made by “Not Magic”, not to mention the jaw-dropping that goes on when it gets explained just how bad much of the status quo really is.

Many of the pitches highlighted the need for quickly and easily customisable hospital systems, that allow people to collaborate more easily, and also to generate alerts and notifications, routing information that exists within our institutions to the people who can actually make a difference with it, in time.

As the second day drew to a close, we all gathered together to share what we’d made, and what we’d learnt over the weekend.

We thought that the team who rescued Virtual Microscope - a previously abandonned open source project for viewing, navigating & annotate very high-resolution images deserved huge credit.

Meanwhile the group that took the Oculus Rift and turned it into an eye-test scenario complete with zombies seemed like they had a whole world of fun !

In the end the grand prize went to Medboard - a system for connecting medical students to the classes & opportunities available to them at their respective institutions.

In addition, we were delighted to see our youngest ever attendee to an NHS Hack Day, with Ada Reynolds stealing the record at just 5 weeks old! Although she may have slept through much of this one, we’re all looking forward to her contributions next time !

Next time looks like being London in May 2015 - although the venue & exact date are yet to be confirmed. We’d love it if you joined us though - so do sign up to the mailing list to be kept in the loop !

Photo credits: Paul Clarke

OPAL at UCLH

Early in the year we deployed elCID - our custom built digital service for infection doctors to University College London Hospital.

Despite our early plans for a cautious, staggered rollout, demand from end users to transition to the system meant that we accelerated rapidly, spreading throughout the division of infection at UCLH and racing through the 1000 patient mark within the few months.

Not content to sit on our laurels, we’ve been further developing the platform, with a specialist OPAT (Outpatients Parenteral Antimicrobial Therapy) service developed and launched early 2015, and a walk-in clinic service scheduled for deployment in spring.

OPAL for research

2014 saw the first academic outputs from the OPAL project, with two posters presented at the Federation of Infection Societies conference.

Demonstrating the new capabilities for conducting clinical audits and exploring hypotheses about the patient population treated by UCLH, concluding that:

The electronic prospective data capture benefits of elCID have facilitated organisation
and interrogation of our own clinical practice to greater levels than before, describing
many hitherto uncaptured elements of clinical activity.

Hackdays

2014 saw the NHS Hack Day train roll in to Cardiff, London and Leeds. As ever the events saw us take multidisciplinary groups of Doctors, Technologists & Patients for a weekend of furious hacking, resulting not only in some great new projects, but in hundreds of individual opportunities for people to connect & learn from each other.

Particularly exciting were TB Care Plan - a single page TB guideline project that managed to take the rule of “As simple as it can possibly be” to new heights, and a Renal focussed OPAL implementation for handover and patient management.

The Future

2014 has been a great year for Open Health Care, & We’re excited looking forward to the year to come !

With new product launches, lots of exciting projects in the pipeline, as well as the relentless programme of running events up & down the country, we’ll be busy!

Photo credits: Paul Clarke && Gabriel Pollara