1 / 13

London Ambulance System

London Ambulance System. Some of the slides created by Sommerville. London Ambulance System. Largest Ambulance System I the world Responsible for 600 square miles 6.8 million residents (plus visitors) Carries over 5000 patients a day 2000-2500 calls daily – 1300-1600 – 911 equivalent

anevay
Download Presentation

London Ambulance System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. London Ambulance System Some of the slides created by Sommerville.

  2. London Ambulance System • Largest Ambulance System I the world • Responsible for • 600 square miles • 6.8 million residents (plus visitors) • Carries over 5000 patients a day • 2000-2500 calls daily – 1300-1600 – 911 equivalent • Computer-aided despatch • handles call taking • determines ambulance to send • handles mobilization of ambulance, sends details of incident to ambulance • manages ambulance resources

  3. London Ambulance System • Implemented Computer Aided Despatch (CAD) system • Failed Dramatically on October 26th 1992 after 2 days of operation • Could not cope with normal load • Response to calls was several hours (delays up to 3 hours) • 3 minute turn around expected • Ambulance communications failed and ambulances were lost from the system • Some claimed it could have been responsible for 20 deaths – chief executive resigned • Errors from requirements through design, implementation and introduction of the system

  4. Problems from the start • Yes, there were programming errors.. But the system crash was not the worst of it • Lack of communication • Management and Staff had strained relationship • Exceptional time and $$$ pressures • Requirements – • Must be less then £1.5M • Must be done in 11 months • Anderson Consulting said • £1.5M if they could find pre-packaged systems • Much more if no pre-packaged systems • 19 months • 17 companies bid – they went with the cheapest (<£1M ) • Hmmm what’s wrong with this picture?

  5. Concept/Design of the CAD system • Existing systems dismissed as inadequate • Desired system • CAD + Computer Map Display + Automatic Vehicle location system • Must integrate with MDTs(Mobile data terminals) and RIFs(Radio Interference system) • Success dependent up on • 100% accuracy and reliability of technology • Cooperation from all parties

  6. Problems in a Nutshell • Strained relationships between Staff & Management • CAD system “management’s solution to outdated working practices” • Staff was not involved in the requirements process • Bad assumptions made during specification process • Staff needed to drastically change their work process • Software was incomplete and untested • “high risk” implementation approach • Ambulance crews and Staff trained long before using the system • Reorganization of control room…loss of local knowledge

  7. These led to… • Inadequate requirements • Ill thought out requirements or design • Low cost expectation but high functionality expectation • Human Computer Interface difficulties • Documentation lacking

  8. Project Management Problems • Evaluation team • System manager – ambulance man – not IT • Analyst – contractor – 5 years at LAS • Who got the contract? • Systems Options, Datatrak, Apricot – consortium • Who’s the lead dog? • No relevant experience anywhere • No Independent QA

  9. Resulting system • System removed flexibility in resource allocation • System allocated nearest resource, regardless of originating station • Lack of voice contact exacerbated “us vs them” • Technical problems reduced confidence in the system for ambulance crews and staff • No backup system • No incremental deployment

  10. Resulting System (2) • Communication errors led to… • Radioed in blackspots • Ambulance crews pushing wrong buttons • … and so on • ... Resource confusion which led to • Software could not identify nearest available resource. • Multiply crews sent to the same location • Inaccurate location information. • Communication channels overloaded. • Mobile data systems failed. • Ambulance crews took different vehicles from one allocated

  11. Resulting System • … Enormous exceptions … led to • Also due to • failure to identify all duplicated calls • Lack of prioritisation of exceptions • Operator workstations locked up – queues scrolled off the top of the screen • Slower response • Frustrated Callers • More duplicate calls • Not enough call takers • More delays • Frustrated Crews • More mis-pressed buttons • Greater volume of radio calls • Bottleneck on Radio transmissions – • Crews taking wrong vehicles … and on and on… • System slowed until it crashed. Outcome : missing vehicles, lack of prioritisation duplication of call outs, calls lost.

  12. LAS • LAS did not fail because of the minor programming mistakes • Reasons for failure: • project schedule was far too tight • LAS management has little or no experience in software projects of this magnitude • ditto for contractor • they were far too optimistic in their assessment of risks • they also assumed all people who would interact with the system would work with it exactly as specified • Reorganization of control room made it difficult for staff to intervene • Reasons for failure depend on who you talk to • Management, Crew unions, system manager, government

  13. Lessons Learned • Development must allow fully for consultation, QA, testing, training • Management & Staff must have confidence in the system • A new system should be introduced in a stepwise approach

More Related