I was a junior doctor when the national programme for IT was announced. I had recently learnt to develop in C for the Palm Pilot and I was genuinely excited. Imagine if I could get the test results to sync to my palm! You would not believe the amount of actual legwork that was required to walk (and sometimes run) around the hospital to order tests, take bloods, get test results and write them in the notes. I had spent years at medical school only to become a glorified personal assistant to the medical team, and I had already realised that 90% of my job could be automated - which could free me up to actually improve my ability to diagnose and treat patients.
When a request went round to join the junior doctors' committee for The National Programme for IT (NPfIT), I jumped at the chance. What followed was fascinating if incredibly frustrating. First off, NPfIT did an incredible job of not defining what it was. Many of us quickly reached the conclusion that we needed to clearly define what a medical record was, and agree on some sort of specification. I was hoping we doctors would be consulted on this, and I was delighted to help when the opportunity arose.
The junior doctors' committee was a small part of a much larger engagement that broadly revolved around three different groups: the Clinicians, the Executives and the Vendors. I'm overgeneralising here - but you get the gist.
The Clinicians would meet and the more experienced members were highly sceptical about what, if anything, could actually help, and some would even try and repurpose meetings to focus on existing local projects that had stalled, while us younger members would patiently ignore these concerns and engage with the process and try to understand the (strangely opaque) details of what was being proposed.
The Executives, who I will divide into those who worked for the centre (central government) and those who worked for the hospital, would try to organise and manage the plan, budget, paperwork etc. This was the group that was under the most pressure (increasing towards the centre) and was the group most motivated to see the project succeed, working hard to gain consensus and keep the project moving.
Lastly, the Vendors would be invited to select meetings to ask questions, gather requirements and give demonstrations. I would later discover that a demonstration or demo was not (in the industry) necessarily considered to be the same thing as an actual demonstration of the product, but more a representation of what could be delivered, with varying degrees of mocked-up data, user interface features and integrations.
As I learnt more about software development (on my Palm Pilot), I started to see the vast potential of how mobile computers could help, and I became increasingly excited about what we could build. But as the meetings went on, it became clear that this was not something that we were going to build but was something we were going to buy. Something already built, tried and tested, off-the-shelf.
What I observed in those meetings I would later see played out again and again over my career, from different perspectives, in different organisations, but always the same general pattern.
The main mechanism for change within the public sector is procurement. Everything flows from it. If it's not business-as-usual, it's a project and a project needs a business case, and a business case must be costed, and that cost, if large enough, (and structural changes are always large) needs to be procured. Our system is set up to buy things, not build them. Procurement seems to be the only lever of change.
But procurement is a fundamental part of our system because it's important. This is our government and civil service, spending public money, and it's important that people be held accountable for the appropriate use of public funds. Without it, we risk uncontrolled spending and a significant opportunity for corruption - which according to Transparency International UK may well have happened far more during the COVID pandemic, when procurement rules were relaxed, than many would like to admit.
But even though procurement may prevent corruption, procurement does not support innovation. If we want to truly reform our public services, this is a problem we can't ignore. And it's not just in healthcare - anyone who is in the military will also recognise this issue, and I challenge anyone in healthcare to watch this video on "how procurement destroys armies" and not acknowledge it's the same problem.
I've heard it said (perhaps paraphrasing Joseph de Maistre) that
"in a democracy the people get the government they deserve"
and I think of this quote as a reflection of the gap between what people say they want and what they end up with.
We can think of our public services in the same way. Everyone within the system wants things to improve, money to be saved, things to be easier. But as many of us experience when we engage with our public services, this is far too often not the case. That's not to say that there are not heroic efforts performed on a daily basis by people who genuinely care - but in the words of W. Edwards Deming
"A bad system will beat a good person every time."
Trying to change things within a poorly designed system is hard. If we want better healthcare, education and social justice, we need to improve the design of the system itself. And from my perspective, this should start with improving procurement.