London Ambulance Service
Failure Of A Computer System
The London Ambulance Service
By Steve Cunio
This piece is based on the seminar given by Paul Williams at KPMG's
Manchester office on the 26th of October 1994. Paul was the computer
auditor responsible for auditing the LAS's computer systems after they
failed.
Exactly two years before, to the day of the seminar, the London
Ambulance Service went live with a new computer system. It was to prove
tragic. Newspaper headlines would tell of ambulances failing to arrive
and at least twenty deaths were associated with, although not proven to
be caused by, the failure of the new computer system. As with a lot of
computer systems, this was to replace the old manual system which was
deemed to have become inadequate in meeting the demands of the London
populace. However, as the LAS Enquiry would uncover the manual system
was inadequate but quite the wrong refinement was undertaken. Although
sound in theory, the implementation of the new computer system was
disastrious in the way it was managed. These disasters were documented
in the LAS Enquiry which was first published in February 1993, six
months after the fateful events, as a full public report.
The South West Thames Health Authority, within which sits the LAS,
covers a total of 7 million people, operating the largest service in
the UK. It deals with 5000 patients per day, 2-2500 of these being
emergency calls. The handling of such a number of calls is therefore
critical to the success of the LAS's operations and at the time of the
manual system the targets for efficiency were not being met. Indeed,
the 95% target set to reach a patient within 14 minutes of a call was
at a mere 40% in 1992, the manual system failing, being that it was a
highly inefficient paperbased system. A call would be taken in the
Ambulance Control Room often after having endured a half hour wait on
the telephone queue system. A special form would then be filled in and
placed on a conveyor belt. The forms were then seperated according to
region and an ambulance would be matched to the call by use of a card
system detailing the ambulance status. The card would be passed to the
radio operator who would then contact the ambulance. This messy
procedure prompted the introduction a computer system to speed up the
response time to calls and meet the requirements of the patients'
charter.
The computer system was provided in three main parts - the hardware,
the software and a tracking system. The system installed into the
Ambulance Control Room would be a PC network running under Windows and
the software would be a Computer Aided Despatch System, a
straightforward call taking system. The tracker, an Automated Vehicle
Locator System, would work in conjunction with the network and compute
by triangulation of five radio receivers, the whereabouts of any
ambulance anywhere within 50 metres every 13 seconds. Within the
ambulances the crews were to operate a radio transmitter which would
send the status of each ambulance to the computer program. In this way,
the ambulance best suited to a particular job (and free) would then be
sent a message, displayed on a Mobile Data Terminal for the crew. The
ambulance would then, theoretically, make its way to the stated
destination. This was to happen 90% of the time, the rest of the calls
would need to be handled manually.
The theory was good but in practice absolute chaos ensued. On the first
day calls were lost, many ambulances were sent to the same call and
calls were taking ten minutes to be answered. The plug was finally
pulled on the system after operating for two days. The equipment was
literally stacked in a corner and everyone blamed everyone else. The
hardware people blamed the software people, the computer staff blamed
the 999 crews and politicians put the blame on the Health Secretary,
Virginia Bottomly. Thus an enquiry into the London Ambulance Service
was ordered and a team set up consisting of a representative for the
ambulance service, Don Page, a person from ACAS, Dennis Boyd and Paul
Williams, computer auditor.
Each member of the team conducted their own interviews with all
concerned, interviewing management and staff of the LAS. The interview
process took six weeks to complete. The team also talked to people who
believed that they could contribute to the task at hand, putting
togerther a picture of the two days concerned. From these interviews,
the team learnt how the computer system worked, they gained the
confidence of the staff, tried their best to understand the nature of
the business and stipulated the need to maintain security. They also
called on experts in the fields of radio communications and on the
systems people from other services such as the police force with their
similar systems. They would have brainstorming sessions, interview as a
formal panel, carry out technical analysis and plough through two
filing cabinets worth of related documents.
From this action plan, they would gather that the day was no busier in
terms of the number of patients than on any other day, although there
were many more phone calls, most of which were due to the appaling call
out time. The response time, they would find, was less than 20% of
calls being answered within the 14 minute period. The whole process was
emotionally evocative, the symtons of the this computer system failure,
being extremely saddening. The volumne of the material to be considered
was phenomenal and yet attention to detail and security of information
was of upper most consideration.
From this lengthy process, several conclusions were drawn. The project
was seen to have been over ambitious given the impossible deadlines.
Too much was needed to be done in too short a space of time. The
software contract was signed in August 1991 and the LAS wanted the
system for December 27th 1991. This was duly put back, but only until
January 1992. The tight deadline meant that changes to the software
were made on the fly, so that when problems came to light they were
fixed, but this only confounded the training process making it near
impossible. Secondly, there was no effective project management
although the project itself was supposed to be based around the PRINCE
concepts of project management. Thirdly, sound advice was ignored on all sides. The fire
services warned the management board against the use of the chosen
software house, but the board were misled into believing that the
company had much more experience than was actually so.
The Software House, contracted to develop the software, was
inexperienced in this area and yet was employed due to its inexpensive
services - there was no real comparison of systems due to flawed
procurement procedures. These emphasised the need to get the cheapest
solution and were followed to the letter, no attempt was made by the
LAS to qualify the final choice in terms of value for money and/or
quality of product. The communications system was also unreliable.
There were not enough radio channels and so voice and data shared the
same channel causing loss of time for data to be sent and prompting
more phone calls. The LAS knew this but decided to implement it and see
if they really had a problem confounding the fact that the Locator
System would only work to 50metres in areas not of high buildings and
power cables. Absolutely not the case in London. Also, the backup
system was completely off-line. No-one had even connected it up. If the
computer system had physically shut down there was no adequate recovery
procedure. Matters would have been even worse and even more out of
control than they already were. This was an inexcuseable action.
Many more damning factors were unearthed but many lessons came out of
the enquiry. They found that the following were key elements that
constituted to the main failing of the system.
Produce Systems in Phases - not in one go as was the case here.
Give Ownership of the System - the users didn't like the system as
they preferred the old and familiar way. They were not involoved \
in its design.
Test Supporting Infrastructure.
Ensure Sensible Timetables.
Test Integrated System - particularly before going live.
Crews and Controllers Must Understand Each Others Jobs - effective
control was resigned as crews found they had nothing to do even
when they had been on
standby. They were not aware of the controllers system and if t
hey had been they
could have raised the alarm. Need for joint training to create a
team feeling
Ensure Effective Project Management.
Implement and Test Fallback Procedures.
The failing of this system was multifacted. The production of the full
public and published enquiry being one means to ensure that it never
happens again. At the end of the day it must be realised that the
opertors and the crews always acted in the best interest of the London
populace, burdened with a system they neither wanted nor cared for.
They belived that performance could have been easily improved with a
higher number of staff covering the telephone lines. This is now the
case. They are also back using to the old manual system.
THE FUTURE IS IN YOUR HANDS