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