BY LEIF ANDERSON
Communication is simply the skill and ability to use words (or signals) to effectively impart information and ideas. Communicating thoughts, messages, ideas, and information to firefighters who are responding to or operating at emergency scenes is not easy. Many factors contribute to the difficulty in communicating; the most apparent one is the enormous amount of information we to want to communicate. Recently, I overheard a company officer complain to his battalion chief, “I have a thousand yards of information to communicate in a 10-yard space-it just doesn’t fit!”
Portable and mobile radios are very effective for brief fireground communications (on-scene reports or progress reports, for example), but we can rapidly overwhelm our radio systems with the “thousand yards” of information we want (or need) to communicate. In addition, if we use our radio system for these “thousand yards,” then it won’t be available for critical communications.
It’s not an accident that we want to communicate a “thousand yards” of information. We’re all aware of the positive impact communicated knowledge has on fireground decision making and how this knowledge can be critical to firefighter survival. Better-quality, timely, and accurate information leads to informed decision making on all levels-strategic, tactical, and task. Poor information, on the other hand, leads to uninformed/frazzled decision making and dangerous fireground situations. In the many instances in which a radio just doesn’t allow us the time and space to communicate effectively, we need to develop other media for communicating our “thousand-yard” thoughts, messages, ideas, and information. In the Phoenix Fire Department, we use computer aided dispatch (CAD), mobile data terminals (MDTs), and mobile computer systems to do this.
OUR CAD LEGACY
In 1982, the Phoenix Fire Department entered the computer age. During the 1970s and early 1980s, the city of Phoenix and our surrounding cities had been growing at an exceptional rate (that growth is still occurring today; Phoenix is now the sixth largest city in the USA). Dispatchers had reached their limit of being able to manually gather and document information while tracking the status of multiple units and monitoring those units throughout their emergency activity. Growth alone would have created the need to acquire a CAD system, but the primary factor that pushed us forward was customer service delivery. A CAD system immediately improved our customer service delivery by speeding the dispatch process, permitting our dispatchers to tolerate increased call volumes, allowing us to consolidate the dispatch centers of several cities into one central facility, developing automatic-aid agreements with all departments that joined us in a CAD consortium, and providing improved record keeping and accuracy. Regardless of city borders, our units were dispatched more quickly and our customers received faster service, especially during periods of high activity.
Since those early days, the Phoenix Fire Department has experienced many changes and updates to that basic infrastructure. In 1985, an enhanced 9-1-1 capability was added to our CAD system. By 1994, a wholesale replacement of the CAD system was long overdue. Overall call volume was increasing, and more cities were asking to join the consortium. The CAD system was slowly being overwhelmed while calls were being placed in a queue during periods of high activity. The CAD system needed a leap in functionality and system response to extend the level of our customer service. We installed a highly customized CAD with features that included an automatic vehicle locator (AVL) system and desktop computers in every fire station. The addition of the AVL meant the units would be dispatched according to the location of the apparatus instead of the location of the fire station, further reducing response times and thus improving customer service.
OUR MDT LEGACY
 Examples of MDT onscreen mapping: (1) aerial preplan |
The CAD system also had a direct impact on Phoenix firefighters. MDTs were mounted in all emergency apparatus, and a station-alerting package was installed in each fire station. These additions affected our firefighters primarily in two ways. First, they now had a text copy of the dispatch message (a hard copy from the station printer and a soft copy on the MDT screen), reducing the chance of speaking or hearing errors that could affect response times. Second, they were able to change the status of their unit from their MDT, thereby reducing overall radio time and freeing the dispatcher to manage more activity. Using an MDT, firefighters also perform two-way messaging; receive supplementary call information; view rudimentary building drawings; preplan tactical information; and research information stored in the CAD, such as active incidents, incident histories, and the status of other units.
 (2) streets |
Although our CAD system had undergone many changes and improvements, our MDTs and their infrastructure did not. Since 1982, very little had changed for the firefighter using an MDT. While the basic functionality remained neutral for the firefighter, several factors were becoming apparent as technology advanced and our workforce grew older. MDTs were designed with a 5.5-inch amber phosphorus monitor and a small keyboard, features that are increasingly intolerable to an aging workforce. MDTs also provided limited functionality because of an absence of computing power. In addition, the system controllers that maintain our wireless infrastructure are obsolete and repair parts are no longer available. These are overwhelming factors that indicate change is necessary, but the simple fact that we could no longer purchase MDTs forced us to change.
 (3) data layers |
As if this were not enough, as additional cities were added to our CAD consortium, we had to purchase MDTs that were not compatible with our MMP30 wireless infrastructure. The Phoenix Fire Department, through a patch with the Phoenix Police Department’s RD-LAP wireless infrastructure, dispatches these units seamlessly to the firefighter while using this different communications network.
HOW WE CHANGED
Through a Labor/Management Relationships By Objectives (RBO) system, our department had an RBO committee in 2000. The committee had been examining hardware options for some time. The most viable option was to choose a portable computer running software that would communicate with our CAD system. The committee met with multiple vendors and visited several cities. An assortment of computers were selected for trial use and installed on various apparatus for periods of one to three months.
 1 MDT flowchart |
We formed a project team comprised of members of our support services divisions (technical services, dispatch and deployment, and resource management) and the union. Given the fact that computers were going to be used, the project team wanted to add functionality to the “new MDTs” and take advantage of modern computing power. The project team considered onscreen mapping a necessity. We developed an extensive Request For Proposal; the goal was to solicit one vendor that would propose a comprehensive solution. On review of the bids, the team discovered that no single vendor could fulfill our needs. We contracted with our CAD vendor to write portions of the software, developed other software internally, and purchased the hardware and hardware installation separately.
 2 MDT preplan |
While the software was being written, firefighter focus groups continually refined it. Although the software was designed specifically to support a company officer, the focus groups allowed us to obtain specific information from each rank. During these meetings, we requested that they consider the areas specific to their jobs and that they clearly state what they wanted the computer to do and how they wanted it to happen.
ONSCREEN MAPPING
Our budget didn’t have the funds to purchase the mapping function we desperately desired. During a project team meeting, one of the team members indicated that several employees of his work group had the skills to write the mapping software internally. Using mapping programs and compiling GIS data layers, they began to build an automated mapping program intuitive to firefighters and their skills. The GIS data layers included hydrants (City of Phoenix Water Department), city streets (Phoenix Fire Department), property parcel lines (City of Phoenix Development Services), and aerial photographs (Maricopa County Flood Control).
WIRELESS DATA SERVICE
Next, the project team had to consider the possible alternatives for wireless data service. Our current MMP30 system controllers are obsolete and subject to failure at any time. Our options were to use the RD-LAP system that some of our MDTs are with or use a commercial service provider. After a thorough review of the coverage data, the project team decided to use a commercial provider with Cellular Digital Packet Data (CDPD) service. Our CAD system would now be supporting MDTs (operating on both MMP30 and RD-LAP) and mobile computers on CDPD.
The CDPD modems we purchased contained a GPS receiver, which provided the ability to display the position of the apparatus on the firefighter’s screen. The position is updated once per second and is displayed as a yellow arrowhead on top of the map layer, giving the firefighter a positive indication of the apparatus’ position and orientation to surrounding streets. When used with the aerial photograph layer, a firefighter can see the size, shape, and arrangement of structures before arriving on-scene.
OTHER CONSIDERATIONS
A comprehensive training program was initiated. It included the following phases: Awareness, Education, Basic Training, Just-in-Time Training, and Training Updates. The information was also shown on our internal cable network (Phoenix Fire Network) and posted on our intranet Web site; we also established an e-mail box for members’ questions. The just-in-time training was given at the time the units were installed; firefighters were able to get hands-on training on the computers, attached to carts. Although written material and manuals were present, the training required the firefighters to duplicate the same tactile skills they use during calls.
The project team also worked through various decisions related to the hardware, including the price of each computer, the ease of installation, the ease of maintenance, ergonomics, and bracket selection. Although the project team selected a specific computer, it was decided to be flexible with regard to the future, since technology and product changes are ongoing.
WHAT WE GET
The finished product was specifically designed for firefighter mobile use. It’s migration friendly, it incorporates a consistent user interface, and the reference and static information it provides (e.g., address, phone lists, maps, aerial photos, SOPs, and so on) is stored locally on the computer’s hard drive.
WHAT’S NEXT?
The prefire plan is a major support item during the evaluation process of any fire. Heeding the words of Phoenix Chief Alan Brunacini: “Filing, storing, and finding preplans presents many functional and practical problems. Simply, if you can’t find it, you can’t use it.” Our software writers wrote a program to collect and track the prefire worksheets our fire companies create monthly. The software attaches a scanned image of a company’s worksheet to a specific address. When a firefighter touches an onscreen icon residing over that specific address, the worksheet image (an ArcInfo file) is launched. The firefighter can then resize or rotate the image, or choose to view other available images from pull-down menus. This process enables our firefighters to rapidly view pertinent building information, risk analysis, digital photographs, safety information, and so on over a short response time.
Since the prefire worksheets will also be stored locally on the computer’s hard drive, we needed a process that would update each unit’s computer as new files are created. We are using a wireless Local Area Network (LAN) to transmit the updated files from workstation PCs and servers to each mobile computer in the system. The file updates are seamless to the firefighters, and the wireless LAN software produces a complete status report for the system managers.
The Phoenix Fire Department has enjoyed using a CAD system and MDTs for 20 years. However, mobile computers are an enormous leap forward in both functionality and user friendliness. We believe this jump allows us to communicate our “thousand yards” of information more effectively while improving firefighter safety, firefighter preparedness, and customer service.
LEIF ANDERSON is a captain paramedic with the Phoenix (AZ) Fire Department, where he has served since 1984. He’s currently assigned to Phoenix Fire’s Technical Services section, where he will be assisting with the transition to an 800 MHz radio system and other technologies. He is an affiliate faculty member of Phoenix College, where he has taught in the emergency medical technology and paramedic programs since 1989. Anderson has also taught and made presentations for several outside agencies and businesses. He is an NFPA 1041-certified fire service instructor and an Arizona Department of Health Services IOP certified EMS instructor. Anderson has a State of Arizona teaching certificate.
[Photos courtesy of Phoenix (AZ) Fire Department.]
