Home Page


   Main Index


  NEWS / Info

  CAD failure

Drugs LAS
Drugs Print
Slide Show
Clipart & gifs
ini polls






  Latest protocol


  Spinal care 

  Needle Chest




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.


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.

Doug Hamilton, Department of Information Systems, Monash University, PO Box 197,
Caulfield East Victoria 3145, Australia.