NPfIT 'misconceived': O'Brien

30 Oct 2008

Shadow health minister Stephen O'Brien has launched a stinging attack on the National Programme for IT in the NHS at Healthcare Interoperability in Birmingham.

O'Brien said he had been surprised to see a "flurry" of stories claiming the programme was "grinding to a halt" in this week's press, since there had been no obvious "hook" for them. But he argued they reflected the "perceptible lack of progress" that it is now making.

In his keynote speech to the conference, he then went further and argued that the programme had always been misconceived. He noted that one of the triggers for it had been Sir Derek Wanless' 2002 review of the likely future spending needs of the NHS for the Treasury, which argued the health service needed to raise spending on IT to business levels.

"He [Wanless] felt that ICT was an important condition for a more efficient health service. The government felt it was a sufficient condition," O'Brien said. Once major IT suppliers had become involved, he added, this had translated into a programme that aimed to "drive" rather than support change in the health service.

"The government was seduced by a dream of IT, instead of seeing it as an enabler of a better health service," he said. The irony, O'Brien went on, was that the Wanless report had outlined an alternative: standards based, interoperable systems focused on delivering better quality care to patients.

Although O'Brien was reluctant to pre-empt the findings of the independent review of NHS IT that the Conservatives have set up under Dr Glyn Hayes, he indicated strongly that he felt this was the way that healthcare IT should go in the future.

However, he warned delegates to the conference and exhibition that "we are not operating in a vacuum" and it might be difficult to untangle the multi-million contractual commitments that the national programme had made.

He also attacked suppliers and the government for "hiding behind this cloak of commercial confidentiality" in relation to programme commitments. "We need information to move forward," he said. "So we say to the government 'give us the information, and if we are wrong, and there is a better way forward, then let's take it."

O'Brien was preceded at Healthcare Interoperability by Brian Derry of NHS Connecting for Health, the agency that runs the national programme. He also stressed that IT should be an enabler of better, safer healthcare, and said the recent Health Informatics Review had recognised this.

He indicated that the implementation report promised in the Health Informatics Review would be published next month. He also argued that a number of factors were in place to support its "vision", including the appointment of a chief information officer for health, Christine Connelly, who started work at the Department of Health towards the end of September.

Lyn Whitfield

Reader's Comments

NPfIT Victim of Complexity

roger@objectwatch.com

30 Oct 08 20:47

I read with interest the recent article in e-Health Insider titled “NPfIT 'misconceived': O'Brien”. I have been following the NPfIT saga for several years now. I have recently written a book about IT complexity, and that in that book I extensively document the problems with NPfIT (National Programme for IT).

The book is titled "Simple Architectures for Complex Enterprises" and is published by Microsoft Press. The entire Chapter 6 is dedicated to analyzing the NPfIT as a case study in unmanaged complexity. In that chapter I show that at least 80% of the complexity of NPfIT was completely avoidable, and that if NHS had taken appropriate steps to manage the complexity of NPfIT at the start of the project, the project could most likely have been completed successfully at less than 20% of current cost estimates.

I don’t agree with Mr. O’Brien that the NPfIT project was “misconceived”. The project was actually a very good idea. It was the plan for delivering the project that was misconceived. In particular, there was no plan for analyzing or managing the overwhelming complexity of the project. The basic tools for complexity management for a project of this scope are functional partitioning, prioritization analysis and iterative deployment, none of which appeared to have been used at all.

In my book, I was forced to conclude the following: “At this point, nobody knows what the eventual cost for NPfIT will be. Estimates range from $48 billion to $100 billion. It seems likely that the project will go down in history as the world’s most expensive IT failure.”

There is also little question that the British tax payers will be paying for NHS mistakes for decades to come. They will pay this cost in pounds and in diminished health care. Some of those tax payers may pay with their lives.

Our best hope for NPfIT is that we learn from its mistakes. The most important lesson to be learned is that on any large project, the main enemy is complexity. In order to control complexity, we must understand the mathematical equations that drive complexity, the models that define complexity, and the formal processes that reduce complexity.

Roger Sessions

Lessons learnt

31 Oct 08 10:17

Re comment 1 Apart from the free advertising, the comments are very apt. The one thing I draw from NPfIT is that lessons are never learnt from mistakes.

Problem was simplicity of objectives

31 Oct 08 13:35

I don't actually disagree with Roger Sessions, but I think the real issue was not having a clear strategic view of what this programme was to achieve in terms of what it did for the business (and that includes clinicians and patients).

It seemed to be conceived as an IT project alone with no more of an objective than 'get in some hardware and software', rather like the earlier GPNet project where GPs were all given broadband links with no idea of what they should link to (EHI wasn't around then!).

It all seemed to happen on the back of the Internet boom (which had actually crashed by then, but the NHS has alway been a bit behind, picking up on management fads just as they are proved not to be the the cure-alls that the consultancies push them to be). There was a sense of putting in some infrastructure and it will all sort itself out - the only problem was that it went beyond infrastructure (N3, Smartcards, etc.) into applications.

The original procurement seemed to be to buy existing state-of-the-art proven systems that were being used effectively and just give everyone one. This was Richard Granger's 'ruthless standardisation'. What is mind-boggling is that what was actually commissioned was software that didn't even exist - even IDX which was supposed to have a proven product at Kensington was allowed to use their next-generation product which had to be binned and IDX thrown out.

Their main sin seemed to have been to have a product that was actually 'just around the corner' which was delivered early enough to be thrown out - to be replaced by a company that didn't have a system ready for some years to come.

Before the Tories throw it out, they need to have a clear strategic vision for how they plan to move forward, both in terms of what the NHS needs and how they plan to support an effective market in healthcare IT products without introducing the usual planning blights (NPfIT being a classic example). Only then can they start applying the very sensible rules of 'simplicity' that Roger Sessions advocates. Otherwise there is a danger that, as always happens with the NHS, just as one set of reforms (no matter how poorly conceived) starts to bear fruit, someone panics and rearanges all the chairs, further delaying progress and wiping out all that has been done. No wonder so many staff resist (or is that sensibly avoid?) change, knowing that in a few years black will be white and white black.

I would add that as a design principle I would put flexibility before simplicity though usually they go hand-in-hand.

Follow the Gourd

03 Nov 08 17:11

"The most important lesson to be learned is that on any large project, the main enemy is complexity. In order to control complexity, we must understand the mathematical equations that drive complexity, the models that define complexity, and the formal processes that reduce complexity. "

What utter codswollop. Rodger you sound like a nice person with a brain the size of a planet but you are simply in space cadet territory mate.

The CRS element of NPfIT was based on an incorrect premise. It was 'massive centralisation will work in the NHS'. Well it doesnt. I dont need a book to tell me that. I predicted the demise of CRS when it started and have been consistently predicting that it will fail ever since. I am also not alone. It will fail no matter how clever you are and failure could never have been avoided. 'Understanding the mathematical equations of complexity' for goodness sake. You did give us all a good larf though.

RE: Follow the Gourd (comment 4)

roger@objectwatch.com

04 Nov 08 17:23

Actually, I am quite serious about the mathematical underpinnings of complexity. Let me give you three examples of why math is important in understanding complexity. First, probability theory helps us understand how partitioning can be used to control complexity. Second, set theory defines exactly what we mean by a “partitioned” system. Third, the mathematics of equivalence relations show how we can drive partitions that are reproducible and testable. While it is true that you can mechanically follow the rules of synergistic (equivalence driven) partitioning without understanding any of this math, my experience is that people design much better architectures if they have at least a rudimentary grounding in complexity theory.

Let me give you an analogy. We would never send a rocket to the moon without validating all of the parameters against mathematical models for gravity, fuel consumption, and planetary motion. However we think nothing of building multi-billion dollar IT systems without validating our architectural models. Complexity analysis gives us a way of asking the question, is a given IT architecture a good architecture?

You rightly criticize the CRS architecture. But the CRS architecture is a Solution Architecture. Complexity management, if it is to be successful, must be well underway long before any solution architecture is begun. Complexity management really falls in the realm of Enterprise Architecture (that is, the juncture point between business and IT). So while I agree with you that the CRS architecture was based on a faulty premise, I disagree with you on what that premise was. I believe the faulty premise was that a system of this magnitude could be completed without a focused complexity management program.

Not to try to take advantage of this for another “free advertisement”, but if you are interested in understanding more of the mathematics of complexity I have a free white paper on the subject at my web site: www.objectwatch.com, white papers, SIP briefing papers, Part II. No cost, no registration, no annoying questions, I promise. Just go and download.

- Roger Sessions

Complex systems

andy.hadley@ferndown.nhs.uk

05 Nov 08 15:19

Not sure I agree with Roger's analysis. There is lots of work on complexity, Plesk springs to mind. The best way to deal from the centre with complex systems is to provide simple tools and to anticipate that they will be adopted, developed and enhanced by real users in ways that you can't predict or direct.

So if the centre get back to mandating the standards that really have to be common, rather than specifying a 'rigidly standard' and as it turns out, poor, way that minutia like how an outpatient appointment will be recorded, then we'll all make much more progress.

In contrast with the central propaganda, other countries are making significant progress in moving their secondary care clinicians to electronic practice. It took GPs 10 years of incremental experimentation to get paperless, and with NPfIT, we have hardly started down the path. Clinicians will need time to grapple with systems and get comfortable with technology.

GPs and computerisation

07 Nov 08 13:31

Of course the reason why GPs use computers and acute consultants dont is pretty straightforward. GPs get paid to make sure that the data is right. Consultants dont