There are some important lessons that can be learned by organisations across Health and Social Care because of the recent NHS ransomware debacle. Whilst the headlines have been taken up by the preparedness of the NHS the basic principles should impact all organisations.
Although the breakdown of NHS IT looks catastrophic it is fairly easy to understand why it has happened. Many have glibly pushed blame between NHS Trusts, the Government and Microsoft. Whilst there is responsibility with each of them it’s, not surprisingly, a bit more complicated.
Many people will wonder why such large organisations as NHS Trusts are still running systems, like Windows XP, that have long been retired by Microsoft.
One of the reasons that Windows XP lingers is the need to support legacy systems. Some medical devices were built by third party companies and only have drivers that operate on Windows XP. Those companies might have gone out of business, they might not be able to justify the cost of redeveloping old software for new operating systems. Either way it means that Trusts continue to run operating systems that pose a risk to the wider IT environment.
Much has been made of the Government’s decision, in 2014, to finish an agreement with Microsoft to continue supporting Windows XP. I have some sympathy with the Government on this. The advice to Trusts was not that Windows XP would no longer be supported, just that they should make their own arrangements with Microsoft. I think it’s reasonable that the need for support should be focussed on those Trusts that still require it. It’s then for them to decide whether it is more cost effective to retire legacy systems or maintain support. It seems that was a decision that was not taken by a number of Trusts.
In times of austerity the instinct has been to focus on making savings in back office functions. That is understandable but, potentially, a false economy. If a frontline service is reliant on using any sort of electronic system, then IT failure will bring the ability to provide a service to a halt.
The problem of addressing this is linked to the difficulty in conceptualising the worst-case scenario. The cost of upgrading systems in organisations with thousands of PCs is vast. It isn’t just the cost of software. There is the cost of project management, checking asset registers, testing dependencies and trying to do all of that without shutting down front line services. It’s difficult for people who are allocating scarce resources to justify spending that sort of money on something that “might” happen. Well, it was difficult, it’s probably less so now.
Maintaining investment in your IT systems also requires you to understand how those systems work and the risk of their failure. This is about getting a sense of the true cost of maintaining investment but also the true cost of recovery.
What can we learn from this? I think there are three important lessons that even the smallest health and care organisations can learn.
The most obvious being, keep things up to date. Last year Microsoft gave everyone, with a legal copy of Windows, the chance to upgrade to Windows 10 for free. Leaving aside the problem of legacy systems, everyone should have taken that offer up. If you didn’t then you need to consider buying the upgrade now.
You need to think about what the long-term plan is around the systems you buy in to support your business. What is the risk of failure? What is the cost of failure? What will you do if the vendor goes out of business? One way of managing this risk is to invest in systems that use Open Source software. If the code is available then it is much more likely that you will be able to continue to manage your systems in the future. Closed systems, especially with small suppliers, are vulnerable.
Finally, you need to understand were your data is being stored. If you are keeping it on your desktop PC, with limited or no backups then it is vulnerable. Where possible, try and maintain your data in the cloud (someone else’s computer) with regular backups.
As with any part of your organisation, you need to fully comprehend the risk of it failing. Understanding the risk does not mean that you need to fully understand the technical process, but equally you cannot ignore the risk because it sounds technical.