acm-header
Sign In

Communications of the ACM

On site

Past and Future Emergency Response Information Systems


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. Until it was eliminated in 1973 by the same executive order that removed the Office of Science and Technology from the executive office, 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. This occurred regularly in such areas as transportation strikes, commodity shortages, natural and unnatural disasters. It had a mission to assess threats, plan for the reaction to them, and to execute those plans when needed. It also had responsibility to ensure that the government could function effectively in whatever emergency situation might occur. In practice it was a single agency, at a presidential level, where emergency response problems on the part of industry, federal government, state government, and local government could receive attention and action.

In emergency situations OEP could take over direct command and control of any federal resources, including military, and it could also request specific actions from industry and state or local government. It had all the centralized command and control facilities for civil emergency response that seems to be lacking today.

Back to Top

The Emergency Response Atmosphere

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 wartime OSS days who helped set the tone and atmosphere of the operations of the agency [1]. With respect to information systems, and in particular command and control versions of those systems, one might try to formulate the OEP philosophy as follows:

  • An emergency system not used on a regular basis before an emergency will never be of use in an actual emergency.
  • People in emergencies are working 14- to 18-hour days and have no tolerance or time for things unrelated to dealing with the crisis.
  • Learning and understanding what actually happened before, during, and after a crisis is extremely important for improvement of the response process.
  • Almost everything in a crisis situation is an exception to the norm.
  • There is no way to exactly predict who is going to be doing what, when, why, and/or how at the command and control level in a crisis environment.
  • The critical problem of the moment is the primary factor that collects the people, the authority, and the resources needed to be brought into play at that moment in the process.
  • Roles can be planned but whoever steps into a given role at a given moment defies any attempt to prescribe ahead the composition of the response team or their individual responsibilities.
  • Establishing and supporting confidence in a decision through supplying the best possible up-to-date information is critical to those whose actions may risk lives and resources.
  • Exceptions to the planned response are always the critical factors in determining the minute-to-minute operations.
  • Crisis situations 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.
  • Exact actions and responsibilities of the individuals cannot be predetermined, since new ways to deal with the unforeseen events evolve with the nature of the crisis.

Taking this list as the assumptions, it becomes clear 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 situation except as an integrated electronic library of external data and information sources.

Back to Top

Historical Insights

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 the planning for emergencies and the attempts to uncover vulnerabilities not being adequately dealt with. They were people familiar with critical industries such as energy, communications, commodities (gas, oil, chlorine, and ferroalloys, to name a few).

To a large extent in the late 1960s and early 1970s these individuals were called upon in the classical method of travel and coming together in a small group to address specific issues that had arisen within some planning or threat assessment review. However, it was well recognized that this was an underutilized resource and in the late 1960s OEP conducted a number of Delphi studies to see if large groups of experts could contribute a richer database of ideas and concepts that could be done without travel and small groups.

In 1970 a computerized Delphi system was prototyped and confirmed the ability of a group of 20–30 people to engage in a collaborative Delphi process via a computer network. It was planned to install the system as a mechanism to better utilize the 1,000 or so volunteer consultants associated with OEP as contributors to the planning process on a continuous basis. In 1971, OEP was given the responsibility for something called a Wage Price Freeze and the Delphi system was modified in one week to become an Emergency Management Information System for the Wage Price Freeze (EMISARI). Over the next decade EMISARI was used for transportation strikes, coal strikes, petroleum shortages, chlorine shortages, natural gas shortages, and some of the more severe natural disasters. EMISARI allowed 200 to 300 users scattered around the country to exercise coordinated response to crisis situations.

Since this response system was designed as a communication system, there was nothing in the design relating to the wage price freeze or any other crisis situation, and as a result it was able to be used for any of them. The design focuses on the group communication process and how humans gather, contribute, and utilize data in a time-urgent manner.

Back to Top

Resulting Requirements

It is useful to translate some of the objectives into specific requirements for fulfilling the emergency response mission. These specifics are slight extensions of what once existed in the OEP EMISARI system and the companion PREMIS system, which was designed for collaborative action taken on a case-by-case basis.

The system had a human monitor comparable to a switchboard operator in early phone systems or the Delphi Monitor in a Delphi Exercise. This was a nontechnical person (but an application content expert) responsible for defining the structure of the system and changing it at a moment's notice to accommodate new requirements. The powers of this position include:

  • Establishing a member of the system.
  • Establishing a group or role to which a number of members belong.
  • Establishing any type of data input requirement (a single numeric estimate, a column of data, a table of data) by creating the label, title, and detailed description.
  • Establishing an information item that is a text report but having the same explanation or index properties as the quantitative data item; EMISARI had unique reference tags for many types of items (data, messages, text, contacts) where users could put simple markups in their text to have the current version/value of the item displayed in their "report" type text item (an internal primitive Web).
  • Establishing what member or members within a defined role group have the responsibility for reporting the given data item.
  • Establishing a single discussion thread, designating who is able to input root items and who is able to put in reply items (such threads would have labels, titles and descriptions as well).
  • Providing a moderator of such a single discussion thread who thereby can edit or modify entries as needed.
  • Establishing a conference that can be a collection of any subset of discussion threads.
  • Deciding which automated notifications are triggered by changes to data and or specified discussion threads and to whom they are delivered.
  • Establishing an action template item that is:
       a.) A description of the type of case, situation, or requirement to be handled by this action item;
       b.) Defines various states that an action can be in;
       c.) Defines for each state what decision options are available (including "other"), who or what role can indicate the decision choice for that state, and which new state takes effect based upon that decision.
       d.) A change of state would automatically notify those concerned with processing the next action state.

What we have listed is the ability to tailor the people, objects, and the various data, informational, discussion items, and action items into whatever template is necessary and to modify that template at any time. One can have a set of action templates that may be utilized to treat as many incidents of that action as needed. The objective of the system is to allow the distributed and probably dispersed group of people to track and coordinate their activities as needed. The existence of full-text descriptions for even a single data item allows individuals to search for the data needed. Finally, the internal markups let the users themselves tailor dynamic reports on a given situation by reconfiguring the information in the system.

The concept of a notification is a key to the system:

  • A notification is a short item representing an alert to some change made by others.
  • A change could be actions taken, new data entries, responses to earlier comments, the occurrence or change of some object the user is interested in, and so forth.
  • Any actions taken by the system or the users can be the cause of a notification.
  • Users can tailor notification delivery by merely tagging something they want changed.
  • System monitors can also designate notifications to be sent or not sent on a selective basis.
  • Most important, the notification itself is the retrieval link for the full item.

Given today's use of handhelds for those working in the field during an emergency, the concept of the notification, which was quite prominent in EMISARI, should probably be the core of material delivered automatically to the handheld devices.

A key to the performance of the system is that it keeps track of what people are actually searching for and provides a list of what is being searched for and not found for those who may be able to supply that information. A further key property is that everything put in the system is identifiable by the contributors name/ID and when it was entered. In addition, the contributor may designate a number of adjectives to indicate condition or quality of the reported information. These adjectives would be a stored selection list for all the users with clear guidelines as to what the adjectives mean.

Another key item is that one may launch a discussion thread tied to any data or information item. This means that people can find one another and create various ad hoc groups that are brought together by having only a common interest in the data or information item at a particular moment in time.

"The content of a message becomes the address." This is an extremely critical factor in the dynamic operation of such a system. It is the fundamental property that allows computer-mediated communications systems to be self-organizing. The person reporting an item may have important footnotes to add about such things as the accuracy, completeness, timeliness, or reliability of the data. The person seeking to determine the meaning of the data can express his or her interpretation of what the data means and a person having a completely different hypothesis may express that view. People seeking to take an action can express what is still missing in their ability to have confidence in the action taken. As a result, the monitor can immediately form a related data or information item and assign the responsibility to someone as the reporter of that item who might have a chance of getting it.

Back to Top

Online Communities of Experts

In order to provide the necessary training, the emergency response information system might be used as an exceptional reporting system for everyday operations, and in that capacity it will give the individuals in the response network the opportunity to learn and master the system. The development of online communities of experts that can be utilized for emergency planning and called upon in a crisis would seem to be the desirable choice.

It was an objective in the days of OEP and it should be an objective today to provide relevant communities the sort of collaborative knowledge systems they will find useful for exchanging professional information and advancing the state of their field of endeavor. This is the foundation that will provide the day-to-day use of the technology by the experts supporting the crisis-planning operation.

On top of this service is an ability to collect and tap the minds of these individuals for information that includes such considerations (and the relationships between them) as:

  • Potential threats;
  • Refinement of the threats;
  • Consequences of the threats;
  • Potential counters to prevent threats;
  • Specific plans and responses to the actual occurrence of a threat;
  • Critical resources and facilities for responses;
  • Organizational roles; and
  • People roles.

As a collaborative effort the group as a whole could comment and reflect on any of the items suggested and use scaling and voting decision support tools to judge things like the severity, likelihood, and effectiveness of the individual contributions.

If one individual suggests a new threat he or she may not be the best one to decide counter-actions, and these may arise from other members of the group. It is the synergy between a large group of experts able to reflect and contribute whenever a new aspect of the problem occurs to them that provides for the accumulation of knowledge in a meaningful structure. It is also clear that the evolving knowledge and ideas may very well lead to continual refinement of this structure.

None of the available communication support modes today have quite the sophistication and tailorability for the emergency response and collective knowledge gathering ability of the original EMISARI.

Many organizations seem to have minor crises all the time (delays, cost overruns, bids or proposals, to name a few). These can be used as the training ground for more suitable emergency response systems that can also serve major disasters.

In a crisis situation authority flows down to where the action occurs. However, status information and accountability data must equally flow both upward and sideways. Crisis management creates the need for many hundreds of people to be involved as a large coordinating body. To accomplish this with such large groups the requirement is for both a highly flexible (adaptive), but also structured group communication system.

Back to Top

References

1. Hiltz, S.R. and Murray, T. The Network Nation: Human Communication via Computer. Addison Wesley (Revised edition, MIT press, 1993).

Back to Top

Author

Murray Turoff ([email protected]) is a distinguished professor and chair of the Information Systems Department in the College of Computing Sciences at the New Jersey Institute of Technology. He designed the EMISARI system for the Office of Emergency Preparedness.

Back to Top

Footnotes

For a longer version of this column and related references see eies.njit.edu/~turoff


©2002 ACM  0002-0782/04/0100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2002 ACM, Inc.


 

No entries found