"This is yet another example of a department fundamentally underestimating the scale and complexity of a major IT-enabled change programme. The Department of Health needs to admit that it is now in damage-limitation mode."Now I can't argue with that, the system as proposed was a monster, and whilst it's design may have appeared simple i.e. central database with medical records that every NHS front-line service can access and update, where they've failed is realising that the programme was akin to painting the Forth Bridge. Even if they'd had infinite money and infinite resource by the time they'd have finished the system would be out of date with technology.
The thing is, it could have been so good, it could've even worked if they'd realised not just the scale, but also acknowledged a flaw in their starting assumptions. You see, in principle, the idea of being able to live in London but walk into a hospital in Manchester and that hospital have access to your medical records is not, per se, a bad one. Actually, from the point of view of pure efficiency its a no-brainer how handy such access would be. However, ask yourself this question.... how often would it really be needed?
If you take a pause for thought before getting excited by the wonderful national brilliance of an integrated national system, just think for a moment about how often people really move around great distance when it comes to healthcare. Many people stay in the same town all their lives and may move house but are still in the same geographical areas covered by the same PCT (or whatever the area healthcare coordinator is called at any given time). There will of course be people that get treate3d at different hospitals because of certain conditions, but they are the exception rather than the norm. For the most part people stay local.
This is where the Blair Government got it wrong. This is also where the proposed architectural solution went off the rails. You see, if you assume everyone is constantly moving around then the appeal of a centralised record system sounds more and more like the solution. Never mind the difficultly in migrating already existing data from a multitude of different systems, once you get the idea in your head of the need for a big national system to solve a problem that is not really there you're not going to stop and think about it anymore, you'll just go ahead, and that is exactly what they did.
So how Dizzy, you may be asking, could it have worked you smartarse? Well, without wishing to use too many political clichés, if they'd gone for a bottom-up approach instead of a top-down, and thought about acting locally to affect nationally, rather than acting nationally to affect locally, they could have made the system work. If they'd acknowledged that the "moving patient" was an exception but not the norm, then the scale of the "national" infrastructure would and could have been minuscule, and the amount of investment at a local level with the divergent systems could have been reduced too, here's how.
There are only a few key pieces of information you really need in national infrastructure to make this work, and none of them actually include personal medical records. Everyone treated on the NHS has an NHS ID number, so you need that. Of course, not everyone knows their number without digging out the card, so you need some data to cross-reference it, i.e. a name, DOB and perhaps an address. Finally, you need to know where they're being treated, in other words, the system needs to be able to know where their records are being stored locally. There could be multiple locations but it simply needs to know.
At a local level, what you would have would be whatever system the local level wanted to use, which would, inevitably, also contain the same core information about a patient i.e. NHS number, name, address, DOB, but it would also contain the medical records for that patient. Now, however that system might look, what would need to be developed at the local level is a means of exporting that data to a single file format, and that single file for each customer, which would contain human readable information like pdfs etc rather than information held in a database schema, could be stored in a separate local system that the national system.
So, the situation would occur thus. You are treated at your local doctors and local hospital etc. Each night the local system updates its nationally connected system with a single data file contain everything mapped to an NHS ID. Around the same time the national system queries all these locally held but nationally connected systems and asks the question "do you have any new NHS IDs I don't know about?". If the answer is "yes" the national system updates the "where are the records for NHS ID X stored with the new location?".
The result would be a system where, if a new patient appeared, you could query the national infrastructure like a telephone directory. Rather than asking for the record, you ask where the records are, and you go off and get them yourself. Now, don't get me wrong, this system is not infallible, it is by no way perfect either. What's more you will have to find way to avoid having repeating data.
The point is, instead of having a centralised database with all the information on it and having to go through a lengthy migration by which time the system you've built is not fit for purpose, what you instead have is a system that is decoupled and local, but has the scope to provide information and talk nationally on the odd occasion that it necessary by making the "national" but be a type of middle-ware lookup-layer. The real beauty of this approach is it fits well with an agile type framework and gradual roll-out. You would be able to deliver workable solution rapidly with pilots, and introducing new local systems would not require intensive and massive data migration work for which the resource cost would be huge.
Of course, none of this is going to happen so I'm not sure why I wasted my time writing it :-)
No comments:
Post a Comment