Clinical Informatics

Information System Failures and the NHS


  1. Introduction and Context of Information Systems Failure at large and in the NHS

  2. The Definition of Information System Failure

  3. The causes of Information System Failure

    1. Pre-implementation
    2. During Implementation
    3. Post-implementation

  4. Managing Individual and Organisational Change

  5. Conclusions

  6. References

The causes of Information System Failure Post-implementation

Declaring victory too soon:

The maximum benefit of a system does not manifest itself completely immediately after the implementation. Also there tends to be more need for technical support in the initial stages.

Hence it may be detrimental to "withdraw" on funding immediately after implementation of the project in order to save costs.

Adequate resources are actually needed to ensure that the systems continues to have adequate support and development as further fine-tuning issues are identified during its use in the real world. Iteration is an essential part of software and Informatics Systems development.

Although off-the–shelf solutions are thought to be more economical as they do not need “in-house” development, funding and resources; they run the risk of "vendor tie-in" as they may be the only party able to provide the necessary support or access to the operating system, applications and databases in-use, once these are established with proprietary software.

Hence success in the early stages of implementation may not be sustainable if these companies withdraw or become insolvent or are unable to continue to fulfil their contractual agreements for any multitude of reasons.

The "damage" in such a scenario would be beyond financial terms and may cripple patient-care services nationwide, unless this contingency is fully prepared for as part of the overall risk management process right from the beginning.

Hence, the virtual transfer-of-rights of "cradle to grave" patient data for the whole population of UK via the use of proprietary databases must be thoroughly examined, not only from the commercial point of view but also from the data protection, privacy, perpetual integrity and future accessibility points of view (Douglas Carnall, Opensource Software in Healthcare,2000).

Once the proprietary database for 60 million patients, accumulating data for the expected life-span of 80 years, with all the associated clinical metadata and data-sets is set up, it will be near impossible to transfer this database into a different database, proprietary or otherwise, for whatever reason, without loss of data in the process.

One can hence argue for the merits of "in-house" developed open source software, especially for an entity like the NHS, where the needs are diverse, where change is the only constant and technical support must be available 24/7, for the life-time of the patient, society and as long as the NHS exists.

As the patient, clinician and NHS organisation needs evolve with time, as they must, the open source framework will allow the modification of the source code by NHS staff so that the software and databases can be tailored for each specific temporal and locality needs.

Open source code also allows the continued development of the operating system and applications without fixed tied-in upgrading and support costs.

Furthermore, as open source code do not depend on security via obscurity, it may provide an overall more secure and robust platform for the NHS.

Unlike proprietary software, open source code and applications are designed with open standards in mind, hence facilitating future interoperability between trusts, regions and also on the international front.

It is not clear whether these important concepts were taken into account during the planning stages of the NPfIT. However, they will will be fully tested when the Electronic Patient Record system for the NHS is rolled out.

This is because instead of using the openEHR open source international standard developed by University College of London, it will be based on the proprietary HL7 standard developed in the US. The former, designed from the ground up with the purpose of supporting EHR. The later, a standard that was originally designed for messaging systems, with additional code "bolt-on" to support EHR functions.

Although the openEHR team is working to achieve compatibility with the HL7 standard, compatibility issues is likely to remain in the future. The ramification of this decision is unknown, but is likely to lead to more integration between the health-systems of the US and the UK and "tie-ins" with US private companies.

Failure to learn from previous mistakes:

With each Information System implementation; there will be lessons to be learnt. Mistakes need to be analysed and the experiences need to be shared.

Despite the wealth of knowledge accumulated by researchers in this field, the same mistakes seems to be recurring leading to the Cobb’s paradox:

"we know why projects fail, we know how to prevent their failure, so why do they still fail?" (8)

One explanation could be that the empirical evidence gather has not reached those actively working in the industry.

This brings us full circle back to the need for professional training, continuing professional development and registration with relevant professional bodies in order to regulate and ensure that this happens. (see "UK Wasting Billions on IT Projects", British Computer Society website, April 2004) (1)


This website is certified by Health On the Net Foundation. Click to verify. This site complies with the HONcode standard for trustworthy health information:
verify here.


arrow left arrow right

Page Updated: 17 May, 2017

About Us | Site Map | Privacy Policy | Contact Us | Disclaimer | Acknowledgement | Top of Page |