By Tony Collins
Today the National Audit Office reports on the General Practice Extraction Service, an IT system that allows patient data to be extracted from all GP practices in England.
The report says that Department of Health officials – who were then working for the NHS Information Centre – signed off and paid for a contract even though the system was unfit for use. The original business case for the system grossly underestimated costs.
And the system was developed using the highest-risk approach for new IT – a combination of agile principles and traditional fixed-price contract.
Some of the officials involved appear to be those who worked for NHS Connecting for Health – the organisation responsible for what has become the UK’s biggest IT-related failure, the £10bn National Programme for IT (NPfIT).
As with the NPfIT it is unlikely anyone responsible for the latest failure will be held accountable or suffer any damage to their career.
The NAO says officials made mistakes in the original procurement. “Contract management contributed to losses of public funds, through asset write-offs and settlements with suppliers.” More public money is needed to improve or replace the system.
Labour MP Meg Hillier MP, the new chairman of the Public Accounts Committee, sums up today’s NAO’s report:
“Failed government IT projects have long been an expensive cliché and, sadly for the taxpayer and service user, this is no exception.
“The expected cost of the General Practice Extraction Service ballooned from £14m to £40m, with at least £5.5m wasted on write-offs and delay costs.
“GPES has managed to provide data for just one customer – NHS England – and the data was received 4 years later than originally planned.
“While taxpayers are left picking up the tab for this failure, customers who could benefit, such as research and clinical audit organisations, are waiting around for the system to deliver what they need to improve our health service.”
Some GPs who do not want patient data to be extracted from their systems – they believe it could compromise their bond of confidentiality with patients – may be pleased the extraction system has failed to work properly.
But their concern about patient confidentiality being compromised will not make the failure of the extraction service any more palatable.
The NAO says it only learned of the failure of the extraction system through its financial audit of the Health and Social Care Information Centre. It learned that the system was not working as expected and that HSCIC had agreed to pay additional charges through a settlement with one of the main suppliers, Atos IT Services UK Ltd.
An NHS Connecting for Health legacy?
Work on the GP Extraction Service project began in 2007, first by the NHS Information Centre, and then by the HSCIC.
The NHS Information Centre closed in 2013 and responsibility transferred to the HSCIC which combines the Department of Health’s informatics functions – previously known as NHS Connecting for Health or CFH – and the former NHS Information Centre.
What went wrong
The original business case said the extraction service would start in 2009-10, but it took until April 2014 for HSCIC to provide the first data extract to a customer.
Meanwhile other potential users of the system have found alternative sources of patient data in the absence of the HSCIC system.
The NAO says that officials changed the procurement strategy and technical design for the GPES extraction systems during the project. “This contributed to GPES being unable to provide the planned number and range of data extracts.”
The NHS Information Centre contracted with Atos to develop a tool to manage data extraction. In March 2013, the Centre accepted delivery of this system from Atos.
But officials at the HSCIC who took over the system on 1 April 2013 found that it had fundamental design flaws and did not work. “The system test did not reflect the complexity of a ‘real life’ data extract and was not comprehensive enough to identify these problems”.
To work in a ‘real life’ situation, the GPES query system needed to communicate accurately with the four separate extraction systems and other systems relying on its data. The test officials and Atos agreed was less complex. It did not examine extractions from multiple extraction systems at once.
Nor did the test assess the complete process of extracting and then passing GPES data to third-party systems.
Fixed price and agile – a bad combination
Officials began procuring the GPES query tool in April 2009, using a fixed-price contractual model with ‘agile’ parts. The supplier and officials would agree some of the detailed needs in workshops, after they signed the contract.
But the NAO says there was already evidence in central government at this time that the contractual approach – combining agile with a fixed price – was high risk.
The NAO’s report “Shared Services in the Research Councils”reviewed how research councils had created a shared service centre, where a similarly structured IT contract failed.
In the report, Fujitsu and the shared service centre told the NAO that: “the fixed-rate contract awarded by the project proved to be unsuitable when the customers’ requirements were still unclear.”
The court case of De Beers vs. Atos Origin highlighted a similar failure.
To make matters worse officials relied too heavily on contractors for development and procurement expertise. And 10 project managers were responsible for GPES between 2008 and 2013.
Once health officials and Atos had signed the query tool contract, they found it difficult to agree the detailed requirements. This delayed development, with Atos needing to start development work while some requirements had yet to be agreed. Officials and Atos agreed to remove some minor components. Others were built but never used by HSCIC.
A Department of Health Gateway 4 review in December 2012 found that difficulties with deciding requirements were possibly exacerbated by development being offshore.
They raised concerns about the project management approach:
“The GPET-Q [query tool] delivery is being project managed using a traditional ‘waterfall’ methodology. Given the degree of bespoke development required and the difficulties with translation of requirements during the elaboration parts of R1, the Review Team considers that, with hindsight, it might have been beneficial to have adopted an Agile Project Management approach instead.”