1 BCS-NPfIT - 7 Feb 2008 Taking Stock Brian Randell

2 BCS-NPfIT - 7 Feb 2008 A Disclaimer I am not myself a specialist in medical IT systems – I became interested in NHS’s National Programme for IT (NPfIT) in April 2006 when I was invited to sign an open letter to the Select Committee on Health calling for an inquiry into the programme's plans and progress. Since then, I have found myself spending a considerable amount of effort on tracking NPfIT, and assembling a dossier of published concerns related to it. Why am I doing this? The main reason is that I care deeply about the NHS. Indeed, without it (in particular Newcastle's two main hospitals) I wouldn't be here today. I am very supportive of the general aims of NPfIT, but have become increasingly concerned at what I have been able to find out about it, in particular about those aspects concerned with what are variously called electronic patient records (EPRs), or electronic health records (EHRs). In 2000 I helped initiate the 6-year 5-university Dependability Interdisciplinary Research Collaboration (DIRC) on the reliability and security of computer-based systems (i.e., systems made up of computers and people). Much of DIRC’s research concerned healthcare systems, including EPR systems. It sensitized me to the importance of socio-technical issues in system design, and has greatly coloured my attitude to NPfIT.

3 BCS-NPfIT - 7 Feb 2008 NPfIT - in one slide! A 10-year project, launched in 2004, intended to serve “40,000 GPs, 80,000 other doctors, 350,000 nurses, 300+ hospitals, 50m+ patients, and 1.344m healthcare workers” The Programme is (or rather was – see NLOP) largely the responsibility of a set of so-called Local Service Providers (LSPs) - CSC, BT, Fujitsu and (until Sep 2006) Accenture, each responsible for one or more “Clusters” (each concerning healthcare IT services for a population of about 10 million patients). A (completely novel) major focus throughout has been on the bringing together birth-to-death EHRs (initially a full, later just a summary record) for the entire English nation, into a set of just five interlinked “local” hosting centres, one per regional cluster of health trusts, as part of a “National Care Records Service.” But: “There was never a business case made for a national EHR. The real benefits of clinical IT is in the use of computerised decision support and local shared records.” [Frank Burns] By early 2006 there were many indications that, though some other aspects of the Programme were making progress, the EHR/EPR plans in particular were in trouble.

4 BCS-NPfIT - 7 Feb 2008 NHS23NHS23 NHS23 is the name acquired by the group of 23 computer science and systems professors who were signatories to the April 2006 open letter to the Health Select Committee. Further letters, and a suggested draft terms of reference for the suggested open independent review, were sent by NHS23 during In January 2007 we distributed a 212-page “Dossier of Concerns” to 160 parliamentarians and officials. The Select Committee reversed its earlier refusal, and in February 2007 announced an inquiry into “The Electronic Patient Record and its Use.” NHS23 provided written evidence to, and testimony at, their hearings in June 2007, and – at their request – further written evidence (on the impact of independent reviews of other large software projects). NHS23 members have taken part in numerous conferences and workshops. The online version of the NHS23 dossier has now grown to over 350 pages. The Select Committee’s Report contained many criticisms of NPfIT, and recommended various specific reviews, but not the sort of overall independent technical review that we still argue is needed.

5 BCS-NPfIT - 7 Feb 2008 Our Evidence to the Select Committee Inquiry The evidence I submitted on behalf of NHS23 to the Health Select Committee’s Inquiry into the “The Electronic Patient Record and its Use” listed a large number of generic problems encountered in large software projects, and stated: “We find it quite remarkable, and extremely worrying, that our Dossier shows that all of the above lengthy list of generic system problems would appear to exist in NPfIT.” Our main comments regarding EPRs were: “Virtually all the claimed clinical advantages for patients of centralised EPRs (at cluster or national level) could be achieved by replacing paper records with electronic ones at the local (i.e. trust) level.” “The claimed importance of being able to access a central EPR directly when a patient requires treatment far from home is not supported by evidence.” “Making what could have been local record keeping part of a cluster-level, leave alone an immense national-level, “system-of-systems” introduces system interdependencies that, because of their effect on system complexity, pose risks to system reliability and availability that in our judgement are likely to prove out of all proportion to any potential benefits.” “The integration of EHR files at cluster, leave alone national, level greatly exacerbates the problem of maintaining patient confidentiality.”

6 BCS-NPfIT - 7 Feb 2008 Testifying to the Inquiry An interesting experience! Beforehand I put much effort into, and obtained much help in, identifying the Select Committee’s likely questions to me, and preparing suitable answers. Thanks to the committee members’ constructive questioning, I was able to make just about all the main overall points about NPfIT that NHS23 had helped formulate, which concerned: Centralization, Evolutionary Acquisition, Socio-Technical Issues, and Constructive Reviews. Subsequently I turned my preparatory notes into the paper: “A Computer Scientist's Reactions to NPfIT”, Journal of Information Technology, 22, 3 (Sept 2007), pp In what follows, I first provide - and look back on - the summaries given in this paper of these four main points.

7 BCS-NPfIT - 7 Feb 2008 CentralisationCentralisation Pulling lots of data together (for individual patients and then for large patient populations) harms safety and privacy it is one by-product of excessive use of identification when in fact all that is usually needed is authentication. Large centralized data storage facilities can be useful for reliability, but risk exchanging lots of small failures for a lesser number of much larger failures. This applies especially to security. A much more decentralised approach to electronic patient record (EPR) data and its storage should be investigated. So, what is the impact on this of NLOP?

8 BCS-NPfIT - 7 Feb 2008 NPfIT Local Ownership of Programme (NLOP) (Announced late 2006, implemented gradually during 2007.) Clusters are allegedly no more, but LSPs continue to exist This leaves “strategic health authorities and NHS trusts to take more responsibility for defining the requirements and design of NPfIT products, and their subsequent delivery and implementation”. Connecting for Health will continue to be responsible for NPfIT commercial strategy, contract negotiations, specialist technical functions and overall finance. Some staff and resources transferred out from CfH. “Local ownership and local buy-in are very important, but responsibility without power has little benefits.” [Charlotte Atkins MP, a member of the Health Select Committee] A cynical view - NLOP stands for “No Longer Our Problem.” The notion of “local” in NLOP is apparently still far above that which would adequately alleviate the centralisation problems that we and others have identified.

9 BCS-NPfIT - 7 Feb 2008 Evolutionary Acquisition Specifying, implementing, deploying and evaluating a sequence of ever more complete IT systems is the best way of ending up with well-accepted and well-trusted systems especially when this process is controlled by the stakeholders who are most directly involved, rather than by some distant central bureaucracy. Thus authority as well as responsibility should be left with hospital and general practitioner trusts to acquire IT systems that suit their environments and priorities subject to adherence to minimal interoperability constraints and to use centralized services (e.g., for system support and back- up) as if and when they choose. NLOP comes too late, and provides merely for a limited degree of choice among specified “complete” software offerings, so would seem to be of little relevance to this issue.

10 BCS-NPfIT - 7 Feb 2008 Socio-Technical Issues Ill-chosen imposed medical IT systems impede patient care, are resisted, result in lots of accidental faults, and lose user support and trust. All these points are attested to by rigorous studies involving expertise from the social sciences (psychology, ethnography, etc.) as well as by technical (medical and computer) experts. Much more attention needs to be paid to such studies, and more such studies encouraged (Section 12 of our online dossier, at provides details of many recent studies.) NLOP provides the possibility of a modest degree of additional control over socio-technical issues, but far less than has been shown to be effective in situations where systems specification and development have been the responsibility of the clinical as well as the IT staff of an individual hospital - e.g. Frank Burns’ Wirral project.

11 BCS-NPfIT - 7 Feb 2008 Constructive Reviews A constructive expert review, working closely with Connecting for Health, could be very helpful (but must be evidently independent and open and thus essentially different in nature to past and current inquiries). A review of this nature could recommend appropriate changes of plan, and speed progress. It could also contribute to the vital task of helping to restore the trust and confidence of the public and the media in the programme and in the government officials involved At the Select Committee’s request, we provided supplementary evidence containing details of a number of well-established software project review schemes, such as: The DERA (now Qinetiq) review of the UK’s En-Route Air Traffic Centre (Swanwick) software project. The UK MoD Annual Major Products Review The US DoD Tri-service Assessment Initiative The NASA Post-Challenger review But all to no avail - as yet!

12 BCS-NPfIT - 7 Feb 2008 Further Issues – 1 EPR Data Quality Further Issues – 1 EPR Data Quality Patient safety considerations indicate a need to design EPR systems in such a way as to ensure (or at least to encourage) high data quality. The best way to achieve this is to arrange that EPRs be created and updated – as far as possible completely automatically – as an immediate by-product of standard clinical activities, so that these activities can directly benefit from such data capture, for example, through the immediate detection of prescription errors. In contrast, EPR data that is collected afterwards and that is mainly used just for other purposes such as statistical analyses and research (e.g., summary care records) will never be of the same quality, or utility, because it will be of much less concern or interest to the clinicians. The collection and maintence of this data may even come to be viewed by clinicians as just an unjustifiable bureaucratic burden.

13 BCS-NPfIT - 7 Feb 2008 Further Issues – 2 Identity Management Large commercial and government organizations assume that it is their responsibility and right to collect, own, and exploit identity information about the general public, subject only to the Data Protection Act. The alternative view is that individuals should be the owners and managers of their identities, exercising control (subject to legal safeguards) as to who is allowed to see and make what use of information about them. This more modern citizen-oriented view leads naturally to being careful to distinguish between ‘identification’ and ‘authentication’, and to use the former only when necessary, under very strict legal and technical controls. Centralised identity management, and excessive use of identification when authentication would have sufficed, is inherently dangerous from the point of view of privacy protection, avoidance of identity theft, etc.

14 BCS-NPfIT - 7 Feb 2008 Further Issues – 3 Security Failures Most security failures are not due to inadequacies in the security mechanisms employed, but to failures (such as software bugs) in the IT system in which they are employed, or through the actions of people involved with the system. All experience to date makes it very evident that with huge systems of the type planned, with very large numbers of authorized users, patient records would frequently be divulged (or corrupted, lost or rendered inaccessible), on occasion on a grand scale. It is therefore critical in determining what services are to be provided by a system to consider how the surrounding organisation will manage to cope when the system fails. And to have procedures in place beforehand by means of which victims can gain prompt redress, and those responsible can be traced and penalised.

15 BCS-NPfIT - 7 Feb 2008 Further Issues – 4 Public Trust Trust is gained slowly and can be lost abruptly – e.g. by losing 25 million unprotected personal data records! The general public needs to trust not just the NHS IT systems, but also the medical staff or government officials (present and future) who control these systems. They need believable reassurances concerning what other systems (inside and outside the NHS) will be allowed to have access to the centralised database of summary EPRs, and what other systems will have access to the detailed EPRs hosted by LSPs. The general public's trust in the medical profession, and especially in their own GPs' respect for their privacy, is typically quite high. This provides an excellent basis on which to build, incrementally, an IT system that will also gain the public's trust – providing the system gains and retains the trust of the medical profession. However, if doctors have systems imposed on them, systems that are under some distant control and ownership, then this avenue towards a well-accepted and trusted national health IT system has been largely closed off from the outset.

16 BCS-NPfIT - 7 Feb 2008 Concluding Remarks Concluding Remarks NPfIT has had some significant successes, and has caused a long overdue massive increase in the the NHS’s budget for IT. However NPfIT, and the National Care Records Service in particular, are – or should be planned and viewed as –a vehicle for (carefully-considered and managed) organisational change, assisted by a large scale IT acquisition, not as just “the world’s largest civil IT project”. But an overbearing, centralized, top-down, one-size-fits-all IT project – which is how many see NPfIT – is not how best to achieve organizational change, particularly in an organization of the size, diversity, and complexity of the NHS, especially given the frequent strategy and structural changes imposed on the NHS. And it is unlikely to satisfy the disparate legitimate needs of the many different clinical specialities and environments. Finally, it would be nice to think that the changes that are starting to be made to the way in which the Programme is organised and controlled will continue to the point where they successfully address the many concerns that NHS23, and others, have identified – unfortunately this seems unlikely.