Below is my list of reasons why I think NPfIT failed. NPfIT was the NHS National Programme for IT in health, starting in 2002, with Richard Grainger appointed as NHS IT director. A timeline is published here. NPfIT is generally conceded to have spent £10.7bn by the government in 2013, when it was definitively shutdown. Claims have been made that slightly more than this was delivered in value. Realistic analyses such as the one linked to from the image at the top of this post show that the realised benefits are miniscule. Right now, the benefits for ‘Choose and Book’ can probably also be written off, as it is no longer generally used. I would guess the only benefits that those in the industry would agree were actually realised are N3, the secure NHS network and possibly NHS mail. The Spine supplies some benefits, but is so badly designed and over-complicated that it will undoubtedly be completely replaced in the next 5 years.
My view, pretty uncontroversially, is that the programme was mis-conceived from the start. Here are my reasons, which are by no means complete.
The basic requirements were not understood by those running the programme, even though many are actually fairly obvious. The NHS’s favourite published scenario to solve was a Scottish person on holiday in Cornwall getting sick. However the vast majority of all health system interactions are local. A locally devolved but standardised and federated system architecture was required. Instead a nonsensical centralised system (the ‘Spine’) was devised.
The basic science of interoperability of health information had not been worked out. You have to science before you can do engineering. A 5y industrially oriented research programme should have been funded instead for say £250m
The wrong IT standards were chosen, primarily HL7v3 and CDA. I provided a 25 page report in 2005 as to why they wouldn’t work. And they didn’t. This choice killed the possibility of the main problem being solved by any vendor, even had the requirements been properly analysed.
Not one incumbent hospital system supplierhad a product even remotely capable of communicating information outside the hospital boundary (other than routine lab data). None had any kind of shared health record concept. And yet they were awarded massive contracts to provide a cross-enterprise health record system.
Not one system integrator company had a single previous installation to which they could point as evidence of experience. And yet they got paid massive amounts of public money to blunder about in the dark. I heard accounts of meetings where it was clear that noone had any idea of how to proceed.
Clinical experts were barely consulted. Without deep knowledge of the information and processes of the domain, building a large IT solution is guaranteed to fail.
Critical errors were made in commercial arrangements, resulting in huge payments to corporations such as BT and CSC, with no adequate requirements definition provided by the NHS, and no proof of prior success by the suppliers.
NPfIT was doomed from the beginning, and quite clearly so for some of us who knew anything about the subject matter. I certainly don’t claim to have known how it should have been done back in 2003, and for precisely that reason I would have funded an industrial research programme at a fraction of the cost, to figure it out, including critically assessing health IT standards.
Secondly, I would not have imagined that what was being purchased were ‘solutions’ from corporate suppliers, but instead a permanent development, standardisation and platform-building capability aimed at establishing a component-based supplier economy whose offerings had to obey the platform definition (information models, APIs, domain definitions, terminology etc).
Avoiding this kind of fiasco is not as hard as people think. It requires basic questions being asked and addressed: is the problem space understood? Have the requirements been worked out? Has the basic science of a possible solution been done? Have relevant domain experts been engaged? Have standards been determined and thoroughly tested for fitness for purpose and implementability? Has an affordable pilot programme been set up and monitored? Once all this has been done, then you might possibly consider awarding some large scale contracts, although nothing of the size paid by NPfIT is needed. Much more cost-efficient solutions are possible.
I work on semantic architectures for interoperability of information systems. Much of my time is spent studying biomedical knowledge using methods from philosophy, particularly ontology and epistemology.
Agree with the critical errors 1.GPs had been promised a system of their choice in their contracts (NPfIT contractors expected to use their own systems throughout their region) This resulted in no interoperability of primary and secondary care. 2. No GP system was included in the CSC contract at all!
Yes, I should really have included the GP supplier situation in the list as well – especially as UK GP systems were some of the most advanced health record systems anywhere in the world and the relevant companies and people undoubtedly knew a lot more about the problem space and its solutions that those actually in charge.
Have you had a moment to pass your eye over the Australian myHealthRecord Program. Would love to hear your views,
David, my most recent knowledge of the Aus system is that it was a essentially a bucket of disconnected CDA documents, with an increasingly controversial privacy model. Ignoring the latter, the former means it probably is no better than the UK spine, and has no hope of adequately representing the process picture of a patient’s healthcare for any given episode of illness which would be the one useful function it might try to fulfill.
There is also (AFAIK) no concept that anything in myHR can be treated as a definitive source, e.g. the ‘medication list’ or ‘problem list’ recorded there are just the latest copy of something known inside an arbitrary provider – such copies can easily be incompatible with each other and wrong w.r.t. the patient reality, so either useless or dangerous (probably not too dangerous, since physicians know not to trust the info).
Quite apart from all that, the technical approach (CDAs, and presumably bits of FHIR in more recent times) will not anywhere near flexible enough for the future. No formal representation of patient process / care workflow, hand-offs, etc.
Not much has changed other than all who have not opted out and don’t have one will be given a brand new myHealthRecord – starting in a few weeks time. It is still a secondary aggregation of data held elsewhere and some patient contributed stuff from the few who have actually logged on.
We will now see if giving a record to most of the population assists in getting worthwhile benefits for the $2B or so spent so far. Given over 70% of GPs want nothing much to do with the system the next 12-24 months will be very interesting.
Thanks for your comments – spot on.
Reblogged this on schoutbynacht and commented:
Like post above from David would be interested in your comments on MyHealthRecord program
See response to David above. I may be out of date on myHR though.
I worked in the NHS in IT support just before and after Fijitsu pulled out. What it was trying to do was good – modernize the IT and improve connectivity. When I was there, in Sussex, blood results relied on an ancient 16-bit DOS program. Having software like that later meant that computers couldn’t be upgraded (they needed Windows XP and IE6 to run). So updates weren’t applied and we had WannaCry. The trust I was at still ran NT4.0 servers at the time of WannaCry.
That wouldn’t have happened if the NPfIT had worked, things would have been supported and could have been kept current. However it seemed to me they were trying to do too much, building a big national system when what was needed was local county-wide IT that could communicate.
I’d have stuck to making sure each county moves to AD, then the software could be updated. Gradually improved connectivity, but certainly initially, kept patient data on regional databases while working on standardization and interoperability.