Browse Content by Topic:
From The Chair: The Myth of CAD
Author: Paul D. Bagley
Copyright: 9-1-1 Magazine, Feature Content
In the good old days, back when I began my flirtation with this insane career now known as emergency telecommunications, the idea of computer-aided dispatching was no more on the radar than were computers themselves. Computers were giant rooms full of electronic gear that nerdy high-techie-types tinkered with at Berkeley and MIT, not something that sat upon virtually every desk in a police or fire station, or resided inside police vehicles or fire trucks. The activity records maintained by dispatchers consisted of an actual paper trail. In my case we had two typewriters: one Smith-Corona, one Royal; one was Pica, the other Elite. Doubtless they were left over equipment that The Chief felt would serve just fine in dispatch. One was used to log radio calls, the other a telephone and general activity log. On these hard-copy paper logs we managed to record everything that was worth remembering or knowing. Okay, okay; so I’ve now disclosed that my early years in dispatch were spent handling calls from Barney and Betty Rubble. But if nothing else, this illustrates just how far we’ve come in one short lifetime.
Today, we are either blessed or cursed with computer-aided dispatch, or CAD as it’s affectionately known. In the olden days, a cad was a despicable creature who was sinister and scheming in approach and completely devoid of character. Come to think of it, a dispatching CAD isn’t that far-removed from that same definition. The notion of dispatchers being able to consolidate information through a single point of input had and has great appeal and merit. After all, it eliminates the need for a pair of bulky typewriters sitting atop lazy-Susans allowing two or more dispatchers to share them. CADs are also alluring because most of them have colorful screens that can be personalized, thereby making them seem less ominous. But, like any human endeavor that restricts thinking and/or action, or any device that channels activity and limits variables, CADs have drawbacks to those old typewriters that came replete with blank sheets of paper.
NYPD police officers answering emergency calls c1970 before there was 9-1-1 or CADs. The manually completed incident card was placed in a slot of the continuously running conveyor belt (seen on the right), and transported to the appropriate dispatcher.
Photo courtesy 911Lifeline.
One of the biggest selling points of CAD programs is the ability to generate statistics. There isn’t a department head on earth that doesn’t thirst for activity data, and being able to sort various data and do analytical breakdowns is even more desirable. If CADs do nothing else well, they do generate data. The problem is the value of that data. In order for calls-for-service (CFS) to be properly sorted and analyzed, they must be properly encoded by call type. This means a finite list of call types must be readily available, and it presupposes that every dispatcher will encode types of calls the same way. Example: an initial call suggests loud music in an apartment complex and Dispatcher A encodes the call as a “noise” complaint. Dispatcher B gets the same type of call and considers the action “disorderly conduct” and encodes the call accordingly. At the end of the year we now have two separate categories for the same kind of call which creates a false premise and flawed accounting. Suppose the police officer responding to Dispatcher A’s “noise” complaint suddenly discovers marijuana in plain view when he’s telling the loud music player to quiet down. Does Dispatcher A remember to change the CFS code to “drugs;” or does the stat remain only a “noise” complaint? Either way, the year-end dispatch summary will be minus a noise complaint or a drug case – flawed accounting.
The problem with too many CFS codes is the overlaps shown in the example above are going to occur unless a single person is dispatching all of the calls. While this might seem a desirable possibility in some jurisdictions, it would probably violate the Fair Labor Standards Act, or at least burn out that single dispatcher in very short order. The trouble with too few codes means that the statistical data will have little meaning when analyzed; much like the simplistic filing system “everything under miscellaneous.” With the old paper logs statistical data that was readily perceivable was virtually impossible. The number of calls-for-service was determined by the formal reports generated by police officers, or by the fire and ambulance run sheets completed; not by the typed hard-copy logs.
The true value to paper logging was the ability for free text and the level of detail contained in an entry. While I fully understand that most CADs provide the ability to add notes of virtually any length to any call, it is never the same. A dispatcher could type into the free text area of a CAD all day long; field personnel and Monday-morning-quarterbacks like The Chief would still only look at the fields populated with the searchable encoded data. Reading lengthy entries is time-consuming and doesn’t lend itself to the underlying concept of “dispatching” a call. After all, our job is to convey information with “dispatch,” right? It also suggests the need for three-dimensional minds to perceive the full import of the additional information contained in such entries, and we all know how unlikely we are to be dealing with those. One police agency for which I once dispatched actually directed dispatchers to severely restrict the amount of free text included in a CFS; they didn’t want to over-burden their personnel with anything other than the raw essentials of a call. Of course, that agency was being run by a collection of Neanderthals that made the Rubbles and the Flintstones look like modern-day intellectuals. This was the same police department where a DUI narrative reading, “Sighted drunk, arrested same,” was considered wordy.
One of the most restrictive aspects of most CAD systems that I’ve encountered has to do with the assignment of units in the field. It may be true that most dispatchers deal with the same select number of units each and every shift, but the inability to instantly add foreign units to CAD entries negates the value of the information being recorded and is revisionist history at best. It is truly frustrating being unable to account for everyone on a call without having to type times and actions into the free-text area as though it were an addendum to the “important” information. Aside from being cumbersome to input, it is tedious to decipher afterwards and is not in keeping with the nationwide initiatives toward achieving true interoperability. While The Chief is looking for what he or she can get statistically out of the software, dispatchers are interested mostly in ease-of-use and the ability to effectively track in real time every field unit for whom they are responsible. If the CAD doesn’t accommodate the addition of field units by the dispatcher that aren’t already programmed into the system, that CAD is useless as a dispatching or recording tool.
From an interoperability standpoint, it’s not enough to be able to add police, fire, and ambulance units from neighboring towns that are already programmed into the system. Suppose an airliner crashes in your jurisdiction: you’re going to need a lot more of everything to help out and you’ll need to be able to get those additional units to respond from far beyond the neighboring towns. You’ll also need the ability to quickly input them into your system for proper tracking and documentation. How many local dispatch centers have NTSB units preprogrammed into their system for immediate use? How many can input and dispatch units of the National Guard, Civil Air Patrol, EPA, OSHA, FAA, state police, and units from other state agencies? More important, how many centers are using CADs that allow for the immediate introduction of such units in order to similarly and accurately account for every aspect of a call? I suspect few, and all should.
Multi-jurisdiction/multi-agency software is not enough. A CAD needs to be elastic enough to provide dispatchers with the unfettered ability to introduce and define new units instantly. How many jurisdictions consider a highway or public works department to be an emergency responder? Yet, how many of those same jurisdictions suffer from water main breaks, road damage caused by flooding or severe weather, or traffic lights suddenly going haywire? Are those situations emergencies? Do they require an emergency response? Of course they do, and the responders should be recorded and tracked just the same as police, fire and EMS personnel. How about emergency management? Can your CAD add these people quickly and track their activities? Does the CAD recognize emergency shelters and warming/cooling stations without having to venture into the free-text area at the bottom of the CFS?
One of the truly spurious aspects of CADs is the date-stamping capability. The time and date on an entry can be very deceiving. If the stamp cannot be adjusted by the dispatcher, then it is somewhat useless as a true chronological tool. In such cases the stamp only reflects when the dispatcher entered the data; not necessarily when the call actually occurred. This creates a void between the audio records for phone or radio found on the digital logger and the so-called written log. Having the ability to edit the stamp creates a different problem: the ability to forge a record in order to conceal shortcomings. Either way, what you see is not necessarily what you got.
Computers have been an integral element of dispatch since the 1980s. CADs were merely the next-most-logical evolution of the software that would be used to record data. The complexity of CAD is contingent upon its application and the desires of The Chief. Whether or not we like it, CADs have become a necessary evil and they’re here to stay. They can be a friend or an enemy – it’s all in how you approach them.
While many may still long for those simpler times when paper ruled, information generated and disseminated electronically goes hand-in-hand with modern emergency telecommunications. Proper input and encoding of data is evolving into an art-form of its own and the day has already arrived when the dispatcher needs to be the most computer-savvy member of their agency. That doesn’t mean we all need to aspire to being IT specialists; it simply means we need to know the program better than the units in the field. The time has also come when The Chief needs to start listening to someone other than the sales rep and the budget director when it comes to understanding the needs of dispatch. From operational aspects like proper coding of calls, to how responsive a CAD is when under heavy fire (use), consideration needs to be given to those who actually use the software and generate all those wonderful statistics.
A clean piece of paper provides a wilderness of free-association for some, but it can be overwhelming and completely daunting to others. CADs offer a remedy to the blank-sheet-of-paper syndrome – a handy and efficient method for recording facts that is pre-programmed to eliminate the need for thinking about what to record. There is little room for personal style. CADs are like the television cop Joe Friday who used to say, “Just the facts, Ma’am; just the facts.” If there is a creative element available to dispatchers it reposes in their individual ability to discern the crux of the problem at hand and properly encode and succinctly pass it on so those being dispatched can thoroughly understand all the salient components of the call. A house on fire is one thing; a five-party domestic dispute at the mayor house is something else. While CADs can limit the number of coding options to the minimum amount necessary to do the job, they can still obscure the truth if not properly programmed and monitored by someone with understanding of both dispatching and that particular CAD. Who better to monitor the computer aiding a dispatcher than the person sitting in The Chair? As General Omar Bradley so wisely observed, “If we continue to develop our technology without wisdom or prudence, our servant may prove to be our executioner.”
See related story archived from our March 2005 issue: "Are CAD Systems Becoming Too Complicated?"
Paul D. Bagley is a published author of both fiction and non-fiction books, a retired police officer and emergency dispatcher. He is the past president of New Hampshire Emergency Dispatchers Association, and he is editor and publisher of the association’s monthly newsletter, “The NHEDA Broadcaster.”
"From the Chair" is produced for 9-1-1 Magazine by 911Lifeline, a national 501(c)(3) membership association providing services for 9-1-1 telecommunicators, assistance to the media, and public education programs. For more information visit http://911lifeline.org.