The Pennsylvania State University

The Graduate School

School of Information Sciences and Technology

THE INFORMATION-TECHNOLOGY-PEOPLE ABSTRACTION

HIERARCHY: A TOOL FOR COMPLEX INFORMATION SYSTEM

DESIGN

A Thesis in

Information Sciences and Technology

by

Arthur C. Jones

© 2004 Arthur C. Jones

Submitted in Partial Fulfillment of the Requirements

for the Degree of

Master of Science

August 2004

I grant The Pennsylvania State University the non-exclusive right to use this work for the

University’s own purposes and to make single copies of the work available to the public

on a not-for-profit basis if copies are not otherwise available.

____________________________

Arthur C. Jones

The thesis of Arthur C. Jones was received and approved* by the following:

Michael D. McNeese Associate Professor of Information Sciences and Technology Thesis Adviser

Steve Sawyer Associate Professor of Information Sciences and Technology

Daniel Lorence Assistant Professor of Health Policy and Administration

Joseph Lambert Senior Associate Dean, School of Information Sciences and Technology Chair, Graduate Programs Advisory Committee, School of Information Sciences and Technology

* Signatures are on file in the Graduate School

iii

Abstract

This work presents a general model for developing the requirements and

constraints for the construction of information systems. The model is based upon

Rasmussen’s [1986] abstraction hierarchy model, but substitutes the elements of

information, technology, and people as peers in place of the traditional whole-part

hierarchical decomposition. The resulting Information-Technology-People Abstraction

Hierarchy is shown to have utility for information systems engineers and is demonstrated

by applying the model to the design of a system for emergency services dispatch

operations.

iv

Table of Contents

List of Figures ...............................................................................................................vii

Acknowledgements ......................................................................................................viii

Dedication......................................................................................................................ix

Introduction.....................................................................................................................1

Review of Literature:.....................................................................................................10

The Abstraction Hierarchy Model ......................................................................10

Ecological Interface Design ...............................................................................18

Information, Technology, and People.................................................................20

Theoretical Framework: the "I-T-P Abstraction Hierarchy" ...........................................24

Introduction .......................................................................................................24

Supporting Literature .........................................................................................28

Using the I-T-P Abstraction Hierarchy Model....................................................29

Application: Emergency Services Dispatching ..............................................................35

Work Domain Analysis Methodology ................................................................41

v

Work Domain Analysis......................................................................................44

Results ..........................................................................................................................61

I-T-P Abstraction Hierarchy for Emergency Services Dispatch ..........................66

Resulting System Specifications ........................................................................68

Prototype Development......................................................................................70

Broader Implications of Findings .......................................................................76

Discussion.....................................................................................................................78

Contributions .....................................................................................................78

Future work .......................................................................................................79

Conclusion ....................................................................................................................81

Appendix A: examples of I-T-P Abstraction Hierarchy models for non-technology-

centered projects............................................................................................................82

Appendix B: database schema of prototyped system......................................................84

Appendix C: interview outlines used during site-visits to emergency communications

centers...........................................................................................................................85

Appendix D: references related to the WDA and demonstration system.........................88

vi

References:....................................................................................................................91

vii

List of Figures

Figure 1 - Abstraction Hierarchy Model; adapted from Rasmussen, et. al. [1994] ..........12

Figure 2 - General Purpose I-T-P Abstraction Hierarchy................................................26

Figure 3 - The primary display of an emergency communications center’s supervisor’s

station....................................................................................................................58

Figure 4 - High-level I-T-P Abstraction Hierarchy for Emergency Services Dispatch

CIIMS ...................................................................................................................68

Figure 5 - A screenshot of the prototype system’s main user interface ...........................72

Figure 6 - I-T-P Abstraction Hierarchy for Stock Market Fund Managers......................82

Figure 7 - I-T-P Abstraction Hierarchy for this thesis ....................................................83

Figure 8 - database schema of prototyped CIIMS for emergency medical services control

..............................................................................................................................84

viii

Acknowledgements

I would like to express my sincere thanks to the members of my thesis committee.

Your guidance and encouragement made this possible, and relatively painless. The

knowledge and advice I have collected from you in the past few years will continue to

benefit me for years to come.

The School of Information Sciences and Technology, as represented by the

faculty, the Deans, and the administrative staff have earned my gratitude and respect. I

am happy to have found an academic home which acknowledges the need to approach

real-world problems from a variety of perspectives to find practical solutions.

Thanks go to the individuals and organizations who gave their time to allow me to

understand their work. Because that work is relatively hidden from the public eye, I

would like to thank all emergency services communications personnel, everywhere, for

what they do.

The support and encouragement from my friends, co-workers, and classmates has

been much appreciated.

Finally, and most significantly, I would like to thank my entire family, but

especially my wife, Maureen. She, more than anyone else, has sacrificed and adapted to

allow me to pursue this work. I surely could not have done this without her.

ix

Dedication

This work is dedicated to the men and women who answer the call for help with

their skill, dedication, professionalism, and bravery. My time serving in the emergency

services has made me who I am and given me some of my closest friends. I hope that

anyone who joins those ranks can feel the same camaraderie and sense of

accomplishment I have enjoyed. It is also my hope that this and similar research can

make your work safer, easier, and more effective.

1

Introduction

Information system design is difficult, particularly when the system is required to

adapt or scale for use in situations that exceed the complexity of standard day-to-day

operations. Such situations might arise unexpectedly and take forms that had not been

imagined previously. These situations are known as critical incidents, highlighting their

departure from the status quo. The term “critical incident” as applied here is an extension

of Flanagan’s [1954, pg. 338] concept: “… defined as extreme behavior, either

outstandingly effective or ineffective with respect to attaining the general aims of the

activity.” The extension applied to this definition is in consideration of the response to

unforeseen circumstances, and an acknowledgement that some circumstances can not be

foreseen. The resultant implication is that a critical incident may exist whenever the

effectiveness of the behavior is uncertain and is not assessed in real-time.

Flanagan’s critical incident technique, which has been widely applied in cognitive

engineering research (see [Koenemann-Belliveau, et. al. 1994][Xiao & Mackenzie

1998][Fountain 1999]), relies on a post-hoc evaluation of information deriving from

critical incidents, or the assessment of imagined worst-case scenarios. The supposition is

that future critical incidents will not be so novel as to defy attempts to be categorized

within the frameworks produced by the technique. The expectation of such novel events

drives the need to construct systems capable of minimizing their impact rather than

attempting to avoid them altogether.

2

The term “information system” in the context of this work refers to the organized

interactions between people, information and communications technologies, and the data

or information (the words will be used interchangeably) itself. In this sense, information

is conceptualized as an object which can exist independently, but can also be embedded

into a larger system. Information, thus, has many of the same properties as technology or

people. As an example, consider a work schedule for the employees of a small company.

The work schedule is a form of information. It may take on a variety of forms, such as an

aggregate display of all the employees, or a single employee’s specific assignments.

These forms are straightforward independent embodiments of the schedule. The schedule

information might also be used as part of a production plan, or within the company’s

payroll system for very different purposes. In these instances, the information is

embedded within larger contexts. This is echoed by the various forms of the concept of

“people.” People may be individuals who are simultaneously members of larger social

units such as workgroups, organizations, cultures, etc. Information and communications

technologies are the easiest of the three elements to visualize in this way, because they

usually have physical presence. Individual computers may be connected to others to form

networks.1 Each of the three information system elements of information, technology,

and people, may simultaneously act at a number of levels of aggregation.

1 “Technology” is not synonymous with “computers,” as is often assumed when speaking of

… (note continued on next page)

3

The proper design of information systems can be of significant importance to

people, ranging from individual users to society at large. Information systems are integral

to many, if not most, components of the national infrastructure of the United States

[Boin, et.al. 2003]. Many of these information systems have risen to a level of complexity

which exceeds their initial specifications. The additional complexity and societal reliance

upon these systems should not be seen only as vulnerabilities. In fact, the ability to utilize

networked information systems to detect and thwart potential problems is of great interest

to homeland security officials [Moodie, et.al. 2000]2.One of the areas of national

infrastructure which relies on information systems is the realm of emergency services,

and in particular the dispatch and communications components of that system. The

emergency services include police, fire, ambulance, general and specialized rescue, and

many similar supporting services. The management and coordination of all of these

services requires the management of a great deal of information, for which a number of

specialized information systems have been developed. The bulk of these systems exist

within the emergency communications centers, which are tasked with receiving,

assigning resources to, and monitoring the progress of, emergency incidents of various

information systems in today’s society. The printing press is a form of information technology. Paper is a form of information technology. Moreover, it is important to recognize that “technology” in no way implies an electronic, mechanical, or even tangible artifact. In the example of a work schedule, a commonly understood grid arrangement of the data is a form of technology; as is the standardized representation of points in time. In a more general sense, you can consider any language as a form of technology.

2 Though this publication pre-dates the September 11th attacks and the subsequent formation of the Department of Homeland Security, its topics are now under the influence of the DHS.

4

types. Especially when atypical incidents occur, requiring the assignment of multiple

resources, accurate information within these systems becomes critical to the achievement

of an optimal outcome.

Emergency management organizations, and their accompanying information

systems, were first implemented at the local level. Over time, the pace of technological

advancement has made possible the sharing or consolidation of resources. This

reorganization has spawned significant changes in the scope of capabilities required to

support the missions of the information systems. For example, Turoff [2002] describes

the development and use of a computer-mediated collaboration system for accessing the

opinions of communities of experts relevant to particular emergency management

situations. The system described dates from the early 1970’s, when such collaborative

capability was just becoming practical. Since that time, the growth of the internet and

other information and communications technologies has allowed emergency response

personnel to more quickly and easily access needed information resources (See [Athey &

Stern 2000][Holzman 1999][Crow & Jonson 2001][McCarthy, et.al. 1997]).

The application of evolving information and communication technologies to the

domain of emergency services dispatching has, over time, increased in complexity. This

complexity is not limited to the electronic hardware employed in the systems. The

information itself has become more complex, reflecting changes in the complexity of the

environment it describes. For example, ambulances in the past were expected to do little

more than carry a patient to a hospital. Modern ambulance services include a range of

5

medical capabilities including advanced cardiac assessment, and rapid-action

pharmaceutical interventions. The variation of capabilities among the emergency service

providers has led to the requirement to better assess needs as requests arrive. The result of

these changes is the collection and processing of more information.

Complex systems are threatened primarily by their failure to accommodate

unanticipated circumstances [Vicente & Rasmussen, 1992][Vicente 1999]. The failure of

complex information systems is made more tragic when the domain of operations of the

failed system routinely involves atypical and often novel events. Examples, such as the

1992 London Ambulance Service’s failed deployment of a new computer-aided dispatch

(CAD) system dramatically demonstrate both the criticality and complexity of some

information systems. (See [Finkelstein & Dowell 1996][McCarthy, et.al. 1997]) The new

system was planned to be a leap forward in the automation of emergency ambulance

dispatch. Instead, within hours of becoming active, the system began experiencing major

problems and was eventually shut down completely. The incident is described as an

example of a systemic failure, rather than a failure of any one piece [Finkelstein &

Dowell 1996].

Knight [2002] includes the London Ambulance Service incident with several

other examples, including some from the nuclear power industry, to demonstrate the need

for well-constructed “safety critical systems.” The fundamental problem cited in these

systems is communication failures between engineers involved in their design and

construction. In the absence of accurate communication, incorrect assumptions are

6

incorporated into system designs, leading inevitably to their failures. One of the most

memorable examples of this phenomenon is the Mars Climate Orbiter crash, caused by

incorrect assumptions concerning the units of measurement used in navigational

calculations.

The additional requirements of developing an information system that is able to

support non-standard operations as well as fulfill its day-to-day routine can become much

more challenging [Knight 2002][Rouse 1981]. The design of information systems which

concurrently address the needs of multiple layers of specification, ranging from the most

elemental to the very general may seem to imply greater complexity. In reality, it is not

the design that must be more complex, but rather the design process. The benefits of the

extra energy expended in designing such a system can have significant effect during

critical incidents, as well as during normal operations [Vicente 2004]. These types of

systems will be referred to as critical incident information management systems (CIIMS).

The primary differential characterization of a CIIMS will be its ability to adapt to the

complexity of critical incidents. Also, it is important to recognize that the term “critical”

is relative and may have specific meaning in different realms. A critical incident in

corporate finance is distinctly different from a critical incident on the battlefield.

Xia & Lee [2004] state that there is a lack of a well-defined framework which

describes the key dimensions of information system design. This sentiment is an echo of

Fitzgerald [1998] and Alter [1999], who each approached the topic by asking first, if such

a comprehensive framework is even possible. While any single framework is unlikely to

7

have utility to all information systems designs, the absence of any subset of front-running

models is troubling. This is especially poignant in the domains of critical importance to

society in general, such as the components of the national information infrastructure. A

set of frameworks which can help define such systems should be developed. It is hoped

that this work is able to help fill that void, at least for the purpose of designing some

specialized subset of information systems.

There have been various approaches to remediate and improve design

effectiveness for complex systems. Human factors analysis, and fault tree analysis are

some common examples. However, these, and most other common analysis techniques,

have very focused concerns within the systems that they are used to describe. Focusing

design efforts on particular pieces of complex systems does not always yield a better

overall design [Vicente 1999, 2002]. Complex, real-world activities require support

systems which take into account the relative priorities of various possible actions, as well

as the opportunities and constraints of the operating environment. Focusing on one part of

a system can easily lead to the neglect of other parts.

Foremost among the options in terms of addressing complex, real-world

situations, is the Abstraction Hierarchy model. The Abstraction Hierarchy (AH) model

conceived by Rasmussen [1986] has been used to aid in the design of complex systems

for many domains [Vicente 1999, 2002]. Their primary application has been for process

control and ecological interface design (EID), an engineering approach which attempts to

produce human-computer interfaces capable of supporting users during novel or

8

extraordinary circumstances [Vicente & Rasmussen 1992][Vicente 1999, 2002]. The

significant feature of the Abstraction Hierarchy model is its ability to simultaneously

represent the opportunities and constraints relevant to a system at several layers of

resolution, allowing focused attention within a more general context. Such representation

concurrency can be exploited in the system design process.

In information system design, many advocate the involvement of those who will

eventually become the users of a system, but often the meaning of “involvement” remains

ambiguous [Singh & Kotze 2003][Rivera, et.al. 2003][Roth, et.al. 2002]. The methods

brought forth by Rasmussen, Vicente, and other proponents of AH modeling require a

work domain analysis (WDA) process. Work domain analysis is used to provide the

system engineer with a better understanding not only of the activities of the (potential)

users of a system, but also of their motivations, overall goals, and general approaches.

WDA encompasses more than any analysis of basic tasks within a system, and can

incorporate the perspectives of several different groups of users or other stakeholders.

As complex information systems continue to grow both in number and

importance, the value of proper design and implementation increases in importance.

Guidelines for system designers tasked with the creation or modification of complex

information systems, which may or may not be part of a critical public infrastructure, are

lacking. This work proposes employing an AH-based model to aid in the design of

information systems in general. The levels of abstraction will be evaluated across the

three peer elements of information, technology, and people, which comprise information

9

systems. An integrated demonstration of this model will utilize the specific real-world

domain of emergency services dispatch operations. The advantages of including this

model in the design phase are expected to include the ability of the information system to

more easily scale to support atypical operations encountered in extraordinary conditions.

Extraordinary conditions in the emergency services dispatch domain can imply

significant loss of lives, wellbeing, or property.

10

Review of Literature:

The Abstraction Hierarchy Model

The abstraction-decomposition space (commonly called the abstraction hierarchy)

model put forth by Rasmussen [1986] is used to develop models of complex socio-

technical systems [Miller & Vicente 1998]. Though applicable to many domains, it has

been used historically to aid in process control and nuclear power systems design

[Bisantz & Vicente 1994]. In recent years, it has been used for information system design

in hospitals, libraries, and command-and-control domains. [Hajdukiewicz, et.al. 1999]

The motive for employing an abstraction hierarchy model is that a complex

system can be viewed, modeled, and interpreted on the basis of a matrix of level of

abstraction (from abstract to concrete structure), and decomposition (whole-to-part

structure). This form of representing and modeling systems is predicated on making

visible the functional-structural elements of the environment that shape or constrain

activity within a work domain. This visibility allows system engineers to more readily

identify the potential opportunities and constraints of a system by matching the more

abstract goals against the more concrete available resources.

The model of a system contained in a well-constructed abstraction hierarchy is

able to convey the form of, the interactions within, and motives for the system at multiple

scales. If you have ever played the game where a child asks over and over “why” or

“how” something works as you respond with more and more detailed answers, you are

familiar with some of the functionality an abstraction hierarchy provides.

11

Because AH models address motives as well as means for the various components

of a system, there is an easily demonstrable path of relationships from the most elemental

pieces to the overall purpose. With such relationships understood, individual components

and higher-order aggregations of components can be assessed against the purposes of the

overall system, as well as against their own localized specification. Understanding a

complex system and its constituent pieces at these varying levels of abstraction allows

system designers to produce designs which not only meet the specifications for the

foreseen normal activities, but also allows the system to continue to operate efficiently

when situations become abnormally complex. In either case, the overall guiding purpose

of the system does not change.

Rasmussen [1986] specified five levels of abstraction in his hierarchy, from

bottom to top: physical form, physical functions, generalized functions, abstract

functions, and functional purpose. The relationship between neighboring layers is often

termed “means-end” as higher levels must successively rely on the lower levels to

provide the foundation (means) required to achieve their own goals. The levels progress

from the most concrete at the bottom, to the most abstract at the top.

There is also a “whole-part” decomposition, usually represented across the

horizontal axis. The usual progression of labels is: total system, subsystems, functional

units, subassemblies, and components. As with the mean-ends hierarchy, the number of

decomposition layers may vary from domain to domain.

12

Whole-Part Structural Decomposition

Total System Sub-System Functional Unit Subassembly Component

Functional Purpose

Abstract Function

Generalized Function

Physical Function

Mea

ns-E

nds

Abs

trac

tion

Hie

rarc

hy

Physical Form

Concept over implementation

Representation of physical processes of the system

Causal network, the flow through the system

Most “concrete” form

Most abstract form; overall reason for the system

Figure 1 - Abstraction Hierarchy Model; adapted from Rasmussen, et. al. [1994]

The five levels Rasmussen named were used in describing process control work

environments, typically exemplified by some kind of manufacturing plant. The physical

form layer described the location and appearance of the equipment used by the process.

The next layer up, physical function, contained a generic description of the specific

equipment given in the bottom layer. The generalized function layer showed the general

function of the more detailed physical function layer. At this level, the concept of a set of

functions begins to take precedence over their implementation. The abstract function

layer provided an overall topological view of the general functions, describing how some

of the general functions are related to each other. The top-most level, functional purpose,

described the governing motive for the system.

An important piece of understanding abstraction hierarchy models is that each

level of abstraction represents a different model of the same system [Bisantz & Vicente

1994]. Though the lower levels of the hierarchy may be more easily visualized due to

their correspondence to tangible objects, the higher levels may be visualized as the set of

broad specifications for the system. Using the example of a system tasked with providing

13

warmth (its functional purpose), it is easy to imagine the physical forms of several

different systems able to fulfill the overall purpose. In every case, the intermediate layers

of the hierarchy would represent a link describing the lower level in a more abstract form,

contributing to the next highest layer, until the most abstract description (warmth) is

reached. Each level describes the same system with a different level of abstraction.

Vicente’s [1996] description of abstraction hierarchies makes a point of

specifying that the contents of the AH’s cells should be nouns, not verbs; that is to say,

objects rather than actions. The term structural means is used to describe the

relationships between subsequent levels of the hierarchy. Structural means is contrasted

with action means through the example of the means used to achieve warmth: a furnace

provides the structural means to produce warmth, while fueling and lighting a furnace are

the actions needed to produce warmth. The difference is important as an abstraction

hierarchy is supposed to contain a model of a work domain, which is used as a platform

to understand activity. Task analysis is a common approach to gaining some

understanding of a work environment. When performing a task analysis, a set of related

activities is observed, studied, and documented with the goal of understanding individual

actions and their interactions between each other and the work domain. The result is a

detailed description of what takes place in a work domain, but does not address the

question of why the action takes place. A task analysis might produce an action hierarchy,

relating one discrete activity to some others, but the action must take place within a

particular work domain. A work domain analysis (WDA) attempts to take a broader view

of the activities within a work environment to try to understand the motivation behind the

14

actions at many levels. WDA tries to understand how one activity relates to another, but

also how a chain of activities relate to the overall goal of the work. Therefore, a work

domain analysis lays the groundwork for subsequent task analysis, by adding a sense of

context in which the tasks take place.

Vicente [1996] made a point of explaining that the five levels of abstraction

defined by Rasmussen are not rigidly defined for all domains. In practice, it is often

necessary to alter the strata labels and vary the number of levels to accommodate an

accurate representation of different work domains. That said, the five-level structure

originally defined for process control systems has successfully been applied to several

other areas. Examples include nuclear power plant control, medical information systems,

and ambulance dispatch.

An additional attribute of abstraction hierarchies made clear by Vicente [1996] is

the existence of “why-what-how” relationships between neighboring levels. Any single

level of the hierarchy represents what describes the system at that particular level of

abstraction. The level above should represent the motive; answering why the observed

level of interest has the given form. The level below should explain how the level of

interest has achieved its form. These relationships are used in ecologic interface design

(EID) to achieve a goal-oriented human-computer interface.

Rasmussen, et. al. [1994] refers to work domain analysis (WDA) as an approach

to informing a useable model upon which to base system development. WDA is

described by saying that “… the aim is not to represent the actual coupling and

15

functioning of the work system in particular situations, but instead to produce a

generalized representation of the ‘work domain’ in terms of its inventory of objectives,

functions, resources and their general properties and, in particular, their capabilities for

action as well as their limiting characteristics, which can constrain these actions.”

[Rasmussen, et.al. 1994, pg. 35]

In their discussion of WDA methods, Rasmussen, et. al. advise that “… a good

introduction to the domain should be obtained from textbooks, activity reports from the

particular work system including material, such as commercial brochures and reports to

the shareholders. Sometimes a careful perusal of newspapers can give useful insights into

policies, management intentions, political disagreements, and relevant changes in

society’s attitudes and opinions. At a more detailed level, formal procedures, and

instructions will be useful for learning about the various means-ends relationships in the

system. However, the typical detailed procedural body concerning ‘what and how to’ is

unreliable as a data source for activity analysis.” [Rasmussen, et.al. 1994, pg. 55]

Following such a review of relevant literature, their recommendations turn to

more intimate methods of acquiring data, mainly personal interviews. One of the

purposes of gaining a basic understanding of the work and its environment through

reading is to prepare the interviewer. Without appropriate background knowledge, the

interviews could not adequately weave through the details underlying the work. The

ability to conduct interviews which are not tied to any script is required to elicit the

needed data. In Rasmussen’s words: “Unstructured interviews at all levels of an

16

organization are very fruitful even though a body of structured information is the ultimate

aim. Unstructured interviews using detailed notes or tape recorders have turned out to be

the only realistic approach.” [Rasmussen, et.al. 1994, pg. 55]

Long before Rasmussen defined his Abstraction Hierarchy model, Flanagan, in

his [1954] seminal work on the analysis of critical incidents within particular work

domains, recognized the difficulty in understanding the complexity of work environment.

Among his advice for conducting what would later come to be known as work domain

analysis, he writes: “… it is clear that the critical incident technique is essentially a

procedure for gathering certain important facts concerning behavior in defined situations.

It should be emphasized that the critical incident technique does not consist of a single

rigid set of rules governing such data collection. Rather it should be thought of as a

flexible set of principles which must be modified and adapted to meet the specific

situation at hand.” [Flanagan 1954, pg. 335] While providing those flexible principles for

studying critical incident domains, he states: “Wherever possible, the observers should be

selected on the basis of their familiarity with the activity.” [Flanagan 1954, pg. 339]

Flanagan, though using some terms that might imply task analysis, rather than a

work domain analysis, was clearly referring to the later. This is made clear in a paragraph

containing some of the essence of the future AH model: “A basic condition necessary for

any work on the formulation of a functional description of an activity is a fundamental

orientation in terms of the general aims of the activity. No planning and no evaluation of

specific behaviors are possible without a general statement of objectives. The trend in the

17

scientific field toward operational statements has led a number of writers to try to

describe activities or functions in terms of the acts or operations performed, the material

acted on, the situations involved, the results or products, and the relative importance of

various acts and results. These analyses have been helpful in emphasizing the need for

more specific and detailed descriptions of the requirements of activities. Typically,

however, such discussions have failed to emphasize the dominant role of the general aim

in formulating a description of successful behavior or adjustment in a particular

situation.” [Flanagan 1954, pg. 336]

Though the WDA process and development of an abstraction hierarchy for a

specific project or work domain may be tedious and time consuming, the payoff is a

much improved understanding of the target system requirements and constraints, which

can hopefully lead to better system designs. The most significant part of this

understanding is of the overall general goals of the domain. A distinction which must be

made is the difference between the goals of the domain and the goals of individual tasks

which take place within the domain. Though any system designed through the use of an

abstraction hierarchy model should obviously support the performance of day-to-day

individual tasks, the real benefit of such designs is their ability to adapt to unusual or

unforeseen circumstances. This ability is based on the understanding of the system’s

overall objectives, which should not change with the circumstances.

18

Ecological Interface Design

The design of complex information systems is generally approached from one of

three perspectives. Flach, et. al [1998] listed these approaches as technology-centered,

user-centered, and control-centered. While technology-centered and user-centered

approaches place emphasis on the capabilities and limitations of machines and humans

respectively, the control-centered approach combines these perspectives to emphasize the

interoperability of humans and machines. In all of these cases, however, the complete

system is envisioned as some combination of the two elements: technology and users

(being only those people who directly interact with the technology.)

Another way to categorize systems is in regard to their focus on the enforcement

of some structured set of rules, versus their ability to support operations outside of

previously-defined situations. The former category is commonly referred to as intentional

systems; the latter as natural or ecological systems. Hajdukiewicz, et.al. [1999] presented

a model placing the two types of systems as the extremes of a continuum, linking a

system’s intentional constraints with its causal (ecological) constraints. All work

domains, and their associated information systems, would exist somewhere along the

continuum. Their exact placement would depend upon several factors, including the

purpose and scope of any analysis of the work.

Ecological Interface Design (EID) [Rasmussen & Vicente 1989] uses abstraction

hierarchies as part of a framework focused on the problems associated with designing

human-computer interfaces for complex socio-technical systems. The purpose of

19

ecological interfaces is to support human decision-making, particularly in atypical and

unanticipated circumstances. Abstraction hierarchies provide a fundamental model

describing a system’s high-level goals related to the lower-level implementations.

Interfaces built with consideration to the progression of abstraction to the overall goals of

the system are able to provide their users with information and controls relevant to that

overall goal, rather than all of the details of physical implementation.

Vicente [2004] cites poor interface design as a contributing factor in such

incidents as the Chernobyl nuclear power plant accident. Even though the control room of

the plant had gauges and displays which provided all of the detailed information needed

to recognize the impending problem, those displays were not arranged and aggregated to

make the information clear to the human operators who might have been able to avoid the

accident. Some of the more noteworthy aspects of the human-system interface are gauges

placed well out of easy view (some were twelve feet above ground level) and similar-

looking yet unrelated controls placed next to each other.

Ecological approaches to interface design have been taken to improve operations

in the nuclear power industry, as well as, neonatal intensive medical care [Sharp &

Helmici 1998], hyper-textual information retrieval, and others [Vicente 2002]. EID

makes use of the AH model’s means-ends relationships between levels to inform the

design of the interface. Each element of an interface design must fit into the why-what-

how structure of the hierarchy and support the more abstract functionality of the “why”

layer above, while also supporting the more concrete “how” layer below.

20

Ecological interfaces are constructed to focus on the use of a system, or the

overall purpose of the work the system is to support. An important piece of the EID

construction process is gathering information of “the work domain (work space or

problem space) as an integral component of the ‘cognitive system.’” [Flach, et.al. 1998,

pg 297] The relative importance of a proper understanding of the work domain is

addressed in the same work: “… The limitations of technologies, humans, and control

systems are important considerations --- but the significance of these limitations can only

be appreciated relative to the functional demands of a work domain.”

Ecological interface designs have consistently been shown to improve the

performance of systems, but this improvement is most apparent in non-routine

operations, where humans are called upon as “knowledge workers” able to adaptively

process the information coming through the interfaces [Vicente 2002]. In Vicente’s

[2002] example of a pasteurization process control system experiment, it was noted that

while performance during unusual circumstances improved, performance during normal

operations was unaffected by the use of EID. This is mentioned to show that the use of

EID is not meant to trade normal condition capabilities for improved capabilities in

atypical conditions. Little effect on normal operations is expected through the use of EID,

while atypical operations are expected to become easier to understand and handle.

Information, Technology, and People

A premise of this work is that information systems are comprised of three

elemental components: information, technology, and people [Sawyer & Chen, 2002], and

21

that these elements are symbiotic peers. The decomposition of information systems into

these three elements has been recognized for many years as a tool for designing and

implementing successful systems. Often, only two of the three are seen as central to the

system, with the third element is given little, if any, consideration. The interactions and

relationships in any pairing of these three elements have a history of research under the

umbrella of a well-defined domain. Information-Technology interactions are at the core

of computer science. Information-People relationships fall into the library sciences.

People-Technology relationships are the realm of the human-computer interface (HCI)

design and ergonomics fields. Of course, each of these pairs must consider the third

element to some extent, but none explicitly consider the combination of all three in their

designs.

Computer scientists often define efficiency in terms related to processing speed,

memory usage, or some other technologic or hardware related metrics. What is implied in

these measures, however, is the effect they have upon the users of a system. Why is the

speed of a given algorithm’s performance a measure of efficiency? What difference will

it make to the computer if a calculation takes one second or one hour? To the technology,

these two blocks of time are exactly the same thing: the time needed to complete a

particular calculation. To people, however, a time savings of fifty-nine minutes and fifty-

nine seconds is very significant and is quantifiable in many ways, most commonly in

monetary terms.

22

The library sciences recognize the value of information to people. The time-value

of information access is also recognized in this domain, and addressed by the introduction

of methods to shorten the time needed to locate particular pieces of information. A library

which contained a copy of every written work from the entirety of human existence

would be utterly useless without some way to eliminate the material that is irrelevant to

the present needs of a person seeking particular information. The organization and

cataloging of the library’s contents is a form of technology. This may seem obvious

today, when many libraries have computer access stations for people to perform searches.

Consider, also, the card-catalogs which utilize the Dewey-Decimal system for indexing

the contents of libraries; only a decade ago, many libraries offered this form of

technology as the sole means of limiting the search for materials.

The field of HCI is primarily focused on the ways that people interact with

information and communications technology. The objective of most human-technology

interaction, though, is the communication of some information. Even when computers

may not be directly involved, the interactions of people with technology are often meant

to convey some information. Consider the action of turning the steering wheel of an

automobile; the driver is communicating his/her desire to have the car’s direction of

motion changed. The linkages and power systems required to affect the change are

hidden, and in many cases unknown, to the human user.

The Information-Technology-People trichotomy is often recognized in literature

relating to systems design from any of the common perspectives. There is, however, no

23

apparent widely-used standard nomenclature for the three elements. For example, Vicente

[2004] states that he is interested in studying the ways that people interact with

technology. He then goes on to describe technology as either “hard” or “soft.” His

examples of soft technologies include hospital schedules, and team coordination. These

so-called soft technologies could be interpreted as forms of information. There is

therefore only a minor semantic transformation, to arrive back at the information-

technology-people framework.

As another example, Xia & Lee [2004] cite “organizational factors” beyond the

control of the system designers as a significant factor in information systems design.

Extrapolating “people” as the elemental components of an organization allows us to

describe Xia & Lee’s concerns in the terms used in the I-T-P framework. While

organizational factors may be beyond the influence of information system designers, this

does not mean that they should be excluded from consideration in the design. To the

contrary, it is because these factors are beyond the designers’ control that they must be

investigated and understood. An understanding of the organizational factors, as a subset

of the mental model used by information system users, will better facilitate the designers’

efforts to connect the users and information through some arrangement of technology. To

ignore the users, and the organizational environments in which they operate, would be

analogous to building a bridgehead without understanding the ground upon which it rests.

24

Theoretical Framework: the "I-T-P Abstraction Hierarchy"

Introduction

An abstraction hierarchy (AH) was developed which targets the composition of a

comprehensive information system. In contrast to the typical abstraction hierarchy’s

whole-part decomposition of systems into sub-systems, units, assemblies, and

components, I have implemented a decomposition of the system into the three peer

elements of information, technology, and people.

The choice of these three elements addresses some of the points of criticism

concerning abstraction hierarchies voiced by Lind [1999]. One criticism, that “... it is not

clear how to express the fact that the information processed by the control system are the

representations of the physical phenomena in the production system… ” is addressed

explicitly by the inclusion of an information element. The people element is meant

primarily to refer to the users of the system, though any set of stakeholders could be

considered. Technology is the usual target of information system design efforts. It refers

to the arrangement of hardware, software, and supporting structures within the system.

The use of three elements implies that one of them will be used as a connection between

the other two. Most commonly, technology will be arranged to bridge human users and

information. This bridge can function bi-directionally, or may be limited to only one

mode of operation.

25

The five levels of abstraction named by Rasmussen [1986] have been retained,

however, the inclusion of “information” as an element of a system compelled me to re-

title the base ranks of the AH from “physical” to “real-world.” The use of these five

labels is by no means a requirement of the model. However, Rasmussen’s five level

model was developed to represent production processes. As information systems can be

thought of as production processes which have data as the raw resource, and information

at the finished product of some transformation process, the five levels defined by

Rasmussen are appropriate. 3

The higher levels show the more broad-based view of the system, and so are

shared among the elements of the decomposition. As the level of abstraction decreases,

toward the lower levels of the hierarchy, the separation of the elements becomes more

pronounced.

3 An interesting feature of the idea of information systems as process control systems, is that the finished product, information/data, may be re-introduced as raw material. Often, the finished product will be a directive to perform some real-world activity, such as the assignment of some particular resource to some particular problem. This will be quickly followed with an inquiry as to the status of the resource and the problem inventories. Having updated resource data allows the process to repeat.

26

Structural Decomposition

Information Technology People

Purpose / Goal Overall outcome improvement

Abstract Function

Description of environment and conveyance of decision makers’ wishes Understanding and manipulation of environment

Generalized Function

Refined or transformed data which accurately describe

relevant conditions and users’ wishes in a timely fashion

Organization, transformation, refinement, storage,

movement, presentation, etc. of data

Understanding of variables describing actual and desired

conditions

Real-World Function

Representation of exhaustive set of available

details

Presentation of data to users, and interpretation of users’ directions

Analysis of conditions and direction of activity

Leve

l of A

bstr

actio

n

Real-World Form Raw Data

Data communications / storage / processing capabilities, interface hardware / software,

database structure, decision support algorithms, etc.

Users

Figure 2 - General Purpose I-T-P Abstraction Hierarchy

The whole-part decomposition of the traditional AH can still be employed to

further break down the system requirements into more contained and manageable pieces.

As you will see in the demonstration example below, the technology to be developed as

part of an information system is often divided into several layers, including data

organization, information processing, and user interface. Additionally, systems may have

several different types of users, of which each type may require a distinct interface,

functionality, and data subset. The decomposition of each of the I-T-P peer elements is an

expected necessity as the system is defined. It is key, though, to hold the three elements

as peers, each dependent upon the other two.

By modeling the constraints and requirements of a proposed information system

in the I-T-P Abstraction Hierarchy, not only is the separation of the elements made clear,

27

but also the tactical relationships between them are shown. By placing the technology

element in the central column, it is shown that the effort is to define an arrangement of

technology for the purpose of connecting people and information. More specifically, the

bottom rank, “real-world form”, of the central column is the target of our efforts; what we

are trying to construct. Alternately, one might put the “people” column in the center to

explore the parameters of training (the equivalent of “constructing”) a person, group, or

organization to act as intermediaries between information and technology. Similarly, the

information column may be centered and treated as a target product linking people and

technology. Examples of these variations may be found in Appendix A.

Diagonal relationships can be found which describe the purpose of the design

effort. In the example general-purpose I-T-P Abstraction Hierarchy, moving from the

bottom right: users will rely on the presentation of data to provide an accurate description

of conditions in a timely manor. You can also move diagonally from the bottom left: raw

data will be presented in such away to support understanding of conditions. The diagonal

relationships can help to specify the scope of the project. In later stages, development can

be checked against the model to see that each element is fulfilling its hierarchical

requirements, and that the inter-relationships exemplified by the diagonals are

solidifying.

The model could also be used to find deficiencies in current systems. As you will

see in the example presented below, the diagonal link from the users to the refined timely

28

information was broken, justifying a redesign of the technology to repair that path while

maintaining the previously specified needs.

Supporting Literature

Xia & Lee [2004] propose a taxonomy of information system development

project complexity comprised of two dimensions: organizational vs. technological, and

structural vs. dynamic. This structure has some similarity to the I-T-P Abstraction

Hierarchy proposed in this work. The organizational - technological dimension of their

model is represented by the people and technology columns of the I-T-P AH. The

addition of the information column makes explicit the role of information implied in their

work, as they attempt to describe information system development. Additionally, their

structural – dynamic dimension represents the ends of the intentional – ecological

systems continuum [Hajdukiewicz, et. al. 1999][Rasmussen, et. al. 1994]. This dimension

is seen here as the scale where a proposed information system must be allowed to move

freely. That is to say that a requirement of the method proposed in this work is that

information systems be designed to support work in both structured/intentional and

dynamic/ecological modes. Under normal circumstances, the structured mode of

operations should lighten the workload of the human operators by attending to well

understood situations. As circumstances change to be more extraordinary, the system

must provide the resources needed by a human user for good decision making.

As a significant factor of information system design complexity, Xia & Lee

[2004] cite uncertainty in the system’s goals and the means required to achieve those

29

goals. The proposed I-T-P Abstraction Hierarchy model addresses this explicitly, as the

neighboring abstraction strata have means-ends relationships at all levels.

Using the I-T-P Abstraction Hierarchy Model

WDA to populate cells of the Hierarchy

The I-T-P Abstraction Hierarchy can be used as a tool to direct the development

of an information system. In the early stages, the cells must be enhanced with more

detailed information concerning the target domain. The details can be established through

a work domain analysis (WDA) of the target domain. As previously described, a work

domain analysis may be conducted by several means, the choices of which depend upon

several factors.

Lind’s [1999] criticisms of abstraction hierarchies include “… no procedure or

guideline exist (to the authors knowledge) that can help in the acquisition of the

background knowledge required for a modeling task.” Rasmussen, et. al. [1994] admitted

that they did not envision any single approach to knowledge elicitation for completing the

AH model for any given domain. A variety of approaches must be assembled specifically

for the area of interest. The selection of approaches may be dependent upon a number of

factors, most obviously the researchers’ previous knowledge of the domain. Research in

many domains can benefit through an insider’s perspective. Xiao [1996] cited the

usefulness on an insider’s background knowledge in researching activities in hospital

emergency departments. The ongoing activities in the environment under study simply

30

can not be interrupted for research clarification, and after-the-fact review techniques,

such as the use of video recordings, may be disallowed by policy.

While it is true that an insider’s perspective can have a significant effect on the

design of a successful information system, it may not be an absolute requirement. Even

the most experienced insider who is attempting research should be self-compelled to

survey the existing literature concerning the work domain of interest. In addition to

Flanagan’s [1954] guidelines for work domain knowledge elicitation, a search for

academic literature relating to similar research may yield much already refined

information and help direct lines of questioning during interviews, surveys, etc. Mirroring

the methodological approaches of some of the related works can lend credibility to the

compilation of data necessary to build a new I-T-P AH model.

As discussed earlier, the general I-T-P Abstraction Hierarchy model uses

Rasmussen’s five layers of abstraction, which fit well with the concept of information

systems as process control systems. That said, there is no requirement that a model

refined for a particular domain use the same five layers. Fewer or additional layers may

be implemented at the discretion of the system designer.

Decomposition of the target product

The whole-part hierarchical decomposition present in Rasmussen’s [1986] model,

is an implicit requirement of the I-T-P AH. The whole-part decomposition can be

visualized as another dimension, adding depth to the presented representation. Rather

than providing a set of general labels for this decomposition (system, sub-system, etc.),

31

that task can be set aside for the specialists who will be constructing the more discrete

pieces. This is done so as to not impose system-level generalizations upon component-

level implementations. As a brief example, consider that most information systems will

have a foundational data layer, a database. A system-level specification would say what

types of information must be stored in the database, different ways that that information

might be aggregated or sorted, and perhaps what types of users will have access to

different presentations of the data. It is left to someone better versed in database

architectures to define the tables, fields, views, etc. necessary to properly implement the

system designers’ specifications. Similarly, it is up to computer programmers to define

the modules, procedures, functions, variables, etc. necessary to achieve the functionality

required at the system-level.

Emergent system specification

Rasmussen’s abstraction hierarchies had a structural decomposition of the

proposed system running along the horizontal axis. We have substituted our own three

peer elements as a technique for better understanding the requirements of a design. Since

we have established that an arrangement of technology is to be the target of our design

efforts, and we have described the technologies’ relationships with information and

people, we can now focus some attention to designing the technology. A first step in

doing this would be to use Rasmussen’s “whole-part” decomposition to break our work

into smaller, more manageable pieces. This would naturally lead to the definition of sub-

systems, units, assemblies, and so forth. Some other nomenclature may be substituted

based on the particular technology being decomposed, but the sub-division of

32

functionality will remain constant. Examples of this are incorporated below, into the

decomposition of the example information system design.

At this stage, the middle layers of the model become significant, because they

describe the interaction of information and people with the technology to be developed.

The cells at these layers will define the external structures which will be the subjects and

objects of the information system’s work. From the general I-T-P AH model, the

exhaustive set of relevant details within the target domain must be defined. This includes

defining the relationships between different categories of those detailed data. Likewise,

the definitions of the system users’ potential wishes and information needs must be

established. The AH’model’s why-what-how relationships between layers are the key to

establishing these definitions accurately. From the top down, each layer defines a need,

with the next layer defining the more fundamental pieces required to address that need.

More and more specific definitions should populate the cells at lower levels, until the

lowest layer contains descriptions of the most basic forms which can then be

implemented.

Entering an iterative design cycle

The process of developing a usably populated I-T-P Abstraction Hierarchy which

accurately models the problem domain could benefit from the adoption of a formalized

method for refining our understanding of the problem domain. Ideally, we should be able

to employ this method through the complete system development life cycle of the

development process, not merely to the design phase. For this purpose, the Living Lab

33

Framework from McNeese [1996, 2000] could be effectively integrated even at an early

stage of development. The Living Lab approach specifies an iterative narrowing of

parameters by cycling through a series of design, implement, test, re-scale steps. At this

stage of system design, the “implement” phase of the cycle would produce an abstraction

hierarchy model prototype for evaluation. Such testing would have to involve presenting

the model and its implications to domain experts for their comments.

Following the initial specification and possibly the construction of a preliminary

information system prototype, development of the system must enter an iterative design

cycle. The purpose of the design cycle is to refine the design and its implementation into

a progressively more useable artifact. As the most easily dynamic, and arguably the most

significant, component of an information system artifact, the system’s software will

likely be the component to be manipulated the most.4 Boy [1998] described his AUTO

(Artifact, User, Task, Organization) pyramid concept as an approach to developing

safety-critical software. The approach is similar to McNeese’s [1996, 2000] Living-Lab

framework for iteratively informed development, but specifically addresses computer

software development and forces the consideration of multiple levels of software use.

Though the AUTO pyramid model uses individual work tasks as one of its fundamental

4 In this case, “software” refers to the entire non-tangible collection of elements of a computer-based information system. To clarify, software includes any application data and database sub-system used to house it, the algorithms used to implement business rules, and the human interface presentation of data and methods of collecting input.

34

elements, it situates those task definitions in the contexts of the working environment, the

user(s) of the system, and the software artifact itself. This combination of simultaneous

considerations is similar to the I-T-P AH model’s goals. For these reasons, it may serve

as an appropriate tool to aid in the construction of a software artifact based on the I-T-P

AH model’s specifications.

35

Application: Emergency Services Dispatching

The work domain of emergency services dispatch was adopted as an area for

investigating the use of the I-T-P Abstraction Hierarchy as a tool for information system

development. The choice of this area was based on several factors, including this author’s

tangential familiarity, as an 18-year veteran emergency medical services (EMS) provider.

The involvement is described as tangential, because as an EMS provider, interactions

with emergency services dispatchers were a regular part of the work. However, this

experience does not include activities directly related to the work performed by those

dispatchers. The relationship is similar to that between a waiter and a chef in a busy

restaurant. Though each may have some knowledge of the general nature of the other’s

job, and may even have some overlapping responsibilities, the details of the work

establish definite boundaries of responsibility. The waiter can understand the overall

purpose of the chef, and the similarities of their individual work domains supports

communication, but this does not mean that the waiter could substitute for the chef.

The author’s experiences as an EMS provider include working in many diverse

environments, including a large urban center and its surrounding communities, as well as

some of the most rural areas of Pennsylvania. Through his career, responses to

emergency medical incidents have included mass casualty incidents, and other types of

responses considered atypically complex by the industry. Observations made in such

circumstances, and in the more mundane day-to-day operational environments have

undoubtedly influenced this particular research. However, it is the author’s contention

36

that this prior experience has allowed better accuracy and relevance in gathering data

more than it has introduced any significant bias.

This domain is considered to be a component of the national critical

infrastructure, and yet is an under-researched area, particularly in its ability to handle

extraordinary circumstances [Rhodenizer, et. al. 2000]. In the wake of terrorist attacks

within the borders of the United States and elsewhere, several efforts are underway to

assure the capability of the emergency response system to deal with future incidents of

similar natures [Moodie, et.al. 2000].

In the emergency services dispatching domain, a critical incident can be

considered as any set of circumstances that increases the likelihood of loss of life,

wellbeing, or property, to unusually high levels. It may be thought of as a set of

conditions where some loss must be accepted as unavoidable and resources must be

managed with such expectations in play. A typical example of this would be a mass-

casualty incident (MCI), which involves multiple people who require medical treatment

for injuries of varying severity. Often, the mechanism of injury includes circumstances

which require other emergency services to become involved simultaneously. Incidents

such as mult-vehicle accidents may result in such conditions. The process of allocating

resources to provide care becomes a much more challenging problem. Even if

comprehensive, accurate, and timely information was available from the scene of the

incident, the allocation of police/fire/medical/rescue personnel and equipment must be

37

made with the consideration of other potential incidents within the territory controlled by

the dispatch center. Some resources must be held back “just in case.”

Previous work in the emergency medical services (EMS) response to

extraordinary incidents [Feliciano 1998] [Beyersdorf 1996] have cited the need for

accurate and timely information as a mitigating factor in the effective care for victims of

mass casualty situations. Though in these case studies the focus was on the proper triage

and transportation decisions affecting actions between the scene and the destination

hospital, many of the same principles apply to the allocation of EMS resources to the

incident itself.

The improved timeliness and accuracy of information related to emergency

incidents has been shown to positively impact the outcome. Athey & Stern [2000]

conducted a study of Pennsylvania’s adoption of Enhanced-911, which provides some

information automatically to the emergency telecommunications personnel receiving the

call. It was concluded that the additional automated information acquisition was able to

boost the survival rates of pre-hospital cardiac patients by about one percent.

As a negative example of the application of technology, in October of 1992, the

London Ambulance Service deployed a highly automated dispatch information system.

Even when much of the automation was disabled, allowing more human decision-making

in the dispatch process, the remaining portions of the new system continued to hinder

operations. After eight days the system failed completely and was switched off.

According to Finklestein & Dowell [1996], the list of factors contributing to the system’s

38

failure includes “… the software was incomplete and effectively untested; the

implementation approach was ‘high risk’ ; inappropriate and unjustified assumptions

were made during the specification process; there was a lack of consultation with users

and clients in the development process with knock-on consequences for their ‘ownership’

of the resulting system; the poor fit of the system with the organizational structure of the

ambulance service. ” The major lesson learned from this experience is that the testing and

implementation of a new system has a much more profound effect on the systems’ final

acceptance, than does the list of new and improved features.

Mayer-Schönberger [2002] described a series of failures of emergency

communications centers to fulfill their missions during extraordinary emergency response

incidents, concentrating primarily on interoperability and communications. Citing the

examples of such high-profile incidents as the 1993 attack on the World Trade Center,

the Branch Davidian standoff, the 1995 Oklahoma City bombing, and the September 11th

attacks, a picture emerges where communications failures between emergency response

agencies can contribute to the complexity of already volatile situation. Though focusing

on the use of voice radio communications as a means to interoperability, the need for

coordination among a large number and variety of field resources is made clear.

39

Hajdukiewicz, et.al. [1999] presented an Abstraction Hierarchy model for

emergency ambulance dispatch management as a piece of a work domain analysis. The

examples provided represent the normal operations of an emergency dispatching center,

with no mention of usefulness of the model in extraordinary circumstances.5 The ability

of an information system to perform well as circumstances become more complex can be

of great importance. Such explicit scalability was considered a critical piece of any new

specification.

In the Critical Incident Information Management System (CIIMS) for emergency

services dispatch case, the population of the I-T-P Abstraction Hierarchy model’s cells

must be completed by gleaning information from people working in the domain. While

gathering this information, the expectation is that any new or improved information

system will be able to scale to support the mission of the domain when circumstances

become extraordinary. It follows that one of the most potent questions to pose to a

member of the domain is “what is normal and what is extraordinary?” Additionally, a

5 Hajdukiewicz, et. al.’s AH model was designed to represent the decision-making process of a single dispatcher reacting to simultaneous requests for assistance. The model contained two columns, representing the potential risks and resource capabilities within the system. This model, though related to the same domain as that presented as a demonstration in this work, is distinctly different due to the particular purposes of the respective WDA’s. While the top-level overall goals are very similar between the two models, the lower levels bare out the distinctions. Since the Hajdukiewicz, et. al. model was built to represent the decision-making process, the bottom rank of their hierarchy refers to the raw information needed for that process. In my demonstration, this information is represented in a single column in the model of a decision-supporting information system. The decision-making process is not captured in my model as the intentions did not include constructing an automated decision-making information system.

40

broad understanding of the domain must be achieved so that the system designer can

expand meaning from the model’s abbreviated cell labels. Questions such as these must

be answered:

o What is the overall governing set of goals and constraints imposed on this

domain?

o What comprises the environment of interest to the domain?

o What is the meaning of “timeliness” in the context of varying incident types and

severities?

o What are the variables? How much detail is needed? What details can reasonably

be assessed?

o How do the variables interact with each other? Which interactions are governed

by human-made policy (intentional), and which are naturally occurring and

uncontrollable (ecologic)?

o Who are the users of information systems in this domain? Who are the

stakeholders? How should information be represented to people to best address

their information needs? How would this change in a more dynamic, and/or

complex situation?

41

Work Domain Analysis Methodology

A review of literature relevant to the domain was undertaken, including studies

related to air-traffic control (ATC) and emergency medicine. ATC and emergency

medicine fields were included to supplement the scant literature directly related to

emergency services dispatch and control. These domains have some factors in common

with emergency services dispatching, which will be explained below. Furthermore, the

literature chosen encompassed both operational and research issues.6

Site visits to a set of emergency communications centers were arranged. In all,

more than thirty hours of interviews and observation time was spent at four different

centers. The centers were chosen to represent a varied set of environments. Two of the

centers were in neighboring highly populated counties. One center was responsible for an

extremely rural area. One center was a mixture, controlling a geographically large rural

area with a relatively dense central population center. The choices of the specific centers

to visit were based partially upon the author’s prior experience in the territories served by

those centers. This allowed the author to more fully understand the operations within

those centers as a basic level of local “common knowledge” existed concerning

geography, protocols, resources, etc. An additional factor in the choice of centers to visit

6 This literature review was conducted specifically to inform the development of the demonstration model and prototype. It should be considered distinct from the literature review conducted for the development of the I-T-P Abstraction Hierarchy model, though some works overlap both areas. References related to the WDA and demonstration system are listed in Appendix D.

42

was the diversity of environments served by those centers. In particular, the differences

between busy sub-urban centers and the smaller rural centers were of interest. The

author’s prior working knowledge of a special-purpose emergency medical dispatch

command post was also influential.

One of the topics of interest in the interviews was the communication center’s

interactions with neighboring centers during critical incidents. Though this topic was

discussed during the visits to each center, the site visits to the neighboring county

communications centers were especially useful. It allowed some discussion of the

interaction between centers, with data representing two parties who would likely have to

inter-operate to handle a large-scale incident in either of their territories.

During each visit, interviews were conducted with administrative staff members

as well as on-duty dispatch personnel. Additionally, the interviews with the dispatch

personnel coincided with an observation period of up to several hours. This way,

dispatchers could be observed performing their normal tasks without disruption, then

queried to better understand their actions. Interviews were semi-structured. Outlines of

the questions to be posed during the interviews were sent to each center in advance of the

actual meeting. The outlines were used as guidelines for the conversation, allowing

exploration of interesting statements made along the way. A copy of the interview

outlines in included in Appendix C.

Previous work in the assessment of cooperative information management [Zaff ,

1993], and as particularly applied to medical treatment [Xiao, 1996 & 2001] have

43

influenced the approach to assessing the activity relevant to this project. Though the

medical-related studies primarily deal with treatment in emergency departments, as

opposed to pre-hospital dispatch and response, there is overlap in many of the areas to be

considered.

The combined observation-interview sessions were indicated as other common

methodologies, such as video or even audio-only recording, were disallowed for security

reasons. Such restrictions are not without precedent, and have particularly affected

research in emergency medical treatment environments.

Along with methodological restrictions and a fast pace of activity which can not

tolerate disruption for academic clarification, the use of domain-specific jargon has been

cited as a hindrance to some emergency medicine research [Xiao, 1996]. The

environment of emergency services dispatch centers has a similar reliance on domain-

specific language. In fact, the use of proper names such as locations and

police/fire/ambulance departments, which may be specific to a particular center’s

territory, may cause confusion in an unfamiliar observer. (See “WDA - Language” below

for more detail.)

Methodological insight was also gleaned from the literature concerning

investigations of air traffic control (ATC) centers. This domain has many similarities to

emergency communications centers (ECC), but also some significant differences. While

both are concerned with the centralized monitoring and direction of a set of remote

agents, the ATC’s remote agents are relatively homogenous. The ECC may be tasked

44

with directing police, fire, ambulance, rescue, and auxiliary services simultaneously.

While the ATC aims to prevent aircraft from interacting with each other, the ECC must

maintain order while directing a variety of services into one or more emergency

incidents. To describe the differences most succinctly, ATC centers exist to avoid

dangerous situations, and will direct their agents away from problems, while ECC’s exist

to support a response to dangerous situations, and will direct their agents toward the

problems. That said, the methods used to affect their disparate goals bear some striking

similarities. (See “WDA – Use of Information Technology” below for elaboration.)

Work Domain Analysis

Work related directly to emergency medical dispatch information handling has

been very limited. Normark [2002] describes the movement of dispatch information

through a multi-stage dispatch center (where the call-taker is separate from the

dispatcher.) McCarthy [1997] specifically addresses the problem of describing the

location of an emergency scene, and contrasts the information flows in urban and rural

emergency medical dispatch centers.

Common Practices

Emergency Communications Centers (ECC’s) have the responsibility allocating

emergency services resources, including police, fire, ambulance, general and specialty

rescue, hazardous materials response, etc. All interviewed ECC personnel stated this

general idea when it was discussed. Two of the administrators acknowledged a secondary

purpose of tracking incidents and resource response to later justify requests for funding.

45

The scope of any center’s responsibility is constrained by at least two aspects: the

geographic area which they are mandated to serve, and the emergency services resources

which they direct. In the visited centers, these constraints roughly adhered to the geo-

political boundaries of the county the center serves.

The area to be served can be defined in a number of ways, but over the last decade

one practical definition has emerged: a center’s territory of responsibility is essentially

established by the telephone companies’ routing of calls to 911. Most centers recognize

an obligation to handle calls for help from anywhere, however, in the United States, the

vast majority of such calls come via a telephone call to the 911 emergency number.

Generally, 911 calls are routed within geo-political boundaries. In Pennsylvania, where

this work was studied, the basic geo-political subdivision is the county. There are 67

counties in Pennsylvania, each of which must maintain an emergency communications

center. There are instances, however, where the areas of responsibility for an ECC do not

exactly match the borders of the county in which it sits. As an example, one of the visited

centers controls a mountainous rural area. The topography of the area interferes with

radio communications to and from the established transmitter locations. The ECC also

controls some transmitters which are able to communicate into neighboring counties

where those counties’ ECC’s are unable to reach with their transmitters. The solution is

the adjustment of control territory boundaries, taking the form of 911 routing

specifications.

46

The constraint on assignable resources varies greatly from center to center. The

visited centers each control all, or nearly all of the local resources in their territory. There

were a few exceptions, where the ECC would have to contact a smaller, specialized ECC

to request particular resources. The example revealed during the site visits, occurs where

a few municipalities within a county have together formed a regional police force, with

their own communications center. 911 calls from these municipalities are routed to the

county ECC where fire and ambulance response requests are handled. Requests for police

are then routed from the county ECC to the regional police department ECC. This routing

of specific requests also occurs between peer, neighboring ECC’s as well as

organizations with a wider scope of operations, such as state or federal law enforcement

agencies.

The most fundamental task of an ECC is resource allocation. There are two

essential bodies of information required to accomplish this task: assessed needs and

resource availability. In this context, needs are assessed primarily through telephone calls

arriving via the 911 system. Additionally, radio communications with field responders

may indicate new or changing needs within an existing incident. Resource availability is

currently much more difficult to assess.

Resources within the territory of an ECC can take on a number of forms. Even

within a single type of response unit, there can be a great variety in assignable capability.

For example, within the police force for a given municipality, there usually exists some

command hierarchy. The allocation of higher-ranking officers may be reserved for more

47

serious types of incidents. Some police vehicles carry resources useful in particular

incidents, such as automated external defibrillators (AED’s) used to resuscitate victims of

sudden cardiac arrest; or K-9 dogs used to detect illegal drugs or explosives. The tracking

of such capabilities is a logistical challenge in large systems.

In many communities of the United States, and true of the areas visited during this

research, emergency medical and fire-fighting services are largely dependent upon

volunteer involvement. This can cloud the concept of resource availability/assignability.

The term “closest available ambulance” can have several different legal meanings. As a

more specific example drawn from this term, “available” may mean that a resource is not

assigned to any incident currently, which still leaves some question as to whether that

resource has adequate staffing if it were needed immediately. In the author’s experience,

most emergency communications centers use such an imprecise working definition,

though a few require services to call in to the center and report their availability

explicitly.

The standard unit of operations in the visited ECC’s is the incident. An incident is

initiated by one or more calls to the ECC representing a situation which requires the

intervention of one or more of the services controlled by the ECC. An incident is usually

limited to a specific location and primary type: illegal activity, medical problem, fire, etc.

The information systems currently used by the ECC personnel reflect the central role of

the incident. From a computer display of a single incident, it is possible to determine

which resources have been assigned to that incident, and their current level of

48

involvement (dispatched, responding, at the scene, etc.) with the incident. Some of the

systems provide a display of the activity of any one resource for some period of time.

That is to say that one can learn of the incidents with which a single resource unit has

been involved.

It is noteworthy that computer-generated displays of aggregate data related to

resources were not available in any of the visited centers’ information systems. The

question “what resources are busy right now?” could only be assessed by manually

iterating through displays of all current incidents and noting the resources assigned to

them.

Work Environment

The lighting in the emergency communications centers is generally kept low to

make computer and radio equipment displays easier to see. Small desk lamps are

frequently used to better illuminate paperwork on writing surfaces. This was true even in

the one visited center which had windows. The curtains are generally drawn closed. The

other visited centers were either building-interior or underground.

The camaraderie among ECC personnel was obvious in all of the visited centers.

This is noteworthy because of the resultant “free” exchange of information between

communicators. It was common for individuals to verbally query or volunteer details of

telephone or radio conversations. This allowed each communicator to maintain a better

real-time mental model of the activities being coordinated by the center. The fidelity of

these interactions far exceeded what could be contained in the written notes entered into

49

the computer-aided dispatch system. Some example of these interactions were statements

such as “it sounds like they’ve got a real mess there” (referring to a particularly complex

motor vehicle accident) and “I could barely understand a word they were saying”

(referring to a significant language barrier between the call-taker and the person reporting

an incident.) These bits of information help the personnel to form a more complete

mental picture of the incident.

These interactions communicated information which could not be contained in the

computer aided dispatch system. As such, they are very important for training purposes.

In one observed instance, a police dispatcher was presented with an unfamiliar and

atypical situation involving an organization thought to have the capability of intercepting

the radio messages between the center and the police enforcement agencies being sent to

handle the situation. Consultations with the other dispatchers and the supervisor resulted

in a plan of action designed to avoid the potential interception. The information systems

in place in the center had no way of handling the extra information related to this

situation.

Each center had a variety of sources for information outside their own information

systems. Most of the centers had at least one television for the staff to view news – local

news when it was available, otherwise one of the 24-hour news networks. The use of the

televisions was at the discretion of the supervisors. Access to the internet for news,

weather, and mapping data was available in all of the visited centers, though the larger

centers limited internet access to the supervisor only. An information feed from a

50

commercial weather service was also a common feature. One of the visited centers had

access to video feeds of major roadways and intersections within their territory.

Individual Tasks

The breakdown of individual tasks within each center is fairly straightforward.

Incoming requests for assistance must be acknowledged, with initial information

gathering by voice communications. The information must then be directed to one or

more dispatchers who will allocate resources by dispatching (usually by radio) the

appropriate police, fire, ambulance, etc. organization. Communications must then be

maintained with the assigned resources to assure their response and handling of the

situation in the field, as well as coordinate activities between response agencies and other

entities. A common example of this coordination occurs as an ambulance is transporting a

medical patient to a hospital. During the trip, the hospital must be advised to expect the

patient so proper preparations may be made. Usually one of the emergency medical

personnel will make radio contact with the emergency communications center and ask to

be “patched through” to the hospital. The communications center then sets up a

communications channel allowing the ambulance personnel to speak directly with the

hospital staff. Occasionally, when the ambulance crew is especially busy, the

communications center staff may be asked to simply relay a short message to the hospital

in lieu of a more lengthy direct communication which would detract from the care of the

patient.

51

It is important to realize that though the individual tasks are common to most

emergency communications centers, the allocation of these tasks among the personnel

may vary greatly. For example, one visited center generally only keeps two emergency

telecommunicators on duty at any time. Both of these individuals are responsible for all

of the individual tasks listed. One of the larger centers had a similar approach, though

each person was given a much smaller geographic area to control. Another center

explicitly divided the call-takers and the dispatchers into separate groups. In the larger

centers, the dispatcher may be further sub-divided into groups responsible separately for

police and fire/medical services. More detailed descriptions of the individual activities

follow.

Generally, the beginning of an incident is heralded by a telephone call arriving in

the emergency communications center (ECC). The person receiving the call must quickly

gather the information needed to affect an appropriate response. It is preferable that each

call-taker be responsible for a specific geographic region, so that multiple calls

concerning a single incident can be identified. Attempts at automating such

identifications have been unsuccessful, sometimes with disastrous results, as was the case

with the 1992 London Ambulance Service’s incident [Finkelstein & Dowell 1996].

Call-takers have a preferred process for gathering incident information. Generally,

the location of the incident is ascertained first, so that if communications are interrupted,

responders may be sent to assess the situation in the field. The second piece of

information requested is usually a return phone number, so that if communications are

52

interrupted, the call-taker may attempt to re-establish contact. Recent upgrades to the 911

system have allowed this information to be recorded automatically in some areas and

used to lookup more detailed information relevant to the incident [Athey & Stern 2000].

The details of the incident are then requested and entered into the ECC’s information

system, called a computer-aided dispatching (CAD) system, in centers which utilize

computer technology.

Once the nature and some details of the incident have been entered into the CAD,

a needs assessment can be begun. Such an assessment, deciding the propriety of

dispatching police, fire, medical, or other services, can follow a set of guidelines either

known to the ECC personnel, or incorporated into the CAD. Once initial needs are

established, information concerning the incident can be routed to the personnel

responsible for allocating specific resources. Routing can be accomplished automatically

by some CAD’s, or manually by the call-takers.

The dispatchers who receive the refined information regarding the incident must

then decide which of the available resources are best capable of fulfilling the needs of the

incident, and should be allocated. Generally, this decision is based on a protocol which

begins by dispatching the nearest available appropriate resources, then follows to pre-

determined back-up resources if the first is unable to respond adequately. The protocols

governing dispatch operations can be fairly complex, are established locally, are based on

a number of factors, and address a wide variety of possible scenarios. The locally-defined

complex nature of these protocols implies tremendous difficulty in establishing an

53

automated decision-making system.7 It follows that a human-centric decision support

system must be implemented to smooth the work at this step.

Once a response has been initiated, the emergency telecommunications personnel

must maintain contact with the resources dispatched to the incident. This assures that the

allocated resources actually arrive at the scene of the incident and render aid. If a

resource fails to do so for any of a number of possible reasons, such as mechanical

failure, or finding a traffic accident while on the way to the scene, the ECC must repeat

the step of dispatching the next most appropriate resource. Doing this requires a new

assessment of resource availability and this inventory may have changed since the time of

the initial dispatch.

The emergency telecommunicators may be required or requested to perform other

tasks associated with an incident. For example, requests to retrieve data from online

databases may need to be handled. This is often the case when the police are involved, in

order to check identification, etc. There are efforts underway to try to offload some of

this kind of work from the ECC’s to the field units [Sawyer, et.al. 2004]. It is expected

7 Each fire-fighting and emergency medical service establishes “mutual aid agreements” with their neighboring services. These agreements define plans of action should the primary service be unable to respond for any reason. In some cases, these agreements can be quite detailed and address issues other than the straightforward handling of incidents, such as financial compensation and/or billing rights. Beyond the basic substitution of a neighboring service for the primary, some responses require a combined effort from several agencies. For example a basic ambulance service may require the assistance of another service for their more advanced medical treatment capabilities. The distribution of activities is then an added variable to the mutual aid agreements.

54

that the introduction of new information and communications technologies will change

this piece of the ECC’s mission in the next several years.

The larger visited centers each had an explicitly named dispatch supervisor role

whose duties involved watching over and assisting the other dispatchers. This individual

is usually much more experienced than the other telecommunicators, and able to direct

activity outside the normal range of activity for lower-ranking individual dispatchers.

During one site visit, a police dispatcher queried the supervisor about the proper handling

of an incident involving an organization found on a federal law-enforcement issued watch

list. The supervisor responded by instructing the dispatcher to deviate from the normal

notification protocols to avoid radio communications that could be overheard by the

organization in question. Additionally, the supervisor, while not being caught up in the

details of each incident, can allocate time to assessing aggregate conditions in the control

territory. As one example, the supervisor might survey traffic patterns from a variety of

sources to better advise the dispatchers on instructions to give field responders enroute to

or from an incident. A summary of a large portion of the supervisor’s role is to perform

unanticipated analysis of information contained within the ECC’s system and to manage

information from other sources to the benefit of the ECC’s mission.

Language

The use of work-domain specific language, or jargon, was recognized and noted.

Though probably not as cryptic as some other domains, such as emergency medicine, the

use of special-purpose words, abbreviations, and mnemonics in fast-paced spoken

55

communication would be difficult for non-familiar observers to understand well. The

impracticality of interrupting the dispatchers’ activities to ask for clarification implies the

need for some a priori knowledge to understand lower-level meanings.

The use of informal proper names to describe locations and entities within the

scope of the dispatch center’s influence was noted. Persons unfamiliar with the references

might have difficulty understanding the activity in the center. As an example, a

dispatcher receiving a request to “send out the Mounties” was able to interpret the

message to mean dispatch the Mountain View Fire Department, which is referenced in

the computer-aided dispatching (CAD) system as fire company #12 (specifics have been

replaced). Similar translations were repeatedly observed.

One of the most interesting aspects of the conversations with dispatch personnel is

that the meanings of “good” and “bad” are relatively subjective and somewhat

ambiguous. Several times, while discussing a “good” work shift, dispatchers would stop

to explain that they understood that the busy-ness of the communications center was tied

to the detriment of life, health, and property in the communities they serve. These

conversations would often transpose the words “good” and “bad” with the implicit

understanding that the meaning was subjective and dependent upon the point of view. In

all instances, it was inferred that dispatcher considered the situations as “good” in that

they allowed them to demonstrate their ability to handle the complexity, while

understanding that they were “bad” in that they revealed weaknesses in the system that

may or may not be tied directly to human error. The perspective of the person requiring

56

assistance via the communication center was also implicitly understood as “bad.” Queries

posed to the dispatchers regarding these inferences confirmed their validity.

Types of Critical Incidents

Extraordinary incidents in the emergency services dispatch domain are broadly

broken into two categories: single multi-unit responses, and multiple single-unit

responses. The former is the classical model of a mass casualty incident (MCI), typically

exemplified as something like a bus crash, where there are several wounded individuals

requiring a number of ambulances to respond to the same scene. The later category is

described as much more challenging by the interviewed ECC personnel. Multiple single-

unit responses are common in the wake of severe weather conditions, where relatively

minor damage is wide-spread.

Administrators from two of the visited ECC’s described operations during an

especially heavy rain storm within the past year. In those cases, nearly every fire

department in the territories of those centers was kept busy for a time handling downed

tree limbs on roadways, minor flooding, and similar damage. While the work of any one

of those responses was not exceptionally difficult or complex, the coordination of that

number of simultaneous responses and the precipitant incoming calls for assistance,

stressed the capabilities of the ECC’s.

Another center’s administrator gave an account of the same weather event, but

with very different effects. In this center’s territory, similar conditions were encountered

and dealt with at first. One area of flooding damaged a gas main near an apartment

57

complex. The escaping gas ignited explosively, causing significant damage to one of the

apartment buildings. The ECC then had to direct several fire and ambulance department

resources to this one incident, while managing the priorities of the wider damage. An

interesting comment on this event is that because much of the territory’s fire apparatus

was already in the field, it was easier than normal to direct specific resource capabilities

to the explosion scene. The ECC knew that the needed equipment was already staffed,

and immediate communications with the various departments’ commanders was already

in place.

Use of Information Technologies

The levels of technology used in the different centers varied greatly. Two of the

ECC’s used standard computer-aided dispatch (CAD) software packages. Both of these

centers’ administrators described the need for moderate customization of the software.

Upon further questioning, it became clear that the customizations were essentially the

implementation of a customized data set to reflect the locally standardized labels for

geographic locations, response organization names, types of incidents, facility names, etc.

Little or no changes in the software’s functionality resulted from these customizations.

One ECC acquired ownership rights of their CAD software when the company

which had initially produced it declared bankruptcy a few years ago. Since that time, the

ECC had employed a full-time programmer responsible for maintenance and upgrades of

the software base. Several enhancements to the original functionality had been

implemented in the time since. One example of the additional functionality is portrayed

58

in Figure 3 - The primary display of an emergency communications center’s supervisor’s

station. A supervisors’ screen allowing the monitoring of overall activity in the center

was developed. Even though the CAD system uses a text-based interface, the display was

built to provide graphical cues via color use and text placement.

Figure 3 - The primary display of an emergency communications center’s supervisor’s station - The display is a representation of the entire center and shows current operational conditions. The screen to the right displays radio channel use in real-time. The far left screen can be used to display details of individual incidents.

The smallest center visited does not use a CAD system at all. Serving a very rural

area which does not generate a volume of incidents anywhere near that of the other

centers, the administration does not believe the expense of a CAD system is warranted.

Alternatively, incidents and dispatches are recorded on specialized paper cards. Space on

59

the card is reserved for recording initial information free-hand. A time-card clock is used

to record the times that resources are dispatched, responded, became available, etc. The

reverse side of the card is used for recording free-hand notes concerning the incident.

Cards are kept until the end of the month, when they are forwarded to the involved

response organizations so they can check their incident report records against them. Only

very general information concerning each incident is kept by the ECC, in the form of

hand-entered spreadsheets, for generating statistical reports.

Interestingly, the paper card system seems to allow a much more comprehensive

view of activity within the region. As each resource is dispatched, a new card is used to

record the activity of a single resource. The cards are grouped together into piles

representing individual incidents. By scanning the dispatcher’s work area and counting

the piles, one can easily determine the number of active incidents. By counting the

number of cards in each pile, one can estimate the severity of the incidents.

Even in the larger centers, there was a substantial use of such “primitive” tools as

simple paper-and-pen. The hand-written notes and reminders are used by the

telecommunications staff as memory aids and would likely appear as gibberish to anyone

other than their author. All of the visited centers appreciated the use of simple paper-and-

pen-like tools. Many of the personnel acknowledged the potential for CAD system failure

(see [Boultin 2003]) and the subsequent need to revert to more basic practices. When

queried further, the personnel indicated the paper notes would be needed after the fact to

build reports; there was not an expectation that the paper notes would be useful in real-

60

time decision making. Unlike air traffic controllers (see [Mackay, 2000]) paper is not

used to pass information between individuals.

Expected Changes

Each of the centers visited which use CAD systems expect to perform some

upgrade in their hardware and software within the next year. Though the details of the

new CAD systems were not available at the times of the interviews, the administrators

and other ECC personnel do not expect the new systems to radically alter their current

methods of operation. The planned upgrades seem to be aimed at increasing the speed of

information entry and access while not really altering the content of the information.

61

Results

The findings of the work domain analysis indicate that the overall goal of the

domain is the minimization of loss-of-life and that the general approach used to achieve

this is the appropriate allocation of emergency service resources. In referring back to

some of the questions identified for specification (see page 40), the following points

emerge from the WDA:

o The overall purpose of work within this domain is the minimization of loss-of-

life, pain and suffering, and loss of property. The mechanism for achieving these

goals is an inventory of emergency services resources, including police,

firefighting, emergency medical responders, and other resource types. All of the

interviewed ECC managers concurred with this assessment of their domain. In the

discussions with the managers and the other personnel, a common theme was

“getting the right people and apparatus to the scene as quickly as possible.” The

constraints of the system generally derive from the numbers and specific

capabilities of the emergency resources. Those capability constraints may be

functions of the composition of the specific resource (such as not carrying some

particular piece of equipment), or they may be functions of the resource’s state at

the time of need (an ambulance can not respond to two incidents at the same time;

nor can it effectively respond to some very distant locations.)

o The environment of the work domain is specific to each emergency

communications center. Though the overall goals and general work are relatively

62

homogenous, because each center is responsible for a particular geographic

region, the set of resources and constraints will vary from center to center. This

became very evident during discussions of the special-purpose resources available

to the ECC’s. One of the visited centers is located in the northeastern area of

Pennsylvania, where small lakes are a very common feature of the geography.

This feature of the environment impacts the emergency services by increasing the

incidence of water-related accidents. To address this, the county’s sheriff’s office

has established a specialized dive-rescue squad with equipment and staffing

capable of responding to a variety of water-based incidents. Likewise, the more

metropolitan regions have specialized rescue units to handle hazardous chemical

or biologic materials spills, which are more likely in those regions due to the

increased road and railway traffic.

o The meaning of “timeliness” does vary somewhat with different incident types.

However there are general policies in place to enforce some action within a set

period of time. For instance some centers may track an incident’s progress

through their system to try to achieve an initial dispatch within two minutes of

receiving the call for assistance. What variance exists is based on an initial

assessment of the severity of the incident, and used to better decide which

resources to allocate to the incident. As a general rule, however, when in doubt, it

is more desirable to over-allocate resources rather than to under-allocate. The time

from the receipt of the call to the initial dispatched was named by the ECC

managers as one of their primary metrics of performance. Said one of the

63

managers: “anything you can give us to shave a few seconds off of that time

would be welcome.” It is interesting to note that the ECC’s record the time of

each stage of an incident response, and these times are later distributed to the

police/fire/medical personnel for their own reports. The time-to-dispatch, though,

is the only span completely under the control of the ECC. Assessments of the

ECC’s timeliness in reaction to unusual events are not conducted unless there is

some otherwise known cause for concern.

o Some of the most important variables in the emergency services dispatch domain

are the number, capability, and status (availability, location) of emergency

resources; and the type, severity, and location of emergency incidents. The detail

required includes several different attributes of each resource or incident item. For

example, it may be desirable to track the individuals staffing a police response

resource so that specialized knowledge may be considered in the allocation of

resources to an incident. To be more specific with this example, consider that any

police vehicle in an area may be assigned to a traffic accident incident, but a

vehicle carrying a canine officer might better be assigned to a search for a

fugitive. This localized domain knowledge is cited by both the ECC managers and

staff as something which must be learned over time by the dispatchers and as so

serves as one measure of an individual dispatcher’s readiness for promotion.

Another, related, bit of knowledge is the appropriate methods of accessing some

of the special-purpose resources within the region. For example, the organization

of a search and rescue effort is not a common enough occurrence to allow many

64

of the dispatchers to be familiar with it. Knowledge of policies and practices

needed to coordinate such activities is regarded as another sign of experience.

These examples are mentioned here because they are seen by the ECC personnel

as areas where computer-based information systems can not be employed, due to

the complexity of the potential situations. Upon further discussion, it became

apparent that the ECC personnel were not differentiating between decision-

support information systems and decision-making information systems. This is

probably due, at least in part, to some of the rudimentary dispatch automation in

place in some of the CAD systems. Some of the systems will provide a

recommended set of response resources when the nature and location of an

incident are provided. The dispatchers report that they deviate from the system’s

recommendations only when they have some information which directly

contradicts the computer, such as the recommended resource already being

assigned to some other incident. The blind acceptance of the system’s suggestions

is seen as almost mandatory without some such contradictory information.

o The resource inventory is relatively static compared to the incoming requests for

aid. Therefore, the details of the resource inventory form the more pre-defined

(intentional) parts of the system; whereas the incoming calls are unknown and

uncontrollable (ecologic). The interaction between these two sets is embodied in

the assignment of particular resources to particular incidents. Of course, this

assignment, as well as the subsequent response of the resource, alters the status of

both the resource and the incident.

65

o The primary users of information systems within this domain are the

emergency telecommunicators staffing the communications center. The

ECC staff’s use of electronic information and communications system was

of special interest during observation periods of the site visits. While

watching the dispatchers use the computer aided dispatching systems, the

proportion of time spent entering data versus extracting data seemed very

lopsided. Though no quantitative measures were made, the observations

made in each of the centers bear this out. The implication of these

observations is that the CAD systems in place in the ECC’s are used

primarily for the collection of data through the lifespan of individual

incidents, and not used as a source of information to aid the dispatchers in

allocating resources. A related observation was made in one of the

communications centers which had made access to the internet and several

local databases, including the county’s tax assessor’s database which

includes digital photographs and other data of most of the residences in the

county, available to each dispatcher. In this center, it was common for the

dispatchers to utilize these extra data sources to support their mission. A

common practice (and one that the author had benefited from in past

experience) was supplying details of the scene of a given address to police

or ambulance personnel. The field personnel, knowing that the house they

are seeking is green with two large trees on one side, are able to locate the

scene more quickly. This example demonstrates the dispatchers’ ability to

66

consolidate disparate data sources into useful information and that there is

a desire by the ECC staff for more and better information to help them

achieve their mission. The manager of this particular center said this very

explicitly.

o A second distinct group of users is the management personnel of the

centers. Managers are interested in looking at aggregate data, and looking

for specific exceptions to established normal values. This analysis is

generally not conducted in real-time, but is part of a batch process

conducted at set intervals. The purposes of these analyses are for

mandatory reporting required by various county, state, and federal

agencies; and for gathering statistics in support of future resource

allocation, including funding.

I-T-P Abstraction Hierarchy for Emergency Services Dispatch

The work domain analysis of the emergency services dispatch domain was used to

populate the cells of an I-T-P Abstraction Hierarchy model. The top-most level of

abstraction, representing the overall purpose of the system and applicable to all three of

the peer elements, is the minimization of loss-of-life, injuries, and property damage. This

wording was chosen to acknowledge the impossibility of avoiding loss completely, and to

enumerate the highest priority concerns related to the domain’s mission. The second layer

down, abstract function, shows the initial separation of requirements between the

elements. At this level of abstraction, technology, the center column in the model, does

67

not have a distinct composition of its own. This explicitly shows that technology will be

used to link information and people, with a general notion of the purpose of the link in

both directions. The third and fourth levels show the progressive division of requirements

among the three elements. The bottom-most level of abstraction describes the real-world

forms of the three elements. In the information column, the most fundamental set of

information needed is specified. Here, the most fundamental information is the inventory

of resources, including whatever attributes of those resources which are deemed

important to the system. The bottom rank of the people column contains the description

of the actual users of the system. In this realm, and for the scope of this system, the users

are the personnel staffing the emergency communications centers. The center column,

representing the arrangement of technology we will need to construct, contains the most

basic system-level description of the components which must comprise the system. This

cell in particular can, and should, iteratively be broken down into a series of whole-part

decompositions to define the construction. The decomposition labels will be defined by

designers better versed in the specific sub-systems, such as databases, computer software,

human-computer interfaces, etc.

68

Structural Decomposition

Information Technology People

Purpose / Goal Minimize loss-of-life, injury exacerbation, property loss or damage

Abstract Function

Meaningful representation of conditions in the context of established triage and protocol criteria Appropriate allocation of resources

Generalized Function

Timely and accurate description of conditions

Organization, transformation, refinement, storage,

movement, presentation, etc. of data

Work assignments (or withholdings) for resource

inventory

Real-World Function

Representation of availability and capability of resource inventory as

well as requests for resources

Maintenance of database integrity with support for real-time data input/output

& directed sharing

Decisions based upon available data

Leve

l of A

bstr

actio

n

Real-World Form

Resource inventory and needs

assessment data

Data structure & accompanying interfaces; data distribution policies (assumes

hardware/network infrastructure is in place)

Emergency communications

personnel

Figure 4 - High-level I-T-P Abstraction Hierarchy for Emergency Services Dispatch CIIMS

Resulting System Specifications

The single most important implication for the new CIIMS design which has

emerged from the use of the I-T-P Abstraction Hierarchy model is the need to break away

from the incident-centric nature of current systems to embrace the overriding need to

monitor overall conditions. While the ability to drill-down to check the specifics of a

particular incident is important, the emergency services dispatcher has a broader

69

responsibility to the general population of their territory. This broader responsibility must

be supported explicitly in any new CIIMS design.8

The break from incident-centricity in the new design implies an approach to the

work of the system which differs from the currently implemented systems. This new

approach is essentially a higher-level situation awareness of the work environment. As

the work environment is comprised primarily of three elements, the resource inventory,

the incident inventory, and the assignments of resources to incidents, the new system

design should incorporate all three elements. The inclusion of all three elements will then

become one of the governing ideas of the system development process.

The identified fundamental information components for the CIIMS are the

assignable resources, the incidents which require resource allocation, and the pairing of

resources and incidents. Additionally, peripheral details of each of these components will

need to be encompassed in any new design. Resources of a similar type, ambulances for

example, may have many variations in their individual capabilities. For the example of

ambulance resources, significant details might include specialized equipment exceeding

8 Ironically, the information systems currently in use in the larger emergency communications centers visited during this research each incorporate a similar idea for allowing the center supervisors to monitor the overall conditions of their center. (See Figure 3 - The primary display of an emergency communications center’s supervisor’s station.) While the supervisors have the ability to drill-down to the details of any one incident, or communications station, generally they concern themselves with a less-detailed overview of the general conditions within the center. Only when specific requests are made do they become concerned with the details.

70

the required standards, or even something as straightforward as off-road driving

capabilities. Likewise, incident and assignment records will have related information to

be built into the CIIMS.

The break of incident-centricity, and the primary purpose of existing systems for

post-hoc reporting, implies the need for real-time interfaces which allow for real-time

information flow into and out of the system. The interface should include some

representation from each of the identified components without overloading the human

users with unnecessary detail. The ability to access detailed information of at least the

same quality as the current systems is an implicit requirement, but a broader overview

should allow the ECC staff to more easily maintain an awareness of conditions

throughout their territory.

Prototype Development

A basic prototype of a CIIMS for emergency services dispatch based on the

resulting system specifications was constructed utilizing the details of a special-purpose

emergency medical services control center familiar to the author.9 The prototyped system

is functional independent of the detail data, but these details add a sense of realism to the

9 The special-purpose emergency services control center coordinates the activity of more than forty response teams of varying capabilities at Penn State’s home football games. The author’s familiarity derives from fourteen years of service including several years as a supervisor, followed by a year of work with dispatch operations.

71

prototype. The prototype is based on common three-tier software architecture. The data

layer of the system is comprised of seven related core tables and a number of additional

“lookup” tables which can be used to tailor the system to specific purposes. The

processing layer is populated with functionality used to enforce data integrity while

changing the status data of resources and incidents. Additional decision support

automation could be added here, but was not pursued in the prototype. The interface layer

is comprised of several specific-purpose displays, but the main display is a departure

from those found in the CAD systems at the visited centers.

The primary user interface for the system is based on the EID premise that “The

nesting of information within a configural graphic should reflect the nesting of meaning

as characterized by the abstraction hierarchy.” [Flach, et.al. 1998, pg. 298] To this end,

the primary interface was designed to provide a very broad view of the major components

of the work domain: emergency services resources, incidents, and the present

assignments of resources to incidents.

72

Figure 5 - A screenshot of the prototype system’s main user interface

The prototype system’s main user interface is presented in Figure 5. The defined

primary elements of the CIIMS for emergency services dispatch are included as follows:

o On the left is a list of the resources defined in the database. Each resource is

color-coded to represent its current status: grey for out of service, green for

available, orange for responding, red for committed. Additionally, different

shades of green indicate whether a response team is just available at-large, or in

place at their assigned duty station. Each resource indicator can be

selected/deselected by single-clicking on it, and multiple selections are allowed in

context.

73

o The right side shows a single-column scrollable list of incidents recorded in the

database in chronologic order, with the most recent incident at the top. This

allows the users to have a common location to refer to a new incident as they

make their initial assignments. Each incident can be selected/deselected as can the

resources, but can also be expanded by double-clicking to reveal a dialog window

with detailed information and data entry capabilities.

o The area between the resources and incidents holds the “action buttons” for

working with the other elements. With these controls, the dispatchers can directly

change the status of resources, assign them to incidents, and declare or cancel

incidents. Each of these actions will generate a series of appropriate database

transactions to log the activity and update the current data set. With each update

of the status information, the corresponding interface components are redrawn to

represent the new condition. Additionally, color-coded lines appear in this area as

a background to the controls. These lines represent the links between resources

and incidents. The colors of the lines indicate an assignment (yellow), a response

(orange), and a commitment (red) of a single resource to a single incident. These

74

lines are also updated with changes to the database. The density of the lines acts

as a quick visual cue to the complexity of the current situation.10

The user interface to the CIIMS is intended to achieve EID-like goals by allowing users a

broad view of environmental conditions so that human decisions are better informed.

Drill-down capabilities to reveal more detail of the various aspects of the environment are

included in the prototype’s functionality. The user interface is, however, only one piece

of the information system being designed. Though the most visible and understandable to

lay-persons, it is by no means the most important component of the system. The interface

represents the system’s attempt to link the human element of the overall system with

technology to facilitate the transfer of information. The other side of the I-T-P

Abstraction Hierarchy model forces system designers to consider the information-

technology link as well.

The link between the basic information of the system and the technology to be

built is largely in the form of a relational database. The schema for the database

developed as part of the prototype system is shown in Appendix B. As with the user

interface, the database reflects the domain’s three primary elements. The resource

inventory, including space to record current status, is represented by the tables in the

10 The prototype interface was built and tested using standard mouse point-and-click capabilities. It was envisioned that touch-screen capabilities could be added to the machine hosting the interface to make data entry even easier. This option was explored briefly and it was found that adequate touch-screen hardware could be purchased reasonably as an add-on to the target deployment systems.

75

upper left-hand side of the diagram. Incidents and their associated attributes are to be

kept in the tables in the lower-right side of the schema. The assignments of specific

resources to specific incidents are stored in the single table in the upper-right-hand corner

of the diagram. This table will also hold time-stamps representing the status of the

assignment while allowing post-hoc analysis of the system’s historical performance.11

The remainder of the prototype’s database schema is used to contain detail regarding

geographic locations, both for resources and incidents. This reflects another piece of the

physical definition of the scope of the system.

The final component of the three-tiered design of the software information system

would be the programming code which would implement the rules governing the

assignments of resources to incidents. The rules would ideally be stored as another piece

of the relational database system, allowing for easier customization of the system in

different emergency communications centers. However, the rules and policies governing

assignment-making vary from center to center, and even between different regions under

the control of a single center. The rules implemented in the programming code would,

11 This after-the-fact analysis is the primary common feature of the information systems observed in the field study. The results of this analysis show information such as which resources (police units, fire companies, ambulances, etc.) were assigned and responded to which incidents. This information is in turn aggregated and used to inform higher-level decisions, such as where to expend funds to add or reinforce resources.

76

like the interface and database, have to consider the capabilities and constraints of the

resources, the incidents, and the assignments linking them.

Broader Implications of Findings

Though the focus of this exercise was the design of a technology artifact to

address the need of the emergency services dispatching domain, the practical design and

implementation of such an information system will require the addressing of more

general factors at play in the domain. As the inclusion of information specific to the

region to be served has been shown to be necessary for the proper working of the

information system design, so too, more general policy must be established to support the

use of these systems. Such a policy change might be necessary to interrupt the status quo

acceptance of the in-place information systems and their set of capabilities. The

information systems in use in emergency communications centers today are used

primarily for after-the-fact analysis of incident data. As these systems are adequate for

most basic day-to-day situations, the local communications centers have little incentive to

expand their current systems to support operations in extraordinary circumstances. As

stated earlier, the need to break away from the incident-centric nature of current systems

is one of the requirements of a new CIIMS which should be capable of handling

extraordinary situations. Establishing the need for real-time inventory and assignment

tracking may have to be accomplished through legislation.

An additional area for policy consideration is the interoperability of CIIMS.

Currently, emergency services coordination is addressed at the level of individual

77

counties. Incidents which may require a response from several counties can be

coordinated much more easily if the involved county’s CIIMS are able to share data.

Again, because the purchase or development of such information systems are done

county-by-county, it may be necessary for some governing entity to mandate such

interoperability in the name of preparedness for extraordinary incidents.

78

Discussion

Contributions

This work contributes to the body of literature by presenting a new model, the

Information-Technology-People Abstraction Hierarchy, for approaching the

comprehensive design and development of information systems. The model is based upon

a well established framework and addresses the interrelationships between information,

technology and people. The strengths of abstraction hierarchy modeling are primarily

focused on the development of complex systems which are able to accommodate

operations in atypical situations, which addresses one of the main reasons for failure of

complex information system designs. As part of the new model, the three peer elements

of information, technology, and people are decomposed into several layers of system

abstraction, revealing the details of implementation while maintaining a view of the

overall goals of the system and its constituent components.

As a demonstration of the I-T-P AH model, this work has included a work domain

analysis of the domain of emergency services dispatching leading to the development of a

prototype critical incident information management system. The prototype’s design

incorporates the knowledge gleaned from the WDA within the structures which form the

separate tiers of the system. The result is an information system capable of scaling to

handle the added complexity introduces by extraordinary events.

79

Future work

The immediate need for proceeding from this work would be the development of

additional and more detailed examples of the model’s application to a variety of domains.

Candidate domains include military command and control, financial management

systems, and medical informatics. Initially, the models can be validated through a

qualitative process of member-checking with experts in the target domain. A logical

follow-on would be the development of prototypical information systems for testing via

simulation or parallel action with current systems.

When actual systems are to be constructed, an effort would have to be made

toward developing metrics to measure the success or shortcomings of information

systems developed using the I-T-P Abstraction Hierarchy model. Developing good

metrics for information systems is notoriously difficult even within a single domain

[Athey & Stern 2000]. Proper metrics for this model would have to account for the fact

that it is to be used by one domain, information system development, to describe some

other domain. Koenemann-Belliveau, et. al. [1994] proposed an evaluative system which

involves the refinement of critical incidents to critical threads of activity. This technique

may be useful in verifying the efficacy of the I-T-P Abstraction Hierarchy model in

information systems design by selecting critical threads that domain experts report as

troublesome with current systems. It may be that anecdotal evidence will have to be

collected from a number of projects to help validate the model. Furthermore, one of the

primary purposes of the model is to aid in the design of information systems which need

to adapt to atypical conditions. Quantitatively measuring performance in such conditions

80

is problematic at best. Methods to evaluate the entropy of the resulting information

systems might be useful in this regard.

Though the model presented in this work should help to design systems capable

of handling extraordinary situations, the performance of information systems in normal

day-to-day activities should be enhanced as an additional benefit. Perhaps one of the best

measures of the effectiveness of this tool will be the user-acceptance of systems built

with it.

Future work related to the demonstration CIIMS for emergency services

dispatching would include the completion of the prototype system to a field-testable state

followed by the iterative design cycles described by the Living-Lab/AUTO frameworks.

Testing would have to proceed from the handling of day-to-day operations and include

tests in some sets of extraordinary circumstances. One possibility is to extend the

prototype for use in controlling resource allocation in large events, such as the sporting

events used to populate the prototype’s database.

Proving the efficacy of the CIIMS built using the I-T-P AH would be a first step

in justifying the need for policy changes which would bring the additional capabilities

into common use, and provide for greater interoperability between ECC’s.

81

Conclusion

This work has presented the Information-Technology-People Abstraction

Hierarchy model as an aid for designing information systems which may be required to

scale to atypical levels of situational complexity. The use of the I-T-P AH requires a

work domain analysis to populate the model with a set of relationships between the peer

elements of information, technology, and people at varying layers of abstraction ranging

from the overall general goals down to the real-world implementation. The model can

then be used to produce initial and evolving specifications for the system. The means-

ends relationships between layers and the relationships between the peer elements at

varying levels of abstraction can help guide the development of information systems,

informing the appropriate requirements for data, processing, and interface design.

In the emergency services dispatching domain used as a demonstration, the I-T-P

Abstraction Hierarchy model makes clear the need to depart from the current incident-

centric nature of computer aided dispatch systems. The ability of the emergency

communications centers’ staffs to quickly assess the overall inventory allocation situation

is needed to better handle extraordinary incidents. This requirement is shown through

each level of the model as individual incidents are consistently considered as a piece of a

greater context involving many possible needs and available resources. The design and

construction of a preliminary Critical Incident Information Management System

prototype shows how the I-T-P AH can be used to produce an information system able to

support atypical operations by addressing the overall goal of the system’s work domain.

82

Appendix A: examples of I-T-P Abstraction Hierarchy models for non-technology-centered projects.

In an effort to quickly demonstrate the application of the I-T-P Abstraction

Hierarchy model to the breadth of the I-T-P elements, two models have been built. The

first model represents the training of a person as a part of a comprehensive information

system. The implication of placing “people” in the center column of the model is that a

particular type of person or organization of people will be the goal of a design project,

and that this person or organization will be used to link information and technology. A

generalized version of this model might be the basis for a training program of any human

decision makers who will utilize technology to understand and manipulate complex data.

Structural Decomposition

Information People Technology

Purpose / Goal Increase in overall value of fund

Abstract Function

Description of business environment and conveyance of decision makers’ wishes

Understanding and manipulation of environment (buying / selling)

Generalized Function

Refined or transformed data which accurately describe

relevant conditions and users’ wishes in a timely fashion

Understanding of business practices, legal issues,

corporate interactions, etc.

Organization, transformation, refinement, storage, movement,

presentation, etc. of data

Real-World Function

Representation of exhaustive set of available

details

Analysis of business conditions and direction to buy/sell particular stocks

Presentation of data to users, and interpretation of users’

directions Leve

l of A

bstr

actio

n

Real-World Form

Stock market data, business news, trend

analysis data, etc. Stock Market Fund Managers

Communications links with data warehouses and stock traders, DSS processes and displays, etc.

Figure 6 - I-T-P Abstraction Hierarchy for Stock Market Fund Managers, demonstrating the model’s use for defining the educational requirement for a person who is part of an information system

83

The second model represents the construction of an arrangement of information to

bridge technology and people. The example given is this work you are reading now. The

purpose of this paper is to present a particular technology to a particular group of people

with the overall goal of aiding the design and construction of complex information

systems.

Structural Decomposition

Technology Information People

Purpose / Goal

Aid in the design and construction of complex information systems with an emphasis on scalability for complexity increases.

Abstract Function

Documented understanding of scope of system Formulation of possible solutions

Generalized Function

Description of interactions between elemental units Presentation of model Understanding of system

requirements and constraints

Real-World Function

Decomposition of system into peer elements

Communication of author’s proposal with supporting documentation System models

Leve

l of A

bstr

actio

n

Real-World Form

The I-T-P Abstraction Hierarchy model My Thesis Information systems

designers

Figure 7 - I-T-P Abstraction Hierarchy for this thesis

84

Appendix B: database schema of prototyped system

Figure 8 - database schema of prototyped CIIMS for emergency medical services control

85

Appendix C: interview outlines used during site-visits to emergency communications centers

Dispatch Center Administrators

Basic Center Demographics

o Description of region served (geography, population distribution, etc.)?

o Number of (police, fire, medical, other) services controlled by facility?

o Number of incidents (per day, month, year; by service type)?

o Number of “big” incidents?

Technology Currently in Use

o Number/Types of computer systems in use?

o How are they related (network structure, dedicated systems, stand-alones)?

o What is the ratio of systems directly used by the dispatch process versus “secondary” systems? (administrative, backup, etc.)

o Is there internet connectivity? Which systems?

o Is audio radio traffic recorded digitally?

o Cost of information technology? (hardware, software, training, maintenance)

o Plans for future IT systems?

Available Data

o How is real-time status information recorded/accessed?

o What real-time data is not being recorded for quick access?

o Is status data used within the information technology (opposed to just being recorded)? i.e. – Is there any decision support automation?

86

o How would you assess the status of neighboring centers’ resources?

o How would neighboring centers assess your resource status?

o What is your “wish list” of features not currently part of your information system?

Response Plans for “Big” Incidents

o How are dispatchers prepared to handle “big” incidents?

o Do the current IT systems help or hinder them? How so?

o How would interactions with neighboring centers and their resources be handled?

Dispatchers

Basic Demographics

o How long as a dispatcher? (full/part-time)

o Background involvements in police/fire/medical/other?

o Usual work assignment? (police/fire/medical/combined) (call-taker/dispatcher/combined)

History

o Description of most notable incident(s):

o Description of most notable “big” incidents:

o Specific problems?

o Specific pre-planned assets?

o Use of information technology?

Use of information systems

o Are the IT systems a help or hindrance? How so?

87

o What is your “wish list” of features for a dispatch IT system?

Response Plans for “Big” Incidents

o In the even of a “big” incident, would the IT systems be a help or a hindrance? How so?

o What might an information system need to do to help you in such a situation?

88

Appendix D: references related to the WDA and demonstration system Bentley, R. & Hughes, J. A. & Randall, D. & Rodden, T. & Sawyer, P. & Shapiro,

D. & Sommerville, I.; Ethnographically-Informed Systems Design for Air Traffic Control; ACM - CSCW’92; (November 1992)

Beyersdorf, SR., Nania, JN., & Luna, GK: Community medical response to the Fairchild mass casualty event. American Journal of Surgery, v.171, pp.467-70; (1996)

Brown, Diane S. & Motte, Susan; Device Design Methodology for Trauma Applications; ACM – CHI ’98; (April 1998)

Cristan, Flaviu & Dancey, Bob & Dehn, Jon; 1996; Fault-Tolerance in Air Traffic Control Systems; ACM Transactions on Computer Systems, Vol. 14, No. 3, pp. 265-86; (August 1996)

Crow, Ed & Jonson, Janet; Wireless Handheld Electronic Devices Assisting Emergency Medical Field Personnel: FINAL REPORT; Submitted to Pennsylvania Department of Health, Emergency Medical Services Office; Grant Agreement ME 00172; available online at: http://www.arl.psu.edu/documents/final_report_padoh_july2001.pdf; (October 2001)

Farahmand, Kambiz; Application of Simulation Modeling to Emergency Population Evacuation; Proceedings of the 1997 Winter Simulation Conference; ed.: Andradottir, S. & Healy, K. J. & Withers, D.H. & Nelson, B.L.; pp.1181-8; (1997)

Feliciano DV, Anderson GV, Rozycki GS, et al: Management of casualties from the bombing at the Centennial Olympics; American Journal of Surgery, v.176, pp.538-543; (1998)

Finkelstein, Anthony & Dowell, John; A Comedy of Errors: the London Ambulance Service case study; Proceedings of the 8th International Workshop on Software Specification and Design (IWSSD `96); IEEE; (1996)

Normark, M.: Sense-making of an emergency call - possibilities and constraints of a computerized case file. Paper presented at the The Second Nordic Conference on Human-Computer Interaction, NordiCHI 02, Aarhus, Denmark; (October 2002)

Gosbee, John & Ritchie, Eileen; Human–Computer Interaction and Medical Software Development; Interactions; (July/August 1997)

89

Holzman, Thomas G.; Computer-Human Interface Solutions for Emergency Medical Care; Interactions; (May/June 1999)

Mackay, Wendy E.; Is Paper Safer? The Role of Paper Flight Strips in Air Traffic Control; 2000; ACM Transactions on Computer-Human Interaction, Vol. 6, No. 4, pp. 311-40; (December 1999)

Mayer-Schönberger, Viktor; Emergency Communications: The Quest for Interoperability in the United States and Europe; (2002)

McCarthy, John C., Peter C. Wright, Patrick Healey, Andrew Dearden, Michael D. Harrison: Locating The Scene: The Particular and The General in Contexts for Ambulance Control; Proceedings of the international ACM SIGGROUP conference on Supporting group work : the integration challenge: the integration challenge, pp.101-110; (November 1997)

Pettersson, Marten & Randall, Dave & Helgeson , Bo; Ambiguities, Awareness and Economy: A Study of Emergency Service Work; ACM – CSCW’02; (November 2002)

Rhodenizer, Lori & Pharmer, James & Bowers, Clint A. & Cuevas, Haydee M.; An Analysis of Critical Incident Reports from a 911 Center; Proceedings of the Human Factors and Ergonomics Society Annual Meeting; (2000)

Sawyer, Steve & Tapia, Andrea & Pesheck, Leonard & Davenport, John; Mobility and the First Responder; Communications of the ACM, Vol. 47, No. 3; (March 2004)

Sellnow, Timothy L. & Seeger, Matthew; Exploring the boundaries of crisis communication: The case of the 1997 Red River Valley Flood; Communication Studies, v.52, no.2, pp.153-67; (Summer 2001)

Tracy, Karen & Tracy, Sarah J.; Rudeness at 911; Human Communication Research, v..25, no.2; (December 1999)

Turoff, Murray; Past and Future Emergency Response Information Systems; Communications of the ACM; Vol. 45, No. 4, pp. 29-32; (April 2002)

Wachtendorf, Tricia; A River Runs Through It: Cross Border Interaction During the 1997 Red River Flood; Master’s Thesis, University of Delaware, Department of Sociology; (Fall 1999)

Xiao, Y., Hunter, W-A., MacKenzie, C.F., Jeffties,N.J.: Task Complexity in Emergency Medical Care and Its Implications for Team Coordination; Human Factors, v.38, no.4, pp.636-645; (1996)

90

Xiao, Y. & The LOTAS Group: Understanding Coordination in a Dynamic Medical Environment: Methods and Results. In McNeese, M., Salas, E., & Endsley, M. (Eds.): New Trends in Collaborative Activities: Understanding System Dynamics in Complex Environments, Santa Monica, CA: Human Factors and Ergonomics Society, pp.242-258; (2001)

Zhu, Zhiwei & McKnew, Mark A. & Lee, Jim; Effects of Time Varied Arrival Rates: An Investigation in Emergency Ambulance Service Syetrms; Proceedings of the 1992 Winter Simulation Conference; Ed.: Swain, J. J. & Goldsman, D. & Crain, R.C. & Wilson, J.R.; pp.1180-6; (1992)

91

References: Alter, Steven; A General, Yet Useful Theory of Information Systems;

Communications of the Association for Information Systems; Vol. 1, Article 13; (March 1999)

Athey, Susan & Stern, Scott; The Impact of Information Technology on Emergency Health Care Outcomes; National Bureau of Economic Research (NBER) Working Paper No. 7887; http://www.nber.org/papers/w7887; (September 2000)

Beyersdorf, SR., Nania, JN., & Luna, GK: Community medical response to the Fairchild mass casualty event. American Journal of Surgery, v.171, pp.467-70; (1996)

Bisantz, Ann M. & Vicente, Kim J; Making the Abstraction Hierarchy Concrete; http://www.eng.buffalo.edu/~bisantz/pubs/revision.html; (1994)

Boin, Arjen & Lagadec, Patrick & Michel-Kerjan, Erwann & Overdijk, Werner; Critical Infrastructures Under Threat: Learning from the Anthrax Scare; Journal of Contingencies and Crisis Management; Vol. 11, No. 3; (September 2003)

Boy, Guy A.: Cognitive Function Analysis for Human-Centered Automation of Safety-Critical Systems; Proceedings of CHI'98, ACM Press, ppp.265-272; (May 1998)

Crow, Ed & Jonson, Janet; Wireless Handheld Electronic Devices Assisting Emergency Medical Field Personnel: FINAL REPORT; Submitted to Pennsylvania Department of Health, Emergency Medical Services Office; Grant Agreement ME 00172; available online at: http://www.arl.psu.edu/documents/final_report_padoh_july2001.pdf; (October 2001)

Feliciano DV, Anderson GV, Rozycki GS, et al: Management of casualties from the bombing at the Centennial Olympics; American Journal of Surgery, v.176, pp.538-543; (1998)

Finkelstein, Anthony & Dowell, John; A Comedy of Errors: the London Ambulance Service case study; Proceedings of the 8th International Workshop on Software Specification and Design (IWSSD `96); IEEE; (1996)

92

Flanagan, J. C.; The critical incident technique; Psychological Bulletin; Vol. 51, No. 4, pp. 327-359; (July 1954).Fountain, Jane E.; A Note on the Critical Incident Technique and its Utility as a Tool of Public Management Research; Note presented at the panel on qualitative methods, annual meeting of the Association of Public Policy and Management, Washington, D.C., November 4-6, 1999; (October 1999)

Hajdukiewicz, John R. & Burns, Catherine M. & Vicente, Kim J. & Eggleston, Robert G.; Work Domain Analysis for Intentional Systems; Proceedings of the Human Factors and Ergonomics Society 43rd Annual Meeting; (1999)

Holzman, Thomas G.; Computer-Human Interface Solutions for Emergency Medical Care; Interactions; (May/June 1999)

Knight, John C.: Safety Critical Systems: Challenges and Directions; Invited Mini-Tutorial, Proc. ICSE'2002: 24th International Conference on Software Engineering, ACM Press, pp.547-550; (2002)

Koenemann-Belliveau, Jurgen & Carroll, John M. & Rosson, Mary Beth & Singley, Mark K.; Comparative Usability Evaluation: Critical Incidents And Critical Threads; ACM – CHI `94; (1994)

Normark, M.: Sense-making of an emergency call - possibilities and constraints of a computerized case file. Paper presented at the The Second Nordic Conference on Human-Computer Interaction, NordiCHI 02, Aarhus, Denmark; (October 2002)

Mackay, Wendy E.; Is Paper Safer? The Role of Paper Flight Strips in Air Traffic Control; 2000; ACM Transactions on Computer-Human Interaction, Vol. 6, No. 4, pp. 311-40; (December 1999)

Mayer-Schönberger, Viktor; Emergency Communications: The Quest for Interoperability in the United States and Europe; (2002)

McCarthy, John C., Peter C. Wright, Patrick Healey, Andrew Dearden, Michael D. Harrison: Locating The Scene: The Particular and The General in Contexts for Ambulance Control; Proceedings of the international ACM SIGGROUP conference on Supporting group work : the integration challenge: the integration challenge, pp.101-110; (November 1997)

McNeese, Michael D.; An Ecological Perspective Applied to Multi-Operator Systems; In O. Brown & Hendrick, H. L. (Eds.), Human factors in organizational design and management— VI (pp. 365–370). The Netherlands: Elsevier.; (1996)

McNeese, Michael D. & Perusich, Karl & Rentsch, Joan R.; Advancing Socio-Technical Systems Design Via the Living Laboratory; Proceedings of the Human Factors and Ergonomics Society Annual Meeting, pp.610-3; (2000)

93

Moodie, Michael & Ban, Jonathan & Manzi, Catherine & Powers, Michael J.; Bioterrorism in the United States: Threat, Preparedness, and Response; Submitted by the Chemical and Biological Arms Control Institute; Contract No. 200*1999*00132; available online at: http://www.cbaci.org/PDFCDCFinalReport.pdf; (November 2000)

Rasmussen, Jens; Elsevier Science Publishing Co., Inc.; New York, NY.; Information Processing and Human-Machine Interaction; North-Holland series in system science and engineering; volume 12; (1986)

Rasmussen, Jens & Pejtersen, Annelise Mark & Goodstein, L. P.; John Wiley & Sons, Inc. ; New York, NY. ; Cognitive Systems Engineering; (1994)

Rhodenizer, Lori & Pharmer, James & Bowers, Clint A. & Cuevas, Haydee M.; An Analysis of Critical Incident Reports from a 911 Center; Proceedings of the Human Factors and Ergonomics Society Annual Meeting; (2000)

Rivera, Theodore & Tate, Adam & Will, Scott A.; Actively Involving Our Information Development Teams with Clients; ACM - SIGDOC’03, October 12-15, 2003, San Francisco, CA; (2003)

Roth, E.M. & Patterson, E.S. & Mumaw, R.J.. Cognitive Engineering: Issues in User-Centered System Design. In Marciniak, J. J.(Ed.), Encyclopedia of Software Engineering, 2nd Edition (pp 163 – 179). New York: Wiley-Interscience, John Wiley & Sons; (2002)

Rouse, William B.: Human-Computer Interaction in the Control of Dynamic Systems; ACM Computing Surveys, v.13, no.1, pp.71-99; (1981)

Sawyer, S. & Chen, T.; Conceptualizing Information Technology and Studying Information Systems: Trends and Issues; in Myers, M. & Wynn, E. & DeGross, J. (Eds.) Global and Organizational Discourse About Information Technology,London: Kluwer, pp.109-131; (2002)

Sawyer, Steve & Tapia, Andrea & Pesheck, Leonard & Davenport, John; Mobility and the First Responder; Communications of the ACM, Vol. 47, No. 3; (March 2004)

Singh & Kotze; An Overview of Systems Design and Development Methodologies with Regard to the Involvement of Users and Other Stakeholders; Proceedings of SAICSIT 2003, pp. 37-47 (2003)

Turoff, Murray; Past and Future Emergency Response Information Systems; Communications of the ACM; Vol. 45, No. 4, pp. 29-32; (April 2002)

Vicente, Kim J. & Rasmussen, Jens; Ecological interface design: Theoretical foundations; IEEE Transactions on Systems, Man, and Cybernetics, SMC-22, pp.589 -606; (1992)

94

Vicente, Kim J.; Human Factors and Ergonomics Society; Ecological Interface Design: Progress and Challenges; Human Factors; Vol. 44, No. 1; ProQuest Psychology Journals; pp. 62-78; (Spring 2002)

Vicente, Kim J.; Ecological Interface Design: Supporting Operator Adaptation, Continuous Learning & Distributed, Collaborative Work; Applied Cognitive Science and Human Centered Systems; HPC’99, Brest, France; pp. 93-97; (September 1999)

Vicente, Kim J.; The Human Factor; Routledge; New York, NY.; (2004)

Xia, Weidong & Lee, Gwanhoo; Grasping the Complexity of IS Development Projects; Communications of the ACM; Volume 47, Number 5; (May 2004)

Xiao, Y., Hunter, W-A., MacKenzie, C.F., Jeffties,N.J.: Task Complexity in Emergency Medical Care and Its Implications for Team Coordination; Human Factors, v.38, no.4, pp.636-645; (1996)

Xiao & Mackenzie; Micro-Theory Methodology in Critical Incident Analysis; Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, pp.2545-2550; (1998)

Xiao, Y. & The LOTAS Group: Understanding Coordination in a Dynamic Medical Environment: Methods and Results. In McNeese, M., Salas, E., & Endsley, M. (Eds.): New Trends in Collaborative Activities: Understanding System Dynamics in Complex Environments, Santa Monica, CA: Human Factors and Ergonomics Society, pp.242-258; (2001)

Zaff, B.S., M.D. McNeese, and D.E. Snyder: Capturing multiple perspectives: a user-centered approach to knowledge and design acquisition; Knowledge Acquisition, v.5, pp.79-116; (1993)