I like it when IT is used to simplify processes, improve design, save money and generally make life better and more enjoyable. But my encounters with the NHS Choose and Book system indicate that it has achieved none of these basic things.

After spending, over many years, what appears to be an unaccountably large amount of public money on its development, Choose and Book provides a system that has managed to simultaneously complicate the process, increase bureaucracy and add costs to an already challenged NHS budget. If anyone working for me produced a system in this state, even as a prototype over a weekend, I’d recommend they go and lie down for a while and then find another vocation. To produce a system like this after years of development and expenditure I find beyond my professional, and personal, comprehension.

My approximate version of how the NHS referral system used to work before Choose and Book is illustrated below.

before choose and book

It all seemed quite straightforward: go to your GP, they contact the relevant administration, you get sent an appointment in the post and attend. If the date sent is inconvenient, you phone and agree a new one.

Now look at my (simplified) recent experience of Choose and Book below.

the reality of Choose and Book

I’ve cut out some of the extra steps involved (such as the arrival of duplicated letters). And the way that the system seems designed around unique booking reference numbers, rather than me as a citizen/patient. And the way it insists on generating and sending letters without any option to let me use email or SMS or anything else that would actually save the NHS time and money. I’m struggling to understand the point of a system that adds steps to a process and still leaves the old paperwork in place. Net result: there is little choice of booking and it generates more paperwork (and hence cost) and involves more processes than the system it replaced.

The new system seems destined to become a case study in inept design and management. It has failed to reduce complexity, or to simplify systems and processes and hence help improve outcomes. More worryingly, I do not understand how Choose and Book reflects clinical need: how does this system know which of its users have the most pressing needs and therefore should be given priority in the tool? From speaking with my GP, I understand it doesn’t: for that, the GP has to get back on the phone and ask for appointments to be moved.

I  seriously question what problem Choose and Book thought it was trying to solve. IT is not the answer to every problem. Least of all when it is put into place without being properly integrated into the wider design of a public service. The referral  system seemed to work reasonably well before. Improving it with well-designed IT would have been useful, and could have been done simply, quickly and cheaply. But this has not happened.

If Choose and Book serves any purpose, it is to put the lie to repeated  claims of “lessons learned” and “never again” when it comes to public sector IT failures. And that is what dismays and irritates me more than the Choose and Book system itself. It’s like a throwback to all that was wrong with poor, big bang, bloated information systems design in the late 1990s. It’s as if the last decade of agile, nimble, cheap IT never happened. More than 10 years ago I was involved with  projects that rapidly iterated potential solutions with end users and delivered mass scale systems in just 90 days that went on to support millions of users. Such capabilities are nothing new, just depressingly absent from programmes such as Choose and Book it seems.

So, what’s my prescription to fix? Firstly, an admission of the obvious: that it’s just not working properly. Secondly, a blunt review of what the real business objectives are and how/whether they can be met, what is needed etc. Thirdly, presuming a decision that at least some IT could help reduce NHS costs and bureaucracy (if well designed….) a “90 days to fix” open and collaborative campaign, bringing in GPs, consultants, administrators, users, citizens and hactivists, to rapdily prototype how it could and should be. Throughout those 90 days alternative interfaces, systems, channels, processes and user experiences can all be explored and proven, or dropped.

At the end of the 90 days, hard decisions will be needed. Decisions about whether the new agile models and preferred solutions output from the 90 days can dovetail into and help fix and improve Choose and Book. Or whether it’s best terminated and a new rapid alternative installed instead, cheaply, efficiently and effectively.

You know what I suspect the biggest challenge will be? Getting to step 1. But if those behind Choose and Book would only bite the bullet, I can’t help thinking we’d all end up in a much better place.