Building a better dental referral process

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

Read more

Opal 0.8 released

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,

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:

        .factory('MyComparatorService', function(){
            "use strict";
            return [
                function(e){ return e.category_name },
                function(e){ return }

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

Read more

Our report on open data in health

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

Read more

Show me the data vs. Show me the things

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

A quick trip to 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

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:

Read more

NHS Hack Day 14 - Newcastle

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.

Read more

More Posts:

Talk to us.

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

Get in touch