Information Systems Failure: The Case of Computer-Aided Dispatch (Cad) System at London Ambulance Service 1. Introduction The LAS covers a geographical area of just over 600 square miles and handles emergencies for a resident population of 6.8 million people. The CAD project is one of the most frequently quoted UK-based examples of information systems failure that took place in early 1990s. The prominence of this particular case is due to the ‘safety critical’ nature of this system and the claim that 20-30 people may have lost their lives as a result of CAD failure.
2. Description of the Manual Dispatch System The manual dispatch system consists of: a) call taking, b) resource identification, and c) resource mobilization. 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 are recorded on the forms. The forms are then placed on a conveyer belt which transports them to a central collection point.
Resource Identification: Other members of ambulance control collect the forms, review the details on the forms and 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 mobilized. 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 then passed on to a dispatcher. Resource mobilization: The dispatcher either telephones the nearest ambulance station or passes instructions to the radio operator if an ambulance is already mobile.
A number of problems exist with the manual dispatch system. Most problems are 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. Therefore, a Computer- Aided Dispatch (CAD) system was considered as a solution to overcome these problems. 3. The Computer-Aided Dispatch System 3.1 Purpose The objective of the CAD system was to automate many of the human-intensive processes involved in the manual despatch system.
3.2 How the CAD system was intended to work The essential features of the CAD system are shown in Figure 1 which illustrates how the system was intended to work in practice. British Telecom (BT) operators would route all 999 calls concerning medical emergencies to LAS headquarters. A total of 18 ‘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 LAN to an ‘allocator’. The system would pinpoint the patient’s location on a map. The system was also expected to monitor continuously the location of every ambulance via radio messages transmitted by each vehicle. The system would then determine the nearest ambulance to the patient.
Figure 1: The structure of CAD system at LAS
Experienced ambulance ‘dispatchers’ were organized into teams based on three zones (south, north-east, and north-west). Dispatchers would be offered details of the three nearest ambulances by the system and the estimated time each would need to reach the scene. The dispatcher would choose an ambulance and send patient details to a small terminal screen located on the dashboard of the ambulance. The ambulance crew would then be expected to confirm that it was on its way. If the selected ambulance was in an ambulance depot then the dispatch message would be received on the station computer. The ambulance crew would always be expected to acknowledge a message. The system would automatically alter HQ of any ambulance where no acknowledgement was made. A follow-up message would then be sent from HQ. The system would detect messages that would tell HQ when the ambulance crew had arrived, when it was on its way to a hospital and when it was free again.
3.3 How the CAD system was built The CAD system was built as an event-based system using a rule-based approach and was intended to interact with a geographical information system (GIS). The system was built by a small 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 servers supplied by Apricot. 4. Events that Identified the Flaws of the CAD System On the night of the 26th October 1992 (Monday), things started to go wrong at the HQ of LAS. A flood of 999 calls apparently swamped operators’ screens and many of those calls were being wiped off screens for unknown reasons. Claims were later made that 20 to 30 people may have died as a result of ambulance arriving late on the scene. Some ambulances took over three hours to answer a call while the government’s recommended maximum was 17 minutes.
Mr. John Wilby, the chief executive officer of LAS resigned within a couple of days of this event. A number of Members of Parliament called for a public inquiry. The Health Secretary initiated an inquiry and the findings were eventually published in an 80-page report in February, 1993, which immediately became headline news in both the computing and the national press.
5. Findings of the Inquiry The inquiry found evidence of poor management practice, high technological complexities and unfavorable operating environment involved in the implementation of the CAD system in LAS. Systems Options, the company responsible for developing the major part of the CAD system had no previous experience of building similar type of systems. This company, which had won the £1.1 million contract for the development of the CAD system in June 1991, was found to have substantially underbid an established supplier (McDonnellDouglas). Hence, Systems Options was under serious 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’. It appeared that Mr. Wilby ignored what amounted to an over-ambitious project timetable. Furthermore, an audit report by Anderson Consulting which called for more finance and longer time scales for the CAD project was suppressed by the project managers.
The board of management of LAS was even misled by the project team over the experience of Systems Options and the references supplied by Systems Options were not thoroughly investigated. Due to the extreme time pressure to develop the CAD system within the allocated timeframe, the project team responsible for developing the system practically did not follow any standard systems development approach. As a result, the resultant software was incomplete and unstable. In January 1992, phases one and two of the project began live trials. In March 1992, phase two of the trials was temporarily suspended due to the discovery of system errors. In October 1992, phase three was terminated after two days of reported chaos described above. Questions were raised about the complexity of the technical system. In the manual dispatch system, communication between HQ and ambulances is conducted via telephone or voice radio links. In the CAD system, links between communication, logging and dispatching via a GIS were meant to be automated.
The automation was completed but no performance testing was thoroughly performed due to the rushed approach to meet the deadline. The system was lightly loaded at start-up on the 26th October, 1992. Any problems, caused by the communications systems (e.g. ambulance crews pressing wrong buttons, or ambulances being in radio black spots) could be effectively managed by staff. However, as the number of ambulance incidents increased, the amount of incorrect vehicle information recorded by the system also increased. This had a knock-on effect in that the system made incorrect allocations on the basis of the information that it had. For example, multiple vehicles were sent to the same incident, or the closet vehicle was not chosen for the dispatch. As a result, the system had fewer ambulance resources to allocate.
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 of calls, together with a slow system and an insufficient number of call-takers, contributed to significant delays in answering the telephones which, in turn, caused further delays to patients. At the ambulance end, crews became increasingly frustrated at incorrect allocations and this led to an increased number of instances where they failed to press the right status buttons. The system therefore appears to have been in a vicious circle of cause and effect.
There was also an apparent mismatch of perspectives among LAS management, HQ staff, and ambulance staff. The system has been described as being introduced in an atmosphere of mistrust by staff. There was incomplete ownership of the system by the majority of LAS staff. The hardware and software suppliers involved in this project reported low staff morale and friction between LAS management and workforce. In other words, an atmosphere of hostility towards the computing systems was observed. One of the reasons for low staff morale was that control room staff lacked previous experience of using computer systems. 6. Conclusion In summary, no single element of the case can be regarded as the sole cause for the failure of the CAD system in LAS. The description demonstrates that failure of information systems projects tend to be multi-faceted in nature.
a) Discuss the CAD system in terms of Interaction Failure. b) What lessons can be learned from the failure of the CAD project in LAS?