Emergency Operations Centre Specifications

The Nelson City and Tasman District Councils of New Zealand have issued a request for Expression of Interest for a Information and Communications System for a joint Emergency Operations Centre (EOC) (Reference: 27532). This is for emergency and disaster coordination.

The 23 pages of documentation (available to registered companies) includes a concise statement of requirements for such a system. Included is a photo of an EOC, equipped with about 13 computers and having about 20 people in it. In contrast to the usual publicity photos of such centres, this shows the messy reality. The requirements specification also shows a simialr grasp of the chaos which can occour in the early stages of an emergecy.

The documentation also specifies the current computer and telecommunications systems of the councils. These a re quite complex and the Councils might find it better to replace them with a more rationalised streamlined system, rather than try to make these systems suitable for emergency use. Recent advancements in thin client computers using VoIP allow low cost equipment to work at low power from low cost servers. This makes for a much simpler set-up than PCs and IP phones which will require more backup power, networking and servers.

Simple database applications with web based interfaces can be used. In many cases organisations spend considerable effort and money on systems to allow the emergency applications to run in standalone mode, in the event of server loss. In practice, most such systems will not work without the server and it is better to concentrate on a cheap, similar and reliable server system.

Also low power, low cost netbooks could be of use. These could replace more power hungry and expensive laptops. Smart phones with WiFi support may also be of use o supplement netbooks. These can form a useful transportable operations centre, with all the equipment needed for a dozen operators fitting in an airline carry-on size wheeled bag. A central server and WiFi base station would provide access for a dozen netbooks and smart phones. This could be used to supplement the fixed centre and the same location, be deployed nearer an emergency location or be used to replace the centre should it be disabled in the disaster.

Requirements

1.80. The EOC may need to operate under three general scenarios:
a. A local emergency with normal power and telecommunications
b. A local emergency with local interruptions to power and
telecommunications (in this scenario the EOC has its own power supply so ICT within the building can operate)
c. Significant emergency, could be Local, Regional or even a National Emergency with limited or no power supply or telecommunications, EOC could be running from one or two stand alone PCs or possibly have reverted to analogue (plus paper-based) systems 1.81. The EOC, when fully operational could be operating 24 hours a day for several days with 30-40 staff in three revolving eight hour shifts (see image below for an overall impression of what an EOC looks like).

1.82. The above image is of a mature EOC i.e. an EOC well into an emergency. When first activated, particularly in a declared emergency, the situation can be quite chaotic. EOC staff may start to arrive over the course of an hour or more and it might take some time for the EOC to reach ‘critical mass’.

Messaging

1.83. Once activated, several different personnel, though typically designated telephonists within the EOC will need to be able to simultaneously record incoming information. This will include messages from: members of the public phoning in, emergency services communications, reports via radio telephone and/or mobile phone from emergency management personnel on the
ground, emergency management personnel reporting face to face. The EOC personnel having those conversations need to be able to quickly record details of the conversation in a structured way.

1.84. Ideally the person taking the call will be able to choose from different situation choices based on what the caller is saying i.e. flooding, blocked road (and blocked by: slip, fallen tree, vehicle incident), call-taker is prompted by
the system about what questions to ask (possibly in a descending order of importance). Where applicable, responses can be tic-boxes.

1.85. Ideally the system will automatically assign metadata where appropriate i.e. date, time, user ID, machine ID

1.86. The use of geospatial aids (maps) is usual in EOC to aid visual representation of an emergency and as an aid to analysis of the situation. Emergency situations suit such analysis because typically incidents within a wider emergency occur at some location. To facilitate display and analysis within a
geographical information system (GIS) (during and subsequent to an emergency), in capturing those locations, the call-taker should be able to choose from managed lists the location that fits the description from the caller i.e. Address (18 Hampden Street, Murchison), Road Intersections (cnr Motueka Quay and Glenaven Drive, Motueka), Road (waimea Road, Nelson), Place or Places (Broadgreen House or Appleby School), River Segments (Washbourn Stream between Hill Street and Washbourn Drive or Motueka River between Woodstock and Stanleybrook).

1.87. Assigning criteria to calls: The person taking the call will need to be able to assign a range of different criteria to an individual message.
• Validation: Who was the caller? How reliable is their information? Was the caller ‘Joe Bloggs’, untrained and unqualified member of the public or a trained and experienced member of Emergency Services or an Emergency Management Field Operative? The information supplied by the latter would be rated higher than the former.
• Urgency: i.e. ‘routine’ through to ‘requires immediate attention’
• Importance: i.e. ‘routine’ through to ‘highest’
1.88. The system would be able to ‘flag’ or highlight individual messages based on a criteria i.e. ‘Red-Flag’ for urgent or important or ‘Blue-Flag’ for routine.
1.89. Have the capability to link or group one or more messages together.
1.90. Often in an emergency situation the EOC will receive multiple calls in a short span of times about the same situation. Rather than record this multiple times, it would be more efficient if you could record the same base information e.g. “Appleby Bridge approaches washed out”, then note the number of calls
received about that. Explain how the system might achieve this.
Request for Expressions of Interest to Supply

Workflow
1.91. Once the EOC call taker or team member has captured all the information regards a particular message, they need to be able to:
• Assign the message to an individual EOC team member
• Assign the message to an EOC team e.g. Planning and Intelligence
• Assign a message to multiple individuals and/or teams
1.92. The system routes a particular message via some form of workflow function to the assigned individual/s and/or team/s
1.93. In the event no individual/s or team/s are assigned to a particular message, the message can be configured to rout particular messages, based on a userdefined criteria to an individual or team based on one of the captured criteria
e.g. all messaged tagged ‘highest’ importance go to the Controller
1.94. Individuals and team can quickly and easily see/be alerted to/find messages assigned to them
1.95. Individuals and/or groups need to be able to add to a message. This may include adding additional information and/or comments. Assigning or reassigning status e.g. under action, closed, validation required, or assigning to an additional individual or team
1.96. Explain how the workflow function works.
1.97. Once messages have been processed have the ability to check or tag them in some way as ‘complete’ or ‘actioned’ etc. and they disappear from the ‘active’ list/screen but stay in the system.

Scalability/Portability
1.98. Could have the capability to be installed, stand alone within Councils smaller EOCs; Motueka, Takaka, Murchison but with the capability to communicate (integrate) with the main EOC
1.99. System can be scaled to monitor and/or manage the range response levels (from Introduction): Level 3 – Local Coordination; Level 4 – Regional Coordination i.e. the system may start off monitoring/managing a single incident which eventually escalates into a full emergency.
1.100. While for most emergencies it would be envisaged the system would operate within Councils existing ICT infrastructure (refer ‘Existing System & Environment section) because of the nature of emergencies it would also need the capability to run in a stand alone situation i.e. be network independent. How would that work?

Integration
1.101. External communication is an important component of an emergency response i.e. letting interested parties know about the status of the emergency; where evacuation points might be; what areas have been evacuated etc. The system would be able to communicate, preferably via standards-based protocols to external agencies/sites i.e. make available data/information feeds in standard formats e.g. Really Simple Syndication (RSS) or Extensible Mark-up Language (XML) or Keyhole Markup Language (KML). Consumers of such feeds could include: Nelson City and Tasman District Offices, Emergency Services (Fire, Police, Ambulance), National Crisis Management Centre,
National Health Coordination Centre. Explain capability for this.
1.102. The system might want the capability to utilise real-time data feeds using standard protocols from TDC and NCC core systems. How could that happen?
1.103. System would have the potential to integrate with Councils geographical information systems (GIS), specifically Environmental Systems Research Institute (ESRI) ArcGIS Server, through web services or other standardsbased integration methods.

How might that work?
Architecture
1.104. Please supply details of the systems architecture.
1.105. Explain how server/PC images, versions and upgrades could be managed particularly at satellite locations such as Murchison.
1.106. How is your system be licensed including those costs.
1.107. Would any changes be required to Councils existing architecture?
Setup and operation
1.108. The system would need to be relatively straightforward and quick to setup/activate/get going once the EOC is activated. Please explain how this might happen.
1.109. Any system should follow established keyboard quick-key functions e.g. Ctrl>C for copy etc.
1.110. Though some system training would be anticipated, graphical user interfaces (GUI) and functional methods would need to be intuitive. Give us some examples if available.
1.111. Please explain how your system creates and manages the message objects it creates?
1.112. In the event of a situation where power supply to the building is affected or the nature of the emergency requires the EOC to relocate, it may be required to fail-over to a manual system. How would/could the system report the current status of the emergency, elements of which the system manages such
that this could be replicated and then managed on-going in an analogue (hardcopy) environment.

Reporting/Display
1.113. The system will need to be able to report on of individual or groups or types of messages based on different user-defined criteria
• Status of messages tagged with a specific urgency rating
• Show messages not actions after a certain length of time
• Show all messages of a certain type e.g. flooding
• or number of messages logged over this time frame
• all messages to a specific user or group
• Please detail reporting functionality.

1.114. Describe any central administration tools you can offer or how you propose council would monitor and support the solution;
1.115. Is there any software that can automatically inform council of problems?
1.116. Is there a central management console and what functions does it support?
Status/Message Board
1.117. The system will need a ‘status board’ functionality to display the latest key data in relation to an emergency event the EOC is managing. This might be thought of as key performance indicator (KPI) reporting and be based on a number of ‘indicators’. The status board will give a ‘snapshot’ of the
situation.
1.118. The status board would also provide key information such as if a state of emergency is declared, and when.

Knowledge Base
1.119. Some kind of knowledgebase would be useful. This could include standard information generic to a general or type of emergency i.e. key contacts, designated assembly points etc. It could also include information about the specific emergency at hand i.e. evacuation centres established, status of individual towns etc. If a knowledgebase was to be utilised in this way it
would need the capability to evolve as the emergency evolved. ...

From: Request for Expressions of Interest to Supply
INFORMATION AND COMMUNICATIONS SYSTEMS FOR COUNCIL’S EMERGENCY OPERATIONS CENTRE (EOC), NELSON CITY COUNCIL and TASMAN DISTRICT COUNCIL, New Zealand, 14 September 2009.