Healthcare IT, NHS, Our Tech, Research, Uncategorized

Partial booking – building a solution

Partial booking has many benefits but for most NHS Trusts is a difficult process to implement at scale. Delivered properly it requires two extra steps compared to traditional full booking and it is a highly manual process which usually relies on slow or labour intensive forms of communication.

From an engineering point of view, an idealised partial booking process had a moderate level of complexity. It’s not simple by any means, but the high-level process fits on a single sheet of A3. Yet add in the real-world complexities of managing thousands of appointments, inflexible technology and varying work practices across thousands of staff; plus all the usual day-to-day pressures of running a hospital – RTT targets, choose and book, TAL, clinic cancellations, room availability, phones ringing non-stop… Implementing a partial booking model becomes an enormous challenge.

To build something for this real-world scenario would be complex, slow and difficult. When DrDoctor first approached the problem, all we wanted to answer was: can we build something small that people will use?

We first tackled booking new patients for an initial consultation after referral – a key part of the process. We chose not to worry about the complexity of how to  get the patient onto the waiting list, how to process the referral or what happens while they are waiting. This simplified and focused us on one part of the partial booking process. Just contact the patient (or get them to contact you), find a mutually convenient time and make the booking.

We started by recording and transcribing the existing phone calls. A typical call took 3.5 minutes. We laid out all the letters the trust sent to the patient relating to this part of the process; an average of 2.2 (2.2 envelopes, 7 sheets or paper). Transit time through the booking part of the process (i.e. excluding the waiting time) took 9 days on average, from sending the initial invite letter to booking the appointment and making the patient aware.

We then distilled out the key information and phrased it as four questions from the patient’s perspective:

  1. How do I book an appointment?
  2. Where can I have my appointment? (Only applicable where there is a choice of locations!)
  3. What times are available?
  4. Has it been successfully booked ?

As a micro-trial, we guided* patients manually through each of these questions by text message, one question at a time. We chose a random group of 10 patients who had appointments due and to whom we would otherwise have sent a letter that day. We held back these letters and only provided a phone number as a back-up option in the initial message. When we received an answer, we followed up with the next question, and so on. The results were interesting:

  • 6 patients booked themselves in completely by text message
  • 1 decided to call up as they were not comfortable sending text messages, but were happy to receive and read them
  • 3 did not respond within 12 hours (the period over which we conducted the trial) – we subsequently reverted them back to the normal letter/phone based process.

With 7 out of the 10 appointments booked within 2 hours there was a significant time saving, and we eliminated 7 sets of letters and 6 phone calls. Although a small not statistically significant sample size, this quickly allowed us to understand that there was real value here for hospitals. The trial also flushed out all kinds of scenarios that needed consideration. For example, what should we do when someone doesn’t respond? What does it mean for a hospital if we book the majority of patients in hours rather than days or weeks?

We also then called each of the patients, explained that we were conducting a trial, and asked for feedback using open questions. The key themes that they all told us about were about it being quick, convenient and easy. To us these are the three magic words that tell us we are doing something right.

This fast, lightweight iteration gave us the confidence to explore the rest of the problem space and code an automated solution which we knew would be genuinely useful for patients and providers.

* this means we pretended to be a computer, but it was actually a couple of us with Excel spreadsheets typing away on a phone!