• Home Page
Main Index
1992
• Training/Info
• Drugs
LAS
• Drugs
Print
• Slide
Show
• Clipart
& gifs
• Mini
polls
• Poem
Learning
• ECG
• Shock
CAD Failure LAS. 1992
The major objective of the London Ambulance Service Computer Aided Despatch (LASCAD ) project was to automate many of the human-intensive processes of manual dispatch systems associated with ambulance services in the UK.
Such a manual system would typically consist
of, among others, the following functions: Call Taking. Emergency calls
are received by ambulance control. Control assistants write down details
of incidents on pre-printed forms. The location of each incident is
identified and the reference co-ordinates recorded on the forms. The forms
are then placed on a conveyor belt system which transports all the forms
to a central collection point. Resource identification. Other members of
ambulance control collects the forms, review the details on the forms and,
on the basis of the information provided, decide which resource allocator
should deal with each incident. The resource allocator examines the forms
for a particular sector, compares the details against information recorded
for each vehicle and decides which resource should be mobilised. The
status information on these forms is updated regularly from information
received via the radio operator. The resource is recorded on the original
form which is dispatched on to a dispatcher. Resource mobilisation. The
dispatcher either telephones the nearest ambulance station or passes
mobilisation instructions to the radio operator if an ambulance is already
mobile.
The major rationale expressed for such computerisation was typically
that a number of problems existed with the manual CAD systems. Most such
problems related to the time-consuming and error-prone nature of
activities such as: identification of the precise location of an incident,
the physical movement of paper forms, and maintaining up-to-date vehicle
status information.
The basic functionality of the intended LASCAD system was as follows:
British Telecom (BT) operators would route all 999 calls concerning
medical emergencies as a matter of routine to LAS headquarters (HQ) in
Waterloo. 18 HQ 'receivers' were then expected to record on the system the
name, telephone number and address of the caller, and the name,
destination address and brief details of the patient. This information
would then be transmitted over a local area
network to an 'allocator'. The system would pinpoint the patient's
location on a map display of areas within London. The system was expected
to monitor continuously the location of every ambulance via radio messages
transmitted by each vehicle every 13 seconds. The system would then
determine the nearest ambulance to the patient.
Experienced
ambulance despatchers were organised into teams based on three zones
(south, north-west and north-east). Ambulance
despatchers would be offered details of the three nearest ambulance by the
system and the estimated time each would need to reach the scene. The
despatcher would choose an ambulance and send patient details to a small
terminal screen located on the dashboard of the ambulance. The crew would
then be expected to confirm that it was on its way. If the selected
ambulance was in an ambulance depot then the despatch message would be
received on the station printer. The ambulance crew would always be
expected to acknowledge a message. The system would automatically alert HQ
of any ambulance where no acknowledgement was made A follow up message
would then be sent from HQ. The system would detect from each vehicle's
location messages whether an ambulance was heading in the wrong direction.
The system would then alert controllers. Further messages would tell HQ
when the ambulance crew had arrived, when it was on its way to a hospital
and when it was free again
The LASCAD system was built as an event-based system using a rule-based
approach in interaction with a geographical information system (GIS). The
system was built by a small Aldershot based software house called Systems
Options using their own GIS software (WINGS) running under Microsoft
Windows. The GIS
communicated with Datatrak's automatic vehicle tracking system. The system
ran on a series of network PCs and file severs supplied by Apricot.
Systems Options, the company supplying the major part of the software for
the system, is reported as having had no previous experience of building
dispatch systems for ambulance services. The company had won the £1.1
million contract for the system in June 1991.
Under the RHA Standing Financial Instructions which provide the regulatory
frame work within which such procurements may take place, the basic rule
is that contracts such as this have to be put out to open tender. This
requirements was complied with alongside accepting the lowest tender
unless there are "good and sufficient reasons to the contrary"
Over the following weeks several meetings were held with prospective
suppliers covering queries on the full specification and resolving other
potential technical and contractual issues. These meetings were minuted by
the project team and it was clear that most of the suppliers raised
concerns over the proposed timetable - which was for full implementation
by 8 January 1992. They were all told that this timetable was non-
negotiable
Out of all the proposals there was only one which met the total LAS
requirement, including timetable and price. On the basis of the proposals
as submitted, the optimum solution appeared to be the proposal by the
consortium consisting of Apricot, Systems Options and Datatrak
Amongst the papers relating to the selection process there is no
evidence of key questions being asked by the selection team about why the
Apricot bid, particularly the software cost (Systems Options), was
substantially lower than other bidders. Neither is there evidence of
serious investigation, other than the usual references, of Systems Options
(or any other of the potential suppliers') software development experience
and abilities.
The prime responsibility for the technical evaluation of the tenders fell
upon the contract analyst and the Systems Manager. The representative from
Regional Supplies was unable to evaluate the tenders on technical merits
as her
experience was in procurement in its most general sense rather than
specific to Information Technology. A contractor and an arguably
unsuitably qualified systems manager (who knew that he was to be replaced
and made redundant) were put in charge of the procurement of an extremely
complex and high risk computer system with no additional technical
expertise available to them.
However, it seems LAS had previously scrapped a development by IAL
(a BTsubsidiary) at a cost of £7.5 million in October 1990. The latter
project is reported to have started a year late (in May 1987), and it
seems to have been scrapped because of a debate over faulty software. The
LAS sought damages from IAL for a faulty dispatch module in October
1990.Also, it appears that Systems Options substantially underbid an
established supplier (McDonnel-Douglas) and were put under pressure to
complete the system quickly. The managing director of a competing software
house wrote various memoranda to LAS management in June and July 1991
describing the project as 'totally and fatally flawed'. Another consultant
described LAS's specifications as poor in leaving many areas undefined.
In order to prepare the requirements specification for the proposed
new system, a team was assembled under the chairmanship of the Director of
Support Services with the then Systems Manager, a contract analyst, and
the Control Room Services Manager. Other individuals were also involved
representing training, communications and other areas. Because of the
problems at the time with the staff consultation process there was little
involvement at this stage from the ambulance crews, although invitations
to participate were given to union representatives
During the systems requirements process in the autumn of 1990
contact was made with other ambulance services in the West Midlands,
Oxford and Surrey, to determine whether or not their existing systems
might be tailored or extended to meet the LAS vision. All of these were
rejected.
Work progressed on the systems requirements specification (SRS)
which was finally completed in February 1991. The work was done primarily
by the contract analyst with direct assistance from the Systems Manager.
As part of the SRS development a companion paper was produced which
constituted a revised Operational Method of Working aimed at both the
central ambulance control staf fand at ambulance staff. The proposed new
system would impact quite significantly on the way in which staff carried
out their jobs, yet in the case of the ambulance crews, there was little
consultation on this new method of working.
T he SRS is very detailed and contains a high degree of precision on the
way in which the system was intended to operate. It is quite prescriptive
and provided little scope for additional ideas to be incorporated from
prospective suppliers. However, as is usual in any SRS, there are certain
areas that were yet not fully defined. In particular, there were few
details on the relationship with, and interface to, to other LAS systems,
including the communications interface (RIFS) and the PTS system. A
typical despatch system merely acts as a repository of details about
incidents. Communication between HQ and ambulances is conducted by
telephone or voice radio links. In the LASCAD system, links between
communication, logging and despatching via a GIS were meant to be
automated.
The system was lightly loaded at start-up on 26 October 1992. Any
problems, caused particularly by the communications systems (such as
ambulance crews pressing the wrong buttons, or ambulances being radioed in
blackspots), could be effectively managed by staff. However, as the number
of ambulance incidents increased, the amount of incorrect vehicle
information recorded by the system increased. This had a knock-on effect
in that the system made incorrect allocations on the basis of the
information it had. For example, multiple vehicles were sent to the same
incident, or the closest vehicle was not chosen for dispatch. As a
consequence, the system had fewer ambulance resources to allocate. The
system also placed calls that had not gone through the appropriate
protocol on a waiting list and generated exception messages for those
incidents for which it had received incorrect status information. Indeed,
the number of exception messages appears to have increased to such an
extent the staff were not able to clear the queue. It became increasingly
difficult for staff to attend to messages that had scrolled off the
screen. The increasing size of the queue slowed the system. All this meant
that, with fewer resources to allocate, and the problems of dealing with
the waiting and exceptional queues, it took longer to allocate resources
to incidents.
At the receiving end, patients became frustrated with the delays to
ambulances arriving at incidents. This led to an increase in the number of
calls made back to the LAS HQ relating to already recorded incidents. The
increased volume ofcalls, together with a slow system and an insufficient
number of call-takers, contributed to significant delays in answering
calls which, in turn, caused further delays to patients. At the ambulance
end, crews became increasingly frustrated at incorrect allocations. This
may have led to an increased number of instances where crews failed to
press the right status buttons, or took a different vehicle to an incident
than that suggested by the system. Crew frustration also seems to have
contributed to a greater volume of voice radio traffic. This in turn
contributed to the rising radio communications bottleneck, which caused a
general slowing down in radio communications which, in turn, fed back into
increasing crew frustration. The system therefore appears to have been in
a vicious circle of cause and effect. In addition, it was claimed that ar
eorganisation of sector desks over the preceding weekend may have caused
loss of local knowledge.
Claims were later made in the press that up to 20-30 people may have
died as aresult of ambulances arriving too late on the scene. The LAS
chief executive, John Wiley, resigned within a couple of days of the
events described above. A Public Inquiry Report presented the findings of
an investigation into the London
Ambulance Service Computer Aided Despatch System failure.
REFERENCES
Flowers, Stephen (1996), "Software failure: management
failure", Chichester:
John Wiley and Sons, 1996.
Report of the Inquiry into the London Ambulance Service, February 1993.
Simpson, Moira (1994), "999 !: My computers stopped breathing
!", The Computer
Law and Security Report, 10, March - April, pp 76-81, 1994.
ACKNOWLEDGEMENTS
Doug Hamilton, Department of Information Systems, Monash University, PO
Box 197,
Caulfield East Victoria 3145, Australia.
