The History of large Health IT Projects
Only a minority of large Health Information Technology (IT) projects are delivered with functionality approximating that specified by the customer, on time and on budget. There is a significant rate of what can only regarded as complete failures. Given the money spent (usually in the hundreds of millions of dollars) this is a surprising result.
To give a few examples: (1)
UK NHS
The number one project disaster of all time is probably the massive £12 billion plan to create the world’s largest civilian database linking all parts of the UK’s National Health Service. This was initially launched in 2002. The project was in disarray from the beginning, missing initial deadlines in 2007, and eventually being scrapped by the UK government in September 2011.
The nine-year debacle, under the National Programme for IT, was way over cost and years behind schedule due to technical issues, issues with vendors and constantly changing system specifications.
In early 2012, one of the primary suppliers, CSC made a $1.49 billion write-off against the botched project. One report claimed the failed project had cost UK taxpayers £10bn with the final bill expected to be “several hundreds of millions of pounds higher.”
South Australian EPAS system (2)
This system was set up initially in 2 country hospitals and SA Repatriation Hospital in 2012
This was a pilot for a statewide electronic medical records system
It was to be deployed in the new Royal Adelaide Hospital but when the hospital opened the system was unusable and paper records were used. At that time the total published cost was $422M. This can only be regarded as a comprehensive failure, though the SA government sought to ”reset” the project using the same software.
HealthSMART modernisation program
In mid-2008, the Victorian government unveiled its HealthSMART program to modernise and replace IT systems across the Victorian public health sector.
Implementation costs for the HealthSMART clinical ICT system rollout blew out to $145.3 million or 150 per cent more than the original budget of $58.3 million, according to an Auditor-General’s report.
The Auditor-General’s audit report also suggested that the absence of appropriate controls and effective mitigations at certain sites could pose serious safety risks to patients.
MyHealth Record (3)
The Federal Government has been engaged in the development of a National E Health record for more than 20 years in various forms
In spite of the investment of some $1.97B at Jan 2020, it has not achieved a useful universal Health record for all Australians.
Some 23M records had been created with half of these holding no data. Of those with data many are incomplete or not useful.
The uptake by the public has been limited by concerns about privacy. It appeared that many government agencies were expecting to gain access to the data – this has now been limited. GPs are used to managing privacy – they are reluctant to allow their patient’s data to be uploaded to a system which appeared not to have to same privacy protections as their own systems.
GPs are also expected to manage and curate the data – however there is little provision by Government to acknowledge the cost and legal risk and reward them for doing so
Early in the process there was the rollout of the Public Key Infrastructure (PKI) system. This was intended to allow identification of health providers such as doctors electronically so that billing and other functions could be carried out online. Unfortunately this did not achieve widespread acceptance by providers because it was cumbersome to use and most of the legal risk was placed on providers with an onerous contract. It appeared that the vendors of the system were able to essentially absolve themselves of risk. The provider password was created by the vendor. As the system had the legal force of a signature, some providers were concerned that having a password held elsewhere by an unknown entity was an unacceptable risk to them.
At one point there was an attempt to agree on interface standards between systems. This was never successful because of the commercial disincentives to standardization and the fact the vendors of software systems were not adequately remunerated. Much the money appeared to be spent on conferences, strategic plans and administration.
Summary of reasons
In my view there three main reasons why the majority of these large projects fail either partially or completely.
(1) Complexity
These projects are genuinely difficult. They are large, enterprise level systems with many users, inputs and outputs. This means they are complex in both the mathematical and the lay sense.
Complex systems are difficult or impossible to analyse mathematically. The outcome of a design process is therefore difficult if not impossible to predict. Ideally a designer will adopt an “evolutionary” approach and replace parts of the system progressively while maintaining current systems for redundancy. But these large Health IT systems are designed with a “waterfall” approach – ie specifications are gathered and the system delivered as a “one-off” on a specific “go-live” date.
(2) Commercial reasons
These projects are commissioned by Governments. They are exclusively delivered by large corporations usually for eyewatering sums of money. The source code is invariably proprietary and secret. Interoperability between systems appears to be discouraged by the vendor. In any case it seems impossible to achieve – there are strong commercial reasons for this.
The tendering and contracting process is invariably “commercial in confidence” – this does not allow external scrutiny. The important decisions which will determine the direction of the project are made at the start of the process and in secret. In practice these systems are rarely designed from scratch – they are usually created by adapting an existing system held by the vendor. Inevitably this involves some compromise on the part of the customer as to which specifications are met.
(3) Government/Political factors
These projects are politically risky.
But the large corporation delivering the software can be used as a “Risk Partner” by the bureaucrats and politicians commissioning them.
There is an imperative to deliver a discrete project at a specific time – an evolutionary design process is not politically attractive.
These large projects require specific skills to manage – Government decision making and management systems perform poorly at the best of times – they are generally not up to the task.
I will explore these issues further in a series of posts.
References
(1) Spectacular IT Failures
https://www.bbc.com/news/uk-politics-24130684
(2) SA EPAS system
https://www.abc.net.au/news/2016-11-08/what-is-south-austrailas-epas-patient-record-system/8005334
(3) MyHR
TjilpiDoc 