Docstoc

London Ambulance Service Case study

Document Sample
London Ambulance Service Case study Powered By Docstoc
					                        London Ambulance Service Case study
The London Ambulance Service (LAS) is world’s largest ambulance Service covering
an area of just over 600 square miles and a population of around 7 million people
(though the daytime population is much larger due to the influx of commuters). The
service is divided into two sections: one providing routine patient transport, the other
an accident and emergency service. In 1992 the emergency service was typically
dealing with up to 1600 calls a day. It had a target of dispatching an ambulance within
3 minutes of a call and attending an incident within 14 minutes.
At that time the service used manual methods for controlling the dispatch of
ambulances. The details of a call, such as the location and type of incident, were noted
on paper and sent to a central collection point where duplicate calls (resulting from
more than one person calling about the same incident) were eliminated. Call details
were then given to an allocator who selected which ambulance to send. The details
were next passed to a dispatcher who contacted the ambulance driver by radio or
telephone. Once the ambulance was dispatched all communication was by radio.
There were problems with this system: paper details could easily get lost, and if a
member of the public called back (to ask why an ambulance had not yet arrived, for
instance) it was difficult to trace how the original call had been dealt with. The paper-
based system meant that, in 1992, an ambulance was dispatched within 3 minutes in
less than half of the emergencies handled; an ambulance attended the scene within 14
minutes in only 55% of calls.
In the autumn of 1990 the LAS decided to commission the development of a
computerised dispatch system in order to improve its performance. A requirements
specification was prepared and an invitation to tender for the development was issued
in February 1991. A large number of companies responded though many commented
that the proposed implementation date of January 1992 made the timescale extremely
tight. Nevertheless a supplier was selected who offered to meet the deadline. This
supplier had carried out work for the emergency services before but had not had
experience of developing this kind of system. From subsequent investigations it is
clear that price was a major factor in selecting the winning bid.
There were many problems during the development of the new system. Software was
frequently late, there was no proper project management and no one involved with the
project had experience with PRINCE, the project management methodology which
had been adopted for the development. Moreover the software developers made ad


1
hoc changes to the software in order to please users. The users themselves were not
adequately trained, and were sceptical about the benefits of the system. As the result
of such problems the implementation was put back until late 1992 but, as it turned,
many problems were still not resolved in time.
The computerised dispatch system finally went live at 7.00 a.m. on 26 October 1992.
Initially, while there were few calls to deal with, the system worked satisfactorily and
staff were able to sort out any problems. However, as the number of calls built up, it
became clear that there were major problems. The system was often failing to
eliminate duplicate calls, so that sometimes more than one ambulance would attend a
scene. The tracking of ambulance status did not work well either. Ambulance crews
were meant to radio back their status by pressing various buttons on a special control
panel fitted to their vehicle. But this system did not work as well as hoped and crews
became confused about what to do. This exacerbated to problems so that the system
did not have a true picture of the ambulance fleet’s status and made inappropriate
allocations of ambulances to incidents. The delays in ambulance response had the
further effect that people at incidents would call again asking why no ambulance had
come, so increasing the load on the system. Eventually it became clear that the service
had lost control for its fleet and on the afternoon of the following day it reverted to a
semi-manual-system, using only part of the original software: that for taking calls. On
4 November, this failed as well due to a programme error, and the system was then
abandoned altogether.
The failure of the LAS system attracted widespread publicity and caused an outcry.
There were allegations that as many as 20 people had possibly died as a result of
delays of up to 3 hours in ambulances arriving at incidents. However, a later enquiry
did point out that there was no evidence of deaths due to ambulance delays. This
enquiry also reported that neither the system nor the user were ready for the
implementation and that, in any event, the system contained design flaws, in
particular an unrealistic reliance on perfect information about ambulance location.
The report also stated that the project timescale had been too short.


The tendency to analyse information systems failure solely from a technological
standpoint is limiting, that the nature of information systems failure is multi-faceted,
and hence cannot be adequately understood purely in terms of the immediate
problems of systems construction. In light of LAS Dispatch Systems:


2
    (a) Discuss the issues arising from the organisational context of software
       development.                                    (12 marks)
    (b) British Computer Society does set a minimum standard, through its
       membership examination, which would ensure a core of common knowledge
       among software developers. Discuss the professional codes of conduct that
       directly related to LAS.                        (13 marks)




3

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:85
posted:2/25/2010
language:English
pages:3
Description: London Ambulance Service Case study