Taking Stock
Brian Randell
BCS-NPfIT - 7 Feb 2008
1
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.
BCS-NPfIT - 7 Feb 2008
2
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.
BCS-NPfIT - 7 Feb 2008
3
NHS23
•
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.
•
•
•
The Select Committee reversed its earlier refusal, and in February 2007
announced an inquiry into “The Electronic Patient Record and its Use.”
•
•
•
•
Further letters, and a suggested draft terms of reference for the suggested open
independent review, were sent by NHS23 during 2006.
In January 2007 we distributed a 212-page “Dossier of Concerns” to 160
parliamentarians and officials.
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.
BCS-NPfIT - 7 Feb 2008
4
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.”
BCS-NPfIT - 7 Feb 2008
5
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. 222-234.
In what follows, I first provide - and look back on - the summaries given in
this paper of these four main points.
BCS-NPfIT - 7 Feb 2008
6
Centralisation
• 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?
BCS-NPfIT - 7 Feb 2008
7
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.
BCS-NPfIT - 7 Feb 2008
8
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 backup) 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.
BCS-NPfIT - 7 Feb 2008
9
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 http://nhs-it.info/, 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.
BCS-NPfIT - 7 Feb 2008
10
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!
BCS-NPfIT - 7 Feb 2008
11
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.
BCS-NPfIT - 7 Feb 2008
12
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.
BCS-NPfIT - 7 Feb 2008
13
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.
BCS-NPfIT - 7 Feb 2008
14
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.
BCS-NPfIT - 7 Feb 2008
15
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.
BCS-NPfIT - 7 Feb 2008
16