London Ambulance fallback failure

Some readers may have seen the article in the London press about the London Ambulance Service having some problems with maintaining effective control during fallback when there was a fire in their control centre.

The fire was an electrical fire in a UPS.  The fire meant that operations had to move to the fallback control room in Bow.  However the report into the events revealed a number of failings in their procedures, when they got to the fallback control there were problems with glare on screens and problems with technical language being used in the control room that hampered communications.

Clearly operational effectiveness during this event were significantly degraded and LAS has learnt some harsh lessons including deciding to keep their fallback control room "live".

This event features many common issues for control centres when looking at fallback arrangements.

• The procedures for moving out and setting up the new control are rarely exercised or tested.  
• The switching of the technology is not well designed to be reliable.
• It is difficult to determine the duration of the fallback and therefore to what degree the fallback control room has to match the main control room functionality.
• The fallback control room often suffers from a lower level of design - it's often not really designed at all.

Many of these issues arise as a fallback control room is seen as a facility which is rarely used and therefore investment is made elsewhere.  As LAS perhaps found out, this is fine until you need it and find it doesn't work or doesn't work well enough.

Report into Heathrow Winter Resilience

The recent enquiry report into the response at Heathrow airport to the recent winter snow raised many interesting points about communications in a complex control environment and responding to difficult situations.

The report highlighted the problems in managing real-time communications between different groups and functions all trying to collaborate.  We often see this in our control room design work - the resource required to disseminate information is often too much so only partial information is shared.  We have been looking at a number of projects recently where shared systems automatically enable visibility of information held by other functions so reducing this problem - providing communications in parallel rather than serial.

This kind of information sharing is important for different teams to retain the "big picture" overview of the situation, one which is often changing rapidly.  Good situational awareness is critical for the right decisions to be made at all levels of crisis response.

The report also flagged some interesting issues about the physical location of controls in relation to the events going on (many of the control rooms involved had no visibility of the airfield to give them that important contextual information) and in relation to each other.  Co-location of control rooms has its problems but it can be effective in short-cutting some of the communication flows.

One final point of note was the importance given to managing passenger needs during the crisis. Inevitably the focus of many operations during events like this is to focus on restoring the service as quickly as possible.  But if all resources are directed on this then the operation ignores supporting the passengers during this stressful experience.  It was good to see recommendations covering passenger welfare both in terms of provision of regular, up to date information and in providing temporary facilities in the airport.

7/7 inquest - control room design failings?

Recently at the 7/7 inquest we saw evidence given that shows up failings in how the ambulance control room operated at a time of high stress and pressure.

See some of the press coverage: www.bbc.co.uk/news/uk-12598785

Some examples from the evidence given:

• There was only one person logging calls and vital information was written on scraps of paper (the inference being that some of these were lost or the information not utilised)
• The whiteboard that was being used to log the events was positioned too high for the person acting as scribe such that they could only write on the bottom half.
• Two people allocated key roles in the management of the incident hadn't been trained in the "gold command" procedures
• The transfer of staff from normal operations to the Gold command room was delayed as the system required staff to logout of one workstation before logging in elsewhere; presumably they weren't aware of this.  This caused a backlog in calls.

In our experience, these kinds of problems are not as rare as one might hope but can be designed out with the right approach.

Often not enough focus is placed on how control rooms deal with these major events as they are so rare - but doing so increases the risk of failings such as those identified at the inquest.

At the very least, events such as this are prominent reminders to other services to re-examine how they do things and that lessons can be learnt to improve systems and processes and get the design of these control rooms right. 

The right approach is to integrate the design of the processes & procedures with the control room design and the development of the control & communication systems.  All too often they are dealt with seperately which leaves these kinds of chinks in the overall incident management system.