Taking Stock Brian Randell

1
Taking StockBrian Randell
2
A Disclaimer

• I am not myself a specialist in medical IT
  systems I became interested in NHSs 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 DIRCs 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
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
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.
• 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.
• 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 Committees 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
Our Evidence to the Select Committee Inquiry

• The evidence I submitted on behalf of NHS23 to
  the Health Select Committees 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
Testifying to the Inquiry

• An interesting experience!
• Beforehand I put much effort into, and obtained
  much help in, identifying the Select Committees
  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.

7
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?
8
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
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
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.

11
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 Committees 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 UKs
  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
Further Issues 1EPR 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
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
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
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
Concluding Remarks

• NPfIT has had some significant successes, and has
  caused a long overdue massive increase in the the
  NHSs 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
  worlds 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.