Events like UKHealthCamp give you an opportunity to meet lots of cool people who are on a mission to make a real difference in healthcare using digital.
I’m currently working with NHS England doing exciting digital things but have spent a large part of my career working for a commercial software supplier to the NHS – for this reason I’ve often been quick to fly the ‘suppliers aren’t all evil’ flag (#notallsuppliers #notallevil). A lot of the time, I’ve met a fairly defensive reaction to this.
It’s worth clarifying that this is absolutely not a post in defense of big software suppliers, and the message is not intended to be “big suppliers are the answer to our digital health needs” (likewise it’s not saying they can’t be) – it is simply acknowledging the fact that they are a significant and established part of our digital health economy. Sometimes, when we’re trying to change things in a big way, ‘the behemoth suppliers’ become only a representation of what we are desperately trying to get away from, and their place in our discussions doesn’t extend past a punching bag for our criticism and utter disbelief.
If you talk with many of the people who are trying to change things in their field/sector/locality, their stories often feature a chapter like:
We’ve asked our current supplier to make some changes – they said they would do it but two years later it still hasn’t happened.
We tried talking to our current supplier but they just weren’t interested and it wasn’t a high enough priority for them to do anything.
Unsurprisingly, people are disappointed by this, and it just leaves people even more determined to do something better in spite of the suppliers.
Hardly any large software suppliers have entered the NHS market within the last 5 years, maybe even the last 10. The systems that are now handling millions of patient encounters have years’ of development behind them – years of code, years of complexity layered on previous complexity, and at least 3 significant rounds of NHS re-organisations requiring renaming or translation of entire database schemas because a table labelled
in hindsight should have been labelled
This is absolutely not to suggest that all long-running systems are long-in-the-tooth – far from it in a lot of cases – but anyone who has created or maintained complex applications will relate to the fact that the longer an application has been evolving for, the more history there is to consider.
None of this excuses how hard it is to change things – definitely not in fact – but we do need to be careful about dismissing their collective experience.
@lexij pointed out to me:
“You have a great idea to solve some problem, and so you solve it, and then someone with that problem wants to pay you to solve it for them, and now you have a paying customer and a contract, and then more people want you to solve the problem for them too, and now you have more paying customers and more contracts, and then someone’s problem changes slightly and they want you to change how you’re solving their problem, and you ask them to complete a change request so that you can control the impact of the change, and now you’re an evil supplier.”
Every supplier, at some point, started by doing something different and solving a problem for someone.
The NHS is starting to understand how important it is to properly discover the problems that need solving – what is the user need? Pockets of (what I consider to be) better practice are appearing all over the digital health community, and high profile digital projects such as the NHS.UK Alpha are demonstrating how better practice can be applied to real needs. This helps to establish a legitimacy for these practices that in turn provides cover for more pockets of better practice to appear. As part of this important research we accept that we need to understand both what and why and I believe that to help answer the why we need to learn from those who have been at the cutting edge before – those who are already trying to solve the problem and getting there. They may well know why they can’t respond to these needs. So as a suggestion, how about we have some conversations asking:
“Why can’t you change your system to meet our need? Do you agree that it is a valid need? If not, why not?”
“What would have to happen so that you could change your system to meet our need?”
“What things stop you from being able to rapidly adapt? Why aren’t you getting ahead of the curve?”
I think we’d probably get some answers including phrases like “fixed contractual deliverables, contractual penalties for not delivering x and y, too many higher priority requirements already in the backlog, no clear return on investment, no clear sign that people need it…..” and many more. Surely all suppliers aren’t just so lazy that they all work from the same list of ‘excuses’ are they? There’s more for us to understand here – we might just be responsible for creating this inflexible environment.
Clever people are looking after these well-established products, and as @lexij also pointed out
“they’re just people – people who just happen to work for a commercial software supplier”
I’d be surprised if they didn’t have some useful perspectives on this stuff, and if we can try and capture some of that experience in our discovery we will almost certainly be more successful in changing things for the better.