NHS IT Systems

Uber-systems don't work. The internet is testament to the value of having a distributed system built with components from multiple vendors inter-operating through common protocols. With that in mind I was happy to see the Conservative response to their independent report on NHS IT. While I haven't finished reading the full report I have been through the key conclusions and the policy response. The idea of getting rid of the centralised nightmare that the current government is wedded to and returning control of IT procurement to the consumers (i.e. the healthcare providers) makes perfect sense. The push for interoperability and multiple suppliers is all good stuff as is the nod to allowing open source solutions to compete on a level playing field.

It will be interesting to see what the political responses will be to the plans. The current line seems to be about how patient confidentiality can be kept. In that response seems to be an implicit idea that you can secure a centralised system better than multiple ones. In reality of course the problem is a lot more complex than that. Central solutions do provide a single point of failure where the entire database can be compromised. However if you remember the Child Benefit fiasco the reasons for failure where human and not technical. If you divide your data amongst 152 systems each with the attendant reduction of people with access to it you dramatically reduce the chances of a catastrophic failure. However it is still possible that an individual PCT could have a technical flaw that leaks confidential data. It won't be much comfort to those that are affected but the consequences will be a lot more manageable than if all medical records had been involved.

I suspect the biggest headache will be caused by the laudable goal of giving people access to their own data. If all that is required to access your records is a username and password we can expect a number of leaks caused by bad passwords and/or comprised user machines running keyboard sniffers. I hope some sort of hardware token approach is mandated in the minimum requirements* to help mitigate the problems.

All in all this is a policy I can happily support.

* I'd prefer tokens that don't need to connect to a computer to work, eliminating the trap of only being supported by some operating systems. For example my bank token is totally self contained and only needs to read my ATM card and display some numbers I enter into the web-form when I log in.