By
Murray Turoff, Michael Chumer, Bartel Van de Walle, and Xiang Yao
|
Murray Turoff turoff@njit.edu Xiang Yao yao_xiang@hotmail.com Information Systems Department College of Computing Sciences New Jersey Institute of Technology Michel Chumer m.chumer@att.net College of Computing Sciences New Jersey Institute of Technology |
Bartel Van de Walle Information Systems and Management Department Tilburg University The Netherlands |
Primary contact: Murray Turoff
turoff@njit.edu
http://is.njit.edu/turoff
Submitted to JITTA for publication
9/5/03
Key Words: Crisis Management, Emergency Response, Extreme Events, Information Systems
This paper examines the requirements for an information system designed to deal with major crises including extreme events. It examines the historical experiences and literature associated with an early system that was utilized for fifteen years in the federal government to handle national emergencies. This is integrated with current literature and considerations to propose the requirements for a new generation of Emergency Response Management Information Systems that go beyond what is currently available. The emphasis is placed upon a system able to serve the first responders and local or regional communities seeking to deal with crisis and disaster situations.
Table of Contents
Introduction
Historical Insights about EMSIARI
The emergency Response Atmosphere of OEP
Resulting Requirements for Emergency
Response
Conceptual Design Specifics
Metaphors
Roles
Notifications
Context Visibility
Hypertext
Generalized Design Principles
Supporting Design Considerations
Resource
Databases and Community Collaboration
Collective
Memory
Online
Communities of Experts
Conclusions and Final Observations
References
There have been, since 9/11, considerable efforts to propose improvements in the ability to respond to emergencies. However, the vast majority of these efforts have concentrated on infrastructure improvements to aid in mitigation of the impacts of either a man-made or natural disaster. In the area of communication and information systems to support the actual ongoing reaction to a disaster situation, the vast majority of the efforts have focused on the underlying technology to reliably support survivability of the underlying networks and physical facilities (Mork 2002; Kunreuther & Lerner-Lam 2002). The fact that there were major failures of the basic technology and loss of the command center for 48 hours in the 9/11 event has made this an understandable result. The very workable commercial paging and digital mail systems supplied immediately afterwards by commercial firms (Michaels 2001; Vatis 2002) to the emergency response workers demonstrated that the correction of underlying technology is largely a process of setting integration standards and deciding to spend the necessary funds to update antiquated systems. The real demonstration of the 9/11 event is the strategic and technical fallacy of making the integration of communications between incompatible systems (fire, police, medical, etc.) dependent upon a single physical command and control center. Such centers are vulnerable to a planned act of sabotage. If there is any strong technical conclusion from the events of 9/11 it is the requirement to develop an integrated communications capability that can react as a distributed virtual system with no required need for the humans involved to be in a single location (Smith & Hayne, 1991). A virtual command center can be created when the authorities, decision and reporting responsibilities, the accountability tracking and the oversight monitoring functions are explicitly represented and present in the supporting communications software for the operation of such a human network. In fact, those involved should be able to operate from wherever they happen to be at the start of the crisis: their home, office, or in transit. It is this underlying technical goal assumption that is one of the foundation goals of the requirements discussed in this paper.
Our principle concern
in this paper is with the functionality requirements that the software needs
for those planning and executing the emergency response management function.
Very little has been published recently on specific functional requirements for the first responders to an emergency based situation. We also note that a great deal of the literature on emergency response prior to 9/11 focuses on the response of commercial firms to emergencies or crises largely restricted to the corporate environment (Barton & Hardigree 1995; Braverman 2003; Kim 1998; Lukaszewski 1987; Massey 2001; Mork 2002; Pearson, Misra, Clair, & Mitroff 1997; Smart, Thompson, & Vertinsky 1978; Smart & Vertinsky 1984) or focused on the public relations aspects of a crisis (Coombs 2000; Dyer 1995). When an emergency in a company starts to cause physical harm to people or facilities, it usually leaves the jurisdiction of the single organization and evolves to be the concern of local, state, and federal agencies depending on the scope and nature of the emergency. However, there are a number of significant observations that apply to crisis situations regardless of the organizations involved.
An important source for requirements will be the past operation and extensive experience of the Office of Emergency Preparedness (OEP) which existed over 25 years until 1973 and was the only agency, prior to the new Department of Homeland Security, which could assume total control of a crisis or disaster situation via executive order of the president and execute the command and control function over all other federal agencies including the military. The remainder of this paper first concentrates on the OEP experience and examines other literature dealing with the functionality to provide those managing a crisis. It then further proceeds to develop a conceptual design approach to an integrated Emergency Response Management Information System (ERMIS). There is a great deal of tacit knowledge gained from experience in emergency response that should influence the design of the functional requirements for emergency response systems.
The objective of this
paper is to set forth some of this wisdom and its resulting relationship to
design and to translate that wisdom into feasible requirements relative to
modern technology.
In the days of OEP, one of the principal resources was its large network of consultants who were experts and specialists from industry and academia. They were individuals who could be called upon to help address issues and problems in both planning for emergencies and attempting to uncover vulnerabilities that were not being adequately dealt with. They were people familiar with critical industries such as energy, communications, or commodities (gas, oil, chlorine, ferroalloys, etc.).
In 1970 a computerized Delphi system (Turoff 1972) was prototyped and this confirmed the ability of a group of 25 people to engage in a collaborative Delphi process via a computer network. The Delphi process (Linstone & Turoff 1975) was the design of paper and pencil based iterative structured surveys to allow large groups of dispersed experts (15 to 500) to exchange knowledge and viewpoints about complex problems. Today Delphi communication structures are also carried out over the Web (Turoff & Hiltz 1995; Wang, Li, Turoff, & Hiltz 2003; Cho & Turoff 2003). It was planned to install that system as a mechanism to better utilize the thousand or so professional volunteer consultants associated with OEP. In 1971 OEP was given the responsibility for a new emergency called a Wage Price Freeze. This event prohibited all changes in prices and wages including those that might have been part of existing contracts for the duration of the event. It fell upon OEP to monitor nationwide compliance, examine and determine requests for exemptions, and to investigate and prosecute violations. The Delphi system was modified in one week to become an “Emergency Management Information System And Reference Index” (EMISARI) for the Wage Price Freeze. The name was chosen to convey to the hundreds of people around the country involved a sense that the system and OEP was providing them what they needed.
There had been no existing plans in OEP for a “wage price freeze” but since the resulting EMISARI system was designed as a communication system integrating people and data into a single data base where all the objects (people or data) could be dynamically changed by non-technical administrators, EMISARI became the only system that could keep up with the evolution of the procedures and processes governing the operation of the Wage Price Freeze. Designed as a communication system (without explicit content), there was nothing in the design that related to the Wage Price Freeze or any other crisis. As a result it was able to be used for any type of crisis. The design focused on the group communication process and how humans gather, contribute, and utilize data in a time urgent manner. EMISARI provided the dynamic ability to tailor the people, objects, and the various data, informational, discussion items, and action items into whatever template is deemed necessary and to modify that template at any time. Such templates were assigned to the members (contacts) of the system by a system administrator who was a management person without any technical training. About one third of the software was devoted to making it easy for an application professional to act as modern switchboard operator by creating templates and matching people to the functions defined by the templates. The existence of full text descriptions for even a single data item allowed individuals to search for what they needed by content descriptions. Templates for data and other functions could be created and assigned in a few moments by the administrator. Finally, the internal markups let the users themselves tailor dynamic reports on a given situation by reconfiguring the current information in the system. This was done by easily specified Hypertext (Web like links) to any existing data or text template. The reports with these links, when retrieved, would always capture and incorporate the latest updates of the defined templates (Hiltz & Turoff 1978, 1993).
EMISARI went on (in the Internal Revenue Service, IRS, and the General Services Administration, GSA) after 1973 to be used over a fifteen-year period for transportation strikes, coal strikes, petroleum shortages, chorine shortages, natural gas shortages and some of the more severe natural disasters (McKendree 1977, 1978; Macon & McKendree 1974, 1975). The lore or tacit knowledge accumulation that takes place in organizations that go through a series of disasters is not often explicitly captured by the organization for reasons we will discuss later. However, natural disasters are valuable events for developing organizational memories and as "occasions for organizational sense-making” (Weick 1993, 1995).
EMISARI allowed, with 1970 technology, two to three hundred users scattered around the country to exercise a single coordinated group response to a crisis. Over the years there has been an accumulated literature on EMISARI (Hiltz & Turoff, 1978, 1993; Kupperman & Wilcox 1972; Kupperman, Wilcox & Smith 1975; Price 1975; Renner, et al. 1972; Rice, 1987, 1990; Turoff, 1971, 1972, 2002, Wilcox & Kupperman 1972).
The Office of Emergency Preparedness (OEP) in the Executive Office of the President grew out of the original OSS (Office of Special Services) operation during World War II. OEP was a single civilian agency that could exert Command and Control over all federal resources (including military) upon the declaration of a Federal Emergency. In such circumstances it could also exert regulation or actions from companies involved in the emergency situation. This occurred regularly in such areas as transportation strikes, commodity shortages, natural and unnatural disasters OEP had a mission to assess threats, plan for the reaction to them, and to execute those plans when needed. It also had responsibility to insure that the government could function effectively in whatever emergency might occur. In practice it was a single agency, at presidential level, where emergency response problems on the part of industry, federal government, state government, and local government could receive attention and action.
In 1973 OEP was dissolved and the various functions of OEP were, in some cases, spread out to other government agencies and/or eliminated from civil government. A number of years later FEMA (Federal Emergency Management Agency) was created as a centralized body, but it has been restricted largely to a reactive role with respect to federal disaster funds management and no significant mission ability for threat assessment, response planning on an integrated government wide basis, and most importantly, overall command and control in an emergency situation. However, the concept of central authority does not mean that those taking actions and making decisions consistent with their responsibilities have to be in one location or belong to one organization. In emergencies, as in military operations, the central authority delegates decision making to those directly responding to the situation.
One of the significant advantages that OEP had was that in an actual crisis they could draft any federal employee the agency felt it needed to be part of the crisis response group. This meant that for any situation the best possible team could, in principle, be created. Most often the process was one of quick negotiation for the talent it needed and only infrequently did OEP resort to ordering the transfer.
There was a lot of lore and wisdom in the operation of OEP and there were still some senior civil servants and consultants from the WWII OSS (Office of Special Services) days who helped to set the tone and atmosphere of the operations of that agency (Hiltz & Turoff 1978; Kupperman & Wilcox 1972).
With respect to information systems, and in particular command and control versions of those systems, we might try to formulate the OEP philosophy in the following set of premises.
An emergency system that is not used on a regular basis before an
emergency will never be of use in an actual emergency.
It is not just a matter of training but of finding actual day-to-day functions that emergency systems can perform so that there is no need for training in the use of the system when the crisis occurs. Any sort of surprise situation that requires a group to be created to react to the circumstances would represent such training opportunities. While many organizations do not like to admit to these events, they seem to be quite frequent. The only training otherwise possible is a quick apprenticeship by sitting at the side of someone who already knows how to react in a crisis and how to use the available facilities. We created in the late sixties a very simple multiple choice Computer Assisted Instructional (CAI) System which would provide a scenario on a given situation and present a set of alternative actions a person could take in a disaster response situation. There was always an “other” choice. Both senior and junior staff at OEP could use it and if they felt there were circumstances not specified that would create a new alternative valid answer, they could choose “other” and explain the circumstances. This very simple system allowed the responders to exchange the experiences and knowledge they had acquired. While in those days we considered it such a simple communication addition to a CAI system that we never published it, one can consider it to day a basic collective memory system. One could, for example, do the same for sales personnel exchanging experiences. Even in the same type of natural disaster the specific circumstances in a similar situation could differ considerably. Not everyone’s experience was exactly like that of others in even the same disaster.
There are actually many events in commercial and governmental organizations that qualify as “mini emergencies” such as strikes, court cases, cost overruns, delivery delay, accidents, new regulations, supply shortage, natural disaster, budget shortfalls, production delay, product or service malfunction, contract negotiation, loss of key employee, loss of key customer, designing or responding to an RFP (Request For Proposal}, competitive actions, etc. All these sorts of events can be “serviced on a regular basis” by the concept of an emergency response system we will be considering. In fact, it is a system ideal for use by large dispersed and asynchronous (i.e., virtual) project teams.
After the prior Northeast Blackout the utilities in the northeast created an emergency dedicated phone system to aid in coordinating activities to prevent another such occurrence. In the Blackout of 2003 there was more than an hour lag between the two major power-lines going out in Ohio and the final 90 second collapse in the New York area. The emergency phone system was not used till after the final collapse throughout the Northeast. One suspects it was a case of a system not regularly used between disasters!
Furthermore, an existing user community is a critical aid during technology diffusion (Rogers 1995) in facilitating the introduction of new and unanticipated users that will always occur within the actual crisis. As a complex operation involving experts in the required areas, the concept of "easy to use" is replaced with "easy to learn" as the primary design objective. Complex situations require a matching complexity of variability in a system designed to respond to such an environment.
People responding to an emergency are working 14-18 hour days and have
no tolerance or time for things unrelated to dealing with the crisis.
This has a significant impact on the design of support systems and rethinking the nature of filters, which attempt to prevent information overload, and searching processes for obtaining relevant information. No one on the front line (physically or virtually) in a crisis has time to read a newspaper, listen to radio or TV, or take or return a phone call without it being clear why they must do so. When involved within an emergency situation they must be able to get the full context surrounding that situation as an integrated process within the system they are using. It also means that one cannot exactly predict what they might be interested in ahead of time.
This also means that the individuals carrying out the roles they are responsible for in the system need to have access to all that is taking place with respect to crisis and one cannot assume that the flow of information can be restricted which usually does occur in a crisis response situation operating under the “threat-rigidity” reaction hypothesis (Rice 1990). Under stress due to the lack of necessary information or coordination awareness people tend to rely on executing action formulas that might be totally inappropriate to the given situation. What may be happening at a different location in the crisis might have an impact on a person’s decision about what actions to take.
Learning and understanding what actually happened before, during, and
after the crisis is extremely important for the improvement of the response
process.
Collecting information on the performance of people and systems in given situations should be incorporated into the design of the systems rather than as an afterthought. The system needs to be designed so that it can be evolved and improved from the understanding provided by prior usage (Keen 1980; Zuboff 1988). Also, capturing the history of what took place without imposing added load on the participants is a critical part of the design objectives. This is related to the next observation.
Almost everything in a crisis is an exception to the norm.
There is no way to predict exactly who is going to be doing what, when, why and/or how at the command and control level in a crisis environment. The crises forces increased decision making by those having to take immediate actions on site. This authority is granted from those above who expect accountability in return so that they can carry out oversight with respect to conflicts for resources and other factors that need to be integrated. Problem solutions and the reallocation of resources go on as a continuous unpredictable process . When a paramedic remains at a site rather than returning with the ambulance it creates a limitation on the use of that ambulance as a fully staffed medical unit to be directed to other sites. What specific data and information is of concern and interest to a given individual is changing rapidly.
Exceptions to the planned response are the critical factors in determining the minute to minute operations. Anything that no one thought of, but which occurs, in the response for a given crisis situation becomes the critical factor in generating problems to be dealt with at all levels in the process. A crisis response system is an information system that has to be an integrated communication and data system where the people involved, their talents, concerns, immediate problems, actions taken, actions planned, situation information, and consequences information are all part of the underlying database and structure. One cannot separate the data processes from the communication processes or from the human processes symbiotic to “data” and “communication” processes.
This means the end user must be able to reconfigure the system interaction in a dynamic manner and designate changes in priorities, filtering and delivery options at any moment during the emergency response process. It also means the system has to dynamically observe these changes and keep others who need to know about them up to date.
The critical problem of the moment is the primary factor which collects
the people, the authority, and the resources that are needed to be brought into
play at that moment in the process.
The crisis response team is a real and virtual community of specialists and experts that must have unrestricted access to one another and is able to act as a collective (Hardeman, Pauwels, Palma, & Van de Walle 1998; Weick 1993, 1995). For specific problems, subgroups with the appropriate talent and backgrounds need to be able to form and function. The system also has to allow for continuity and immediate substitution of individuals when members are lost to the process, forced to reposition their attention, or when they are just plain exhausted. This also speaks to the necessity of training people to undertake multiple roles in a crisis situation and having enough people who can be brought in large scale or prolonged crisis situations.
It is impossible to predict who will undertake what specific role in a
crisis situation. The actions and
privileges of the role need to be well defined in the software of the system
and people must be trained for the possibility of assuming multiple or changing
roles.
Knowing who is available at the time of action has to be determined and taken as a key element of disaster response and the requirements for command and control. Knowing what data relative to a problem is current, what the source is, and what is its degree of accuracy or status of the data is as important as the data itself. Concepts such as roles, responsibilities and the explicit status variables of the data and roles (priority, accuracy, source, actions, interests, concerns, etc.) have to be part of the collaborative database supporting the operation.
Establishing and supporting confidence in a decision by supplying the
best possible up-to-date information is critical to those whose actions may
risk lives and resources.
Emergency response systems must be able to refine the data and information and focus the sources of data on what is critical to a decision. The system must allow for indirect and implicit communication channels between those dealing with interpretation and actions at different levels in the operation. For example, the OEP system, during the Wage Price Freeze, would track the key words searched but not found in various files such the policy interpretation file. The list of words that those people in the field could not find would be presented to the weekly meeting of the policy committee examining requests for interpretations and was used to influence the agenda for the meeting. This is an example of the system providing an indirect communication channel between those in the field and a policy setting committee. The people in the field did not have to waste time making explicit communications. Actions taken are always going to be based upon incomplete information and therefore every effort must be made to obtain and direct the information that is available into a common shared database structure that may be undergoing unpredictable change with respect to the nature and structure of what is being entered.
The extraction of cues form streams of communications and data to create indirect communications is a useful input function for any knowledge acquisition system (Hiltz & Turoff 1978; Wieck 1995). In the emergency situation there is a need for important policy committees in the recovery phase and for prolonged crisis situations which may results in significant differences of view across multiple agencies or government bodies. There can also be a need for very quick reaction committees at higher levels dealing with reacting to possible resource shortages or the integration of outside intelligence into the on going crisis reaction activities.
Crises involve the necessity for many hundreds of individuals from
different organizations to be able to freely exchange information, delegate
authority, and conduct oversight, without the side effect of information
overload.
Consistency of response to all stakeholders is considered a primary requirement. Problems in consistency of response result from the “Niche-Width Theory” (Massey 2001). An organization is either a specialist or a generalist in the scope of the environment and this reflects more limited specific strategies or tactics for the specialist organization. While a specialist agency usually has more correct knowledge about their area of expertise, the generalist agency usually has more influence on policy decisions. This can be applied to the many organizations and agencies involved in a crisis. A good example would be the FBI as a generalist organization and the Centers for Disease Control as more of a specialist agency. The differences in response of these two agencies during the Anthrax emergency are an illustration of the coordination problem typical in a crisis situation. Each agency was operating with different assumptions about the real mission and the lack of quick resolution by a clear authority led to mistakes, public inconsistencies in policies, and undermined the faith of the public in what the government was doing. The Centers for Disease Control wanted the public to have all the details on what was happening for an objective of inhibiting further spread of the disease and the FBI did not want those carrying out the spread of the disease to have some of the information which might inhibit catching the culprits. The problem about how to coordinate among the many agencies involved in a crisis has been expressed on numerous occasions in statements to congress dealing with the formation of the new Homeland Security agency. The challenge is expressed very well by Hale (1997, p. 5 of 15):
“…the key obstacle to effective crisis response is the communication needed to access relevant data or expertise and to piece together an accurate understandable picture of reality.”
Faced with extreme uncertainty, decision makers tend to increase their search for information--often for symbolic purposes and in self fulfilling ways – while simultaneously shutting down some channels of communication, and relying on familiar or formal information and channels (Rice 1987). Furthermore when information overload (Hiltz & Turoff 1985) sets in, groups tend to restrict their information processing and control moves up the chain of command, leaving little flexibility at the lower levels. High levels of uncertainty and information overload are very harmful to reliable disaster response. Fortunately in most crisis situation we do not have to worry about ambiguity as a data corruption problem. As long as the responders are trained in their role responsibilities and there is a history of communication among a key nucleus of the situation reporters and the decision making responders there should be no significant ambiguity problem. However, if the communication system is computer based we have a better ability to put in quick learning aids for those thrown into any situation with out adequate training. If the system knows who they are it can provide additional feedback on what others will think what their words, requests, and actions mean. The system can also enforce apprenticeship by assigning all communications for a “newbie” to be monitored by a real time coach.
The deaths of many of the first responders on 9/11 can be largely attributed to this combination setting in as a result of lost communications. With out awareness of what was happening, the lack of coordination due to the loss of the physical command and control center, and the overload from the immediate stimulus of what was occurring around them, a lot of the first responders were following the rules they had been taught with out reexamination. As a result, we had a tragic example of the threat-rigidity hypothesis at work.
The crux of the coordination problem for large crisis response groups
is that the exact actions and responsibilities of the individuals cannot be
pre-determined.
As we will see this is a result of the uniqueness of each crisis situation, the resulting need for improvising based upon that uniqueness, the reliance on tacit information, and the time-critical nature of the decision process.
Furthermore, governments have certain disadvantages over commercial firms when responding to a crisis. They cannot easily hide what is going on and results in four factors unique to government agencies (Horseley & Barker 2002).
1. Crisis raises questions about the ineffectiveness of government.
2. Frequency of government (in-) action during crises certainly does not imply that government action is always functional or beneficial.
3. Politics can turn crises from “occasions for decisions” into “occasions for restructuring of power relations.”
4. Military and civilian organizations called upon in a crisis may show their Achilles’ heel (e.g. situations they did not expect or plan for) during acutely critical situations.
In theory, government agencies are less likely to get trapped in deceit, as corporations do precisely because they can more easily control and limit information more.
New ways to deal with the unforeseen events evolve with the nature of the crisis. The person needing to make a decision must be assured that anything relevant for the decision can be found in a timely manner; but also understand that precisely because it’s a crisis, what might be considered the most “relevant” information may simply not exist. People can deal with a high degree of uncertainty (e.g., extract cues) to make timely decisions as long as they know it does not result from hidden information that will make their actions appear wrong later. Providing access to all available relevant information at the lower levels is not always the attitude within government organizations.
In a crisis situation authority flows down to where the action is. However, status information and accountability data must equally flow both upward and sideways. In fact, it is also important that teams have accountability as well (King 2002). With the role carrying with it the authority for action and the collection of roles making up a momentary team for dealing with a particular set of related events, we have team accountability as well. This implies a great deal about the functionality designed in an emergency response system. It infers, for example, that the data and actions in such a system must clearly be identified by who is supplying an idea, a plan, a viewpoint, data and/or taking an action.
The sixties and seventies saw considerable academic effort to understand the behavior of individuals and organizations in crisis situations. An excellent report (Dynes & Quarantell 1977) compiled much of this research in to a single document. In their summary they state the following (page 26):
“On the basis of what has been described here, the dominance of a normative planning model which emphasizes coordination by plan is, at best, questionable. The crisis event itself creates the conditions where such coordination is inappropriate. This inappropriateness, however, is not likely to be challenged in post-disaster critiques of organizational functioning which utilizes coordination by feedback. The increase in communication is usually taken as a failure of coordination, not a necessary condition for it. Emergency planning, however, can also be directed toward improving and facilitating coordination by feedback, since it is likely to be the dominant mode in emergency conditions, not a chaotic aberration.”
The extreme of coordination by plan is complete external control of those in the front lines, while the coordination of feedback assumes internal control by those in the front lines of a disaster situation. The nature of the EMISARI system at OEP was the design of a system dedicated to coordination by feedback and it is this mode of operation that is also the essence of the proposed design that follows.
Refusing to recognize the reality of the crisis situation, which is the movement of authority to lower levels and the need for rapid response, often results in the inadequate design of a system that can handle the oversight function in a timely and effective manner. Because many serious decisions are irreversible (Pauwels, Van de Walle, Hardeman & Soudan 2000) this leads to incorrect decisions that cannot be changed or delays in making a decision which eliminates the opportunity for the better alternatives to be chosen.
Taking the above as the assumptions about the nature of a crisis it becomes clear that an Emergency Response Information System must be viewed as a structured group communication system where the protocols and communication structures are provided, but there is little content about a particular crisis except as an integrated electronic library of external databases and information sources. Others have agreed that Group Communication via a computer may be the most appropriate medium for a complex problem requiring input from large numbers of people (McKendree 1978; Price 1975).
A more recent examination of crisis communications challenges highlights some of the same properties (Horseley & Barker 2002):
· Information overload is typical,
· Heterogeneous groups and individuals must coordinate their activities,
· People must work together who do not do so normally,
· It cannot be accurately predicted who will be available and involved at the time of the crisis, and
· Community and public communication is extremely important in dealing with many crises.
All the objectives and requirements discussed so far cut across all types of crisis and emergency situations. We need systems that make no presumption as to whether one is dealing with fires, bombs, hazardous materials, transportation interruptions, etc. It is the lack of dependency upon specified content that makes an emergency response system a powerful tool to apply to any emergency once the users have had the training and experience to master it. There may be supporting data bases that contain content information such as the location and availability of specific resources for specific types of crisis situations or information and knowledge about such things as hazardous materials. These database resources could be anywhere, it is only necessary that the local responders know about them and how to get to use them if needed. However, the system that carries out the response and allows the humans involved to coordinate and exercise various levels of command and control has to be a communication system tailored for the emergency response mission. Fortunately there are communication commonalities to the coordination process in all disaster situations which we can utilize to design the necessary structuring.
Our primary concern is with the design of an Emergency Response Management Information System that will directly support the responders in a local crisis situation and the associated coordination structure among all the involved parties and agencies. We also assume the communications network and computing technology exist to support a reliable network of Personal computers, servers, laptops, and PDA’s, mobile phones, and wireless operations. We are focusing on the supporting software and its required functionality. The significant challenge that is being confronted is to provide a functionality that can be adapted for use on the limited screens of PDA’s as well as the larger screens of desktops and laptops. While it is desirable and useful to consider multimodal interface capabilities, such as the addition of voice input and output (to free up hands for other tasks), it will not explicitly be treated except that the limited visualization capabilities of PDA’s does make the addition of voice input and output very critical as an alternative interaction mode for anyone needing to use their hands for their response activities (Pyush et al., 2002). The ability to record the details of a situation report may also require the ability to convey useful emotional content to express such things as seriousness, urgency, and conviction. The ability to incorporate sound bites emotional icons into any text location and the need for graphics and color is also an obvious assumption. The resulting foundation requirements are:
· Extremely easy to learn via training and exercises because it is consistent with the task requirements.
· Useable by people who will have an understanding of their roles and responsibilities in an emergency environment.
· Will focus on a concise and self-evident design demanded by the small screen orientation and the need to minimize learning.
· Will allow the individual users a high degree of tailoring, filtering, and focusing of the interface tailored to their specific roles and responsibilities.
· Will serve to support planning, evaluation, training, exercises, and system updating and maintenance between crisis events.
· Will allow the operation of the response function without the need for a single operational physical center except for the operation and backups for the computer hardware and software acting as a server and distributed resource databases for this operation.
· Will be designed as a structured communication process independent of the nature of a particular crisis.
To accomplish this we will focus on five very specific criteria for the interface design of a group communication system that is extremely appropriate to the emergency response environment: metaphors, roles, notifications, context visibility, and hypertext.
1. The metaphor or metaphors of a system are the mental models of a system that a user can easily learn in order to create a cognitive map that will make it easier to understand the system. The metaphor allows the user to translate the task objectives into interface actions to carry out those objectives. The type of metaphor that allows a human to create a “road map” or model of an information system is sometimes referred to as a boundary object (Star 1989).
2. The concept of human roles built into the software of group communication systems (Turoff 1990) and supported by specific privileges and tools for carrying out the actions for those roles.
3. The concept of notifications, which are relevant alerts to a user of changes in status, data, and/or information of concern to the given user, brought about by events and/or the actions of other users (Turoff 1990).
4. The concept of context visibility, which is the idea that the components of the meaningful data objects are presented in a context that relates to the understandings of the user. By the user’s choice of a particular data element the system can infer the functions that that the user wants to perform at that point in time. When the user is uncertain as to what will be called up or wants to vary the choice they need to be able to obtain all the possible selections as a submenu. This produces a common sense object interface that makes choices self evident and tailored to the particular user.
5. The original concept of Hypertext (Nelson 1965) which was the possibility of multiple two way linkages with semantic meanings that allowed a person to utilize any item in the content of the application as a set of menu alternatives to move to other content or functionalities in the interface.
By tying these five concepts together we are able to hypothesize some very specific requirements for the design of a self evident Emergency Response Management Information System.
In a foundation paper on metaphors (Carroll & Thomas 1982) the concept was expressed that metaphors were not only useful for training users but that the “right” metaphor could establish the criteria for the actual design of the system, the interface, and its requirements. There is no better illustration of this concept than the emergency response environment. One concept or data construct is understood by all those who deal with crisis management and response: the “event log” of what took place during the crisis. It is the primary concept usually used, after the crisis, to analyze what took place (Hale 1997). Those who have participated in a crisis and tried to understand afterwards what actually occurred, typically use some sort of log of events. The event log is the foundation metaphor for our design.
Instead of a log being a postmortem of what occurs we can turn it into a dynamic evolving record of what is happening as the events of the emergency unfold. Each individual responder would have access to the total log at various levels of summarization. At the highest level would be only the root or triggering events from the external environment that cause reactions to cope with the situation. Clicking on any one of them opens the sub log of everything associated with the collection of information about the event and the resulting responses to the root event as well as the associated resources committed by recorded actions. Clicking on any of the entities in the log will result in obtaining all the relevant links from that item to the various forms of associated information. The log is the on going roadmap of the emergency, which provides access to all the associated trails being blazed by the resulting actions. The user can quickly travel in any direction that is of concern to them. A responder would mark the events they need to track in order to carry out their role and responsibilities. Any resulting actions of a marked event would be delivered to that user in the future.
To accomplish this, the system needs to allow the users to establish templates for an integrated set of logs. A single root log by a single individual can create over time, as a result of future conditions, a whole sequence of related event logs. A typical example of root/parent log and its possible branch/children logs are:
Request resource root event log (location, situation)
Allocate (or deny, delay, partial allocation) of resource
Trigger a “maintenance of resource” as a new root event
Resource in transit to destination
Arrival of resource at desired location
Status change in condition of resource
Status change in condition of situation
Recycle of current incident event for more of the same
Resource reassigned before completion
Completion of original root event transaction for this resource
Resource in transit to normal location
For example, the above sequence or log template might be used for a medical unit, which is typically composed of an ambulance, a driver, a paramedic, and various supplies along with a fuel supply. However, any given unit might vary in the details (e.g., containing a doctor). Furthermore, during the event the paramedic or the doctor might remain on the scene as the ambulance takes others back to the hospital. A delayed response could occur because the only ambulance available needs to be refueled before it can start to satisfy the original request.
During 9/11 there was no prior plan that called for using a ferry to act as an ambulance to deliver patients to the emergency outdoor medical area set up in Jersey City. Some event sets might have to be generic so that the concept of something like a medical unit can dynamically be redefined for a particular resource request event. In this case a new type of medical unit would have to be established in the resource database during the crisis. This nicely illustrates that particular resource types might need to be established in the database during the crisis. It is the structure and process that comprise the software and not the content. In this manner the system can be adapted to any type of crisis.
The above template for a resource request when started for a specific instance would have the information on the reason, situation, and location that is the cause of the request entered (to the extent information is available, and the form should allow for multiple contributions to these, as different individuals in different locations will have different reasons, situations, etc.). Such information might be updated as the request is in progress. There might be a large set of resource requests sharing elements of the basic situation information and at any time details can be updated which in turn might have impacts on the resource requests and their adequacy. In addition, there needs to be the ability for a new type of event template to be created during the crisis situation.
Different people have as part of their “role” the authority for launching a given event type which may be a root or response event in a template. This brings up the use of a secondary but no less important metaphor, that of the “checklist” (Hale 1997; Lukaszewski 1987). Triggering an event brings up a checklist for the person to fill in the appropriate data and check off appropriate choices; but always assuming free form inputs for unexpected “other” unpredicted factors. It would pinpoint the other roles that will be needed and whether they are occupied at that point in time, and display any other conditional impediments that might have to be considered such as the possibility of a delay and the reason for it. If a medical unit cannot be immediately dispatched it might cause the people on the scene to take other or alternative actions (e.g., dispatching some injured in other vehicles).
The person creating an event must be able to have the information that allows him or her to conclude that the related events will be able to proceed with reasonable dispatch. In the original EMISARI system there was a code to indicate that needed data was not yet available which would substitute for the data in the output field. Also with any such item the information was also provided as to who would be responsible for supplying and updating that data item.
A typical mode of operation would be for everyone to receive those root events for the types, locations, and other conditions that they are interested in (i.e., marking them explicitly or having them linked to a marked event). In addition only those events that the user marks for tracking would result in the future delivery of other logs in the event template when they occurred. In this manner the crisis responder sets up their own filtering mechanisms as events occur. Clearly the person creating a root log event would automatically be delivered all follow on log items. There needs to be an override where one person can determine if another has marked an event for tracking and if not trigger a resending of the event to the person who has not been tracking it. This provides the opportunity for oversight and alerting individuals to items they may have overlooked. The use of codes to designate missing information allows users to search and identify and undertake efforts to obtain the missing data.
The use of event log templates was added to a derivative of the EMISARI system (PREMIS) which was used to track the actions with regard to violations of federal orders with respect to numerous commodity shortages declared as federal emergencies in the seventies (McKendree 1978). That system specified what actions the responsible party could take for a given event/step in the procedure and depending on the action notified the appropriate role (person) that it was time to take over responsibility for the given event. The proposed concept of a crisis decision unit (Smart & Vertinsky 1977) is a subset of the concept of event templates for crisis situations.
Roles have always been a key part of any structured group communication process (Turoff 1991, 1993; Turoff et al. 2001). Roles were a key concept in the original EMISARI crisis management system (Hiltz & Turoff 1978; Mckendree 1977, 1978). Any piece of data in that system was always identified by who was responsible for supplying it and updating it. Who could launch what type of actions/events was also very clearly displayed and available for retrieval. A person’s entry in the directory had a dynamic (time wise) list of any responsibilities and was searchable by responsibilities by every member of the systems.
In a crisis it is never certain who will take on which role or which combination of roles. It is expected that people will be trained to be qualified in a number of different roles. While one recognizes that a policeman is unlikely to take on the role of a fireman, when it comes to roles of reporting, making requests for resources and assigning resources we would expect that cross training is in fact feasible. At the time of a crisis the first qualified person active in the system could immediately take on the highest priority role or roles they were pre-qualified for. In some emergency situations individuals might be pressed into roles they are not completely qualified for if there is no one else available at the moment. If this is a likely situation than we need to worry about ambiguity, real-time training, training aids, and more active oversight requirements for monitoring in the system design.
The persons with the authority to assign roles could assign roles to any active member of the system based upon what was needed at that time. At a minimum, there are eleven fundamental roles that can take place in a large scale crisis situation. These are:
Fundamental Roles
1. Request resources: people: medical, police, fire, military, construction, utilities, etc.; things: medical units, transport, fuel, equipment, etc.
2. Allocate, delay, or deny resources
3. Report and update situation
4. Analysis of situation
5. Maintain resources (logistics)
6. Acquire more or new resources
7. Oversight, consulting, advising
8. Alerting
9. Assigning roles and responsibilities when needed
10. Coordinating among different resource areas
11. Priority and strategy setting (e.g., command and control)
In any crisis there are requests for resources; other people must decide if the request can immediately be satisfied or has to be denied or delayed. There is also a need to report the situation at different locations and for different dimensions (medical, fire, police, etc.) and for others to analyze the incoming information to determine the implications for those:
· allocating resources,
· maintaining current resources, and
· acquiring additional resources to meet an expected demand.
In addition we have, in many situations, the need to position resources, obtain specialized knowledge (e.g., hazardous materials) or to raise or lower the level of the current response to the crisis. In the original EMISARI system one could dynamically establish report forms, including quantitative and qualitative inputs and assign them to people responsible for reporting the situation.
Usually, people deal with medical, fire fighting, law enforcement, military, utilities and construction resources so that many of these fundamental roles are multiplied by the types of specific resources being considered. This means coordinators must take the responsibility to ensure responses from these multiple resources are not interfering with one another. Typically today the response systems for these different areas are separate and the details of what is going on with any one of them is not available to all that are involved. In World War II, the army and Navy decoded the Japanese transmissions on alternative days and prepared summaries for the leadership. Too late it was discovered that if the analysts had had access to the total file the likelihood of an attack on Pearl Harbor would have been much more obvious.
In terms of our metaphor of the use of a dynamic log, a role is defined by the privilege associated with the role which than authorize:
1. Creating Event log entries of a given type
2. Responding to specific types of event log entries.
3. Supplying information or data related to specific events.
4. Producing situational and interpretive reports related to sets of events.
The role is an explicit object in the database that has specific links to all the other data objects in the system and those links carry privileges for actions on the data in the system (Turoff 1991). But in the actual emergency it will be a human who takes on the role and carries out all the activities and privileges associated with the role. This was true in the first group communication system (Turoff 1972) for carrying out Delphi Exercises and in EMISARI.
The critical general property of computer-based communications that we are utilizing in designing a group communication system for crisis response is that only by using a computer can the content of the information being communicated also be the “address” for delivery (Hiltz & Turoff 1978; Turoff 1991, 1993, Turoff, et. al. 2001). People in a crisis have to focus on information needed and the currency of the situation factors that relate to the decisions and actions they are taking. Since what they need to know is very dependent upon the actions and knowledge of others, we need to notify the user of the impact of those particular items that relate to their roles, actions, responsibilities, and what they have decided to track in terms of current events in the system. By having the users and their dynamic properties as an integral part of the data structure of the system, the computer can determine who should be sent what notifications. Any other unstructured alternative like email would quickly lead to information overload (Hiltz & Turoff 1985). Given the unpredictable nature of a crisis and its reliance on tacit (unique) knowledge (Hayek 1945) being generated by the situation, one cannot develop or use algorithmic rules for the delivery of information. The system must allow the users to self-organize the information by their actions. Tacit knowledge can be acquired only through experience such as observation, imitation, and practice (Kim 1998).
As an example, the current number of ambulances that have been assigned and which could be assigned is a dynamic variable which is resulting from events requesting the use of ambulances and the consumption of resources needed to maintain the ambulances. At some point there is a need for a notification to one or more individuals that such a resource will run out at a certain time based upon both usage rate and the expectations of additional causalities due to further possible damage. Someone has to seek an additional assignment of ambulances or vehicles that can serve this function to the resource pool and determine where they should be positioned. Another example of tacit knowledge is the assignment of roles, for example, knowing who would be the best reporter for a given situation at a given time in the crisis. In essence, when the information is not complete and not expected to be, the decisions will be utilizing the tacit knowledge or the intuition of the decision makers.
Depending on the nature and extent of the crisis, resources will start to run out and a very dynamic inventory function is needed just to alert the responders to projected consumptions of resources. A human must determine when an action must be taken. The local road conditions, extent of the crisis and numerous other factors make automatic assignment impossible. Even if the supply of ambulances is running out, only a human can decide if the depletion rate and the demand rate in a given crisis situation will require re-supply.
Another critical type of notification is the “canned notification” (Turoff 1991) which also has roots in automated command and control systems in the military. There are a number of distinct types, including response check-off and fill-in.
The response checkoff type of notification is where someone indicates they want to respond to a particular item and obtains a list of alternatives from which they can choose a response that will become linked to the original item and be received by any one who received the original item. Examples are:
I agree/disagree with it
I am taking care of this
Delay this action
Give this higher/lower priority
Since the notifications are standardized and are linked to the item they are referencing there is no resulting ambiguity and their creation and sending takes only a few clicks.
The fill in type is where the receiver of sender can fill in a specific item of quantitative or qualitative data with the notification
Need info on (subject)? (data, e.g. number of injured)
Will have more info by (time)
We will need (number) more (supply item)
What is your best estimate of the injured? (number)
The specific wording of any type of notification is not important since the systems should be designed that so that the local user population can define and change these at any time as an evolving process in the evolution of the system. What is important is to capture those short messages that will be likely and repetitive in any crisis and allow people, as a result, to communicate with an absolute minimum of input operations by utilizing such preformatted communication items.
This type of notification also serves as a retrieval handle in that any click on this notification will bring up the details about the item it is referring to. This leads us to the concept of “context visibility” that is critical to the success of this type of system.
A log event entry has associated with it the categories of information it is concerned with such as:
· Log identification
· Resource type(s)
· Author and/or responsible party
· Relevant location
· Relevant circumstances
· Next expected event or events and role responsibility for action
· Status (associated events in the root log sequence)
· Allowed or generated lateral logs (new root event logs)
· Allowed or generated notifications
· Footnotes or other linkages
An event generating specific maintenance or re-supply of existing medical units or an event to acquire more medical units should be linked to any medical unit requests that have not yet been serviced.
The elements that are attached to a log can act as the menu choices for the users to find out more information about the particular item in the log. For example, clicking on an item in the log brings up various information about the item, as suggested in the following table:
Alternative Object Links (Hypertext Relationships)
|
Context item |
Retrieved
possibilities |
|
Log ID |
All event logs which are children of this one The parent or root event log Lateral generated “brother/sister” event logs |
|
Resource Type |
Current status of this particular unit Status of all units in this state Status of all units at location Status of all unit |
|
Author or responsible party |
Current responsibilities and status Backup individuals Expected time for completion of action for this log or notification item |
|
Circumstances |
All associated status and qualitative information required for this event |
|
Location |
A map or diagram of location area and what is there as well as it is known about what is there. A text / table list of what is there |
|
Status |
List of completed events in this sequence List of incomplete events in this sequence All events in this sequence |
|
Linkages |
Notifications linked to this particular event Notifications linked to this sequence of events Updates and reports relevant to this event |
|
Expected events |
Who is to act on which events as a result of this one |
|
Footnotes |
Any footnotes of added explanations by anyone concerned with this event |
Words and abbreviations in the specific context of an event log are used in much the same way as an icon is used to launch functions in an interface. The advantage over icons is the much larger vocabulary of choice that the use of semantic memory allows us. This concept is an extension of context sensitive help function (i.e., Apple’s System 7 Balloon help) in interface design applied to the primary interaction as opposed to only the help function – similar to Web mouse-overs, or pop-up comments on MTV videos!
The design capitalizes on episodic memory to allow people to track cognitively what is taking place in time and the semantic memory to bring up the needed data or information to take required actions. The role of the person determines what root events he or she will receive and there will be a function which allows the user to indicate if that particular log is one that they wish to follow or track with respect to the log items this event will trigger as children or peers. This method of self