U.S. Department of 

Transportation 

Federal Railroad 

Administration

Human Error Investigation Software Tool (HEIST) 

Office of Research 

and Development 

Washington, DC 20590 

DOT/FRA/ORD-07/15 Final Report 

May 2007 

This document is available to the 

U.S. public through the National 

Technical Information Service, 

Springfield, VA 22161. 
NOTICE 

This document is disseminated under the sponsorship of the

Department of Transportation in the interest of information

exchange. The United States Government assumes no liability for 

its contents or use thereof. 

NOTICE 

The United States Government does not endorse products or

manufacturers. Trade or manufacturers’ names appear herein

solely because they are considered essential to the objective of this

report. 

 
i

REPORT DOCUMENTATION PAGE Form Approved 

 OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. 

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED

May 2007 Final Report 

June 2005–March 2007 

4. TITLE AND SUBTITLE

Human Error Investigation Software Tool (HEIST) 

5. FUNDING NUMBERS 

DTFR53-01-D-00029 6. AUTHOR(S)

Stephen Reinach1

, Alex Viale1, and Donald Green2

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION 

REPORT NUMBER 1. Foster-Miller, Inc. 2. Consultant 

 350 Second Avenue DFRA.060053 

 Waltham, MA 02451-1196 

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING 

 AGENCY REPORT NUMBER U.S. Department of Transportation 

Federal Railroad Administration DOT/FRA/ORD-07/15 Office of Research and Development 

Washington, DC 20590 

11. SUPPLEMENTARY NOTES 

COTR: Dr. Thomas Raslear 

12a. DISTRIBUTION/AVAILABILITY STATEMENT

This document is available to the public through the National Technical Information Service, 

Springfield, VA 22161, and www.fra.dot.gov

12b. DISTRIBUTION CODE

. 

13. ABSTRACT (Maximum 200 words)

Human factors are a leading cause of train accidents and incidents in the United States. Human factors go beyond the 

crewmembers who operate the on-track equipment. They include management support and oversight, operating practices and 

procedures, technologies and facilities, and the work culture—in short, the socio-technical environment in which railroad 

employees work. The purpose of this project was to develop a software tool to help Federal Railroad Administration personnel, 

and the railroad industry in general, systematically consider human factors issues at all levels of the socio-technical environment 

(or system) when investigating the causes or contributing factors of train accidents, incidents, and close calls. This report 

describes the development and features of the Human Error Investigation Software Tool (HEIST). HEIST is a portable Tablet and 

Windows-based application that can be used in the field, a hotel room, or an office to support accident/incident investigations. 

HEIST data collection tools include a checklist of things to consider; operator, front-line supervisor, and manager interview 

guides; a human factors taxonomy and definitions; an interactive data collection aid; and an online accident/incident/close call 

summary form. Data classification tools include an interactive aid and practice module. A HEIST user manual was also produced

under separate cover. The report concludes with some recommendations for future enhancements to HEIST, including 

implementation of a centralized accident, incident, and close call database, and preparation of a field test. 

15. NUMBER OF PAGES

41 

14. SUBJECT TERMS

Human error, root cause analysis, railroad safety, human factors, HFACS 

16. PRICE CODE

17. SECURITY CLASSIFICATION 18. SECURITY CLASSIFICATION 19. SECURITY CLASSIFICATION 20. LIMITATION OF ABSTRACT

 OF REPORT OF THIS PAGE OF ABSTRACT

 Unclassified Unclassified Unclassified

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 

Prescribed by ANSI Std. 239-18 

298-102 
ii

METRIC/ENGLISH CONVERSION FACTORS 

ENGLISH TO METRIC METRIC TO ENGLISH

LENGTH (APPROXIMATE) LENGTH (APPROXIMATE) 

1 inch (in) = 2.5 centimeters (cm) 1 millimeter (mm) = 0.04 inch (in) 

1 foot (ft) = 30 centimeters (cm) 1 centimeter (cm) = 0.4 inch (in) 

1 yard (yd) = 0.9 meter (m) 1 meter (m) = 3.3 feet (ft) 

1 mile (mi) = 1.6 kilometers (km) 1 meter (m) = 1.1 yards (yd) 

 1 kilometer (km) = 0.6 mile (mi)

AREA (APPROXIMATE) AREA (APPROXIMATE) 

1 square inch (sq in, in2) = 6.5 square centimeters (cm2) 1 square centimeter (cm2) = 0.16 square inch (sq in, in2) 

1 square foot (sq ft, ft2) = 0.09 square meter (m2) 1 square meter (m2) = 1.2 square yards (sq yd, yd2) 

1 square yard (sq yd, yd2) = 0.8 square meter (m2) 1 square kilometer (km2) = 0.4 square mile (sq mi, mi2) 

1 square mile (sq mi, mi2) = 2.6 square kilometers (km2) 10,000 square meters (m2) = 1 hectare (ha) = 2.5 acres 

1 acre = 0.4 hectare (he) = 4,000 square meters (m2) 

MASS - WEIGHT (APPROXIMATE) MASS - WEIGHT (APPROXIMATE) 

1 ounce (oz) = 28 grams (gm) 1 gram (gm) = 0.036 ounce (oz) 

1 pound (lb) = 0.45 kilogram (kg) 1 kilogram (kg) = 2.2 pounds (lb) 

1 short ton = 2,000 pounds 

(lb) 

= 0.9 tonne (t) 1 tonne (t) =

=

1,000 kilograms (kg) 

1.1 short tons

VOLUME (APPROXIMATE) VOLUME (APPROXIMATE) 

1 teaspoon (tsp) = 5 milliliters (ml) 1 milliliter (ml) = 0.03 fluid ounce (fl oz) 

1 tablespoon (tbsp) = 15 milliliters (ml) 1 liter (l) = 2.1 pints (pt) 

1 fluid ounce (fl oz) = 30 milliliters (ml) 1 liter (l) = 1.06 quarts (qt) 

1 cup (c) = 0.24 liter (l) 1 liter (l) = 0.26 gallon (gal) 

1 pint (pt) = 0.47 liter (l) 

 1 quart (qt) = 0.96 liter (l) 

1 gallon (gal) = 3.8 liters (l) 

1 cubic foot (cu ft, ft3) = 0.03 cubic meter (m3) 1 cubic meter (m3) = 36 cubic feet (cu ft, ft3) 

1 cubic yard (cu yd, yd3) = 0.76 cubic meter (m3) 1 cubic meter (m3) = 1.3 cubic yards (cu yd, yd3)

TEMPERATURE (EXACT) TEMPERATURE (EXACT) 

[(x-32)(5/9)] °F = y °C [(9/5) y + 32] °C = x °F

QUICK INCH - CENTIMETER LENGTH CONVERSION

0 1 2 34 5

Inches

Centimeters 01 3 26 1 4 5 7 1098 1 12

QUICK FAHRENHEIT - CELSIUS TEMPERATURE CONVERSION

 -40° -22° -4° 14° 32° 50° 68° 86° 104° 122° 140° 158° 176° 194° 212°

 

°F

 °C -40° -30° -20° -10° 0° 10° 20° 30° 40° 50° 60° 70° 80° 90° 100°

For more exact and or other conversion factors, see NIST Miscellaneous Publication 286, Units of Weights and 

Measures. Price $2.50 SD Catalog No. C13 10286 Updated 6/17/98

13
iii

Contents 

Illustrations ..................................................................................................................................... v 

Tables.............................................................................................................................................. v 

Preface........................................................................................................................................... vii 

Executive Summary........................................................................................................................ 1 

1. Introduction............................................................................................................................... 3 

1.1 Background...................................................................................................................... 3 

1.2 Objective.......................................................................................................................... 5 

1.3 Overall Approach............................................................................................................. 6 

1.4 Scope................................................................................................................................ 6 

1.5 Organization of the Report............................................................................................... 6 

2. HEIST Development................................................................................................................. 7 

3. HEIST Overview and Tools...................................................................................................... 9 

3.1 HEIST System Overview................................................................................................. 9 

3.2 Data Collection Tools .................................................................................................... 10 

3.3 Data Classification Tools............................................................................................... 12 

3.4 Reporting Tools ............................................................................................................. 14 

3.5 Software Requirements.................................................................................................. 14 

4. Future Directions .................................................................................................................... 15 

4.1 Future Enhancements..................................................................................................... 15 

4.2 Possible Next Steps........................................................................................................ 17 

5. References............................................................................................................................... 19 

Appendix A. HFACS and HFACS-RR........................................................................................ 21 

Appendix B. User Evaluation Form............................................................................................. 29 

Abbreviations and Acronyms ....................................................................................................... 31 

v

Illustrations 

Figure 1. Human factors accident investigation software initial concept of operations................ 5 

Figure 2. HFACS-RR revised for HEIST and C3RS..................................................................... 8 

Figure 3. HEIST concept ............................................................................................................... 9 

Figure 4. HEIST accident/incident summary form page ............................................................. 10 

Figure 5. HEIST data collection aid (with mouse-over definition shown).................................. 12 

Figure 6. Screen shot of HEIST practice tool.............................................................................. 13 

Figure 7. HAT help function........................................................................................................ 14 

Tables 

Table 1. U.S. train accident data, 2002-2006................................................................................. 3

vii

Preface 

Human factors are a leading cause of train accidents and incidents in the United States. Human 

factors go well beyond the crewmembers who operate the on-track equipment. They include 

local and senior management support and oversight, operating practices and procedures, 

technologies and facilities, and the work culture—in short, the socio-technical environment in 

which railroad employees work. The purpose of this project was to develop a software tool to 

help Federal Railroad Administration (FRA) personnel, and the railroad industry in general, 

systematically consider human factors issues at all levels of the socio-technical environment (or 

system) when investigating the causes or contributing factors of train accidents, incidents, and 

close calls. This work was based on earlier development work under a Small Business 

Innovative Research Phase I program, which identified user requirements and a human factors 

framework, and generated an initial concept of operations. The current research was performed 

under FRA Office of Research and Development Contract DTFR53-01-D-00029. 

The authors would like to thank a number of individuals who assisted in the development or 

support of this tool. First, the authors would like to express thanks in particular to Dr. Thomas 

Raslear, FRA Office of Research and Development Human Factors Program, for sponsoring the 

research and providing programmatic support. The authors also wish to thank Mr. Ralph Elston, 

Mr. Theodore Bundy, and Mr. Patrick McFall, FRA Office of Safety, for their technical support, 

guidance, and critical feedback during the development and testing of the tool. The authors also 

want to thank Dr. Jordan Multer, Volpe National Transportation Systems Center, for 

collaborating on the update to the Human Factors Analysis and Classification System-Railroad 

taxonomy and associated definitions used in the Human Error Investigation Software Tool, as 

well as for providing valuable feedback throughout the project. Lastly, the authors wish to thank 

Ms. Susan McDonough, Foster-Miller, for providing administrative and programmatic support to 

the project and authors, and for reviewing a draft copy of the report. 

1 

Executive Summary 

Human factors are a leading cause of train accidents and incidents in the United States. Human 

factors go well beyond the crewmembers who operate the on-track equipment. They include 

local and senior management support and oversight, operating practices and procedures, 

technologies and facilities, and the work culture—in short, the socio-technical environment in 

which railroad employees work. The purpose of this project was to develop a software tool to 

help Federal Railroad Administration (FRA) personnel, and the railroad industry in general, 

systematically consider human factors issues at all levels of the socio-technical environment, 

when investigating the causes or contributing factors of train accidents, incidents, and close calls. 

This report describes the development and features of the Human Error Investigation Software 

Tool (HEIST). HEIST is a portable Tablet and Windows-based application that can be used in 

the field, a hotel room, or an office to support accident/incident investigations. HEIST is based 

on earlier development work that identified user requirements and a human factors framework 

and generated an initial concept of operations. The overall approach used to develop HEIST 

involved the following steps: 

• Refining the concept of operations based on feedback from FRA Office of Safety 

stakeholders 

• Developing a functional specification for the software 

• Implementing the functional specification (i.e., developing the software) 

• Debugging and improving HEIST using an iterative process 

• Demonstrating HEIST to Office of Safety stakeholders and providing a brief user trial 

period to obtain Office of Safety feedback 

• Updating HEIST based on Office of Safety feedback 

A user manual was also developed to accompany and support HEIST. 

HEIST was built using the .Net software development framework. It is designed to be used on a 

ruggedized Tablet PC that can be used in the field, but it can operate on any other computer 

running Microsoft Windows XP (i.e., another laptop or desktop PC). HEIST can be used in the 

field and/or an office environment to collect, analyze, classify, and report on accidents, incidents, 

and close calls. 

HEIST data collection tools include a checklist of things to consider; operator, front-line 

supervisor, and manager interview guides; a human factors taxonomy and definitions; an 

interactive data collection aid; and an online accident/incident/close call summary form. Data 

classification tools include an interactive aid and practice tool. 

Although the tool has been demonstrated to FRA Office of Safety stakeholders, it would be 

valuable to field test the software with FRA Office of Safety regional inspectors to obtain their 

feedback on usability and functionality before HEIST is distributed and used on a large scale. 

Furthermore, several enhancements to HEIST are suggested to increase functionality, including 

development of a HEIST analysis aid and implementation of a remote, centrally located 

database. 

3

1. Introduction 

1.1 Background 

Although the number and percent of train accidents associated with human error have begun to 

decrease recently in the United States, they remain a significant portion—over one-third—of all 

U.S. railroad accidents, according to FRA data (see Table 1). Human factors often equates to 

blaming the crewmember(s) closest in time and proximity to the accident. Human factors and 

human error, however, go well beyond the crewmembers. James Reason, a leading expert in the 

field of human error theory, notes, 

...human error is a consequence not a cause. Errors...are shaped and provoked 

by upstream workplace and organizational factors. Identifying an error is merely 

the beginning of the search for causes, not the end. The error, just as much as the 

disaster that may follow it, is something that requires an explanation. Only by 

understanding the context that provoked the error can we hope to limit its 

recurrence (Reason, 1997, p. 126). 

Table 1. U.S. train accident data, 2002-2006 

Total U.S. Train 

Accidents 

Human Factor

Train Accidents 

Human Factor Accidents as Percentage 

of Total U.S. Train Accidents 

2002 2738 1050 38

2003 3013 1227 41

2004 3375 1354 40

2005 3236 1253 39

2006 2834 1000 35

Source: http://safetydata.fra.dot.gov; data exclude highway-rail grade crossing accidents. 

A number of models of human error arose in the 1990s and 2000s, which explain organizational 

accidents as arising from a host of factors at all levels of the organization or system. Reason’s 

Swiss Cheese model of accident causation is, perhaps, the most well known. The Swiss Cheese 

model posits that accidents, envisioned as a straight arrow or vector, occur when holes line up in 

the various layers of an organization in just the right manner to allow or enable the accident 

arrow to penetrate through all of the layers. Each layer represents a different level of an 

organization, and, more specifically, these layers represent various organizational accident 

barriers. It is when these barriers fail at all levels that accidents occur. Reason discusses these 

layers in terms of active and latent factors. Active factors are those decisions, conditions, or 

other aspects that are closest in time and physical space to the accident/incident. They have 

traditionally been most often cited as the cause of an accident/incident (e.g., a shop employee has 

a momentary slip of attention while grinding a wheel flange and injures his hand). Latent factors 

(decisions or conditions) often exist for years and may never be identified as a safety issue unless 

they are explicitly examined (e.g., an employee rushes to get the job done due to implicit or 
4

explicit pressure and skips a critical step in repairing a locomotive that contributes to an accident 

in the future). 

Ideally, railroad accident investigators would search for and identify a broad range of operator, 

supervisory, technological, and organizational (i.e., upstream workplace) factors and conditions 

that contribute to railroad accidents. Often, however, this is not the case. 

FRA investigates a variety of railroad accidents, including fatalities and other assigned accidents. 

FRA fatality investigations are thorough, but they are not necessarily systematic with respect to 

exploring possible human factors contributions. Headquarters and regionally-assigned FRA 

investigations address a range of human factors issues, but, again, they may not explore human 

factors contributing factors systematically. The U.S. railroad industry also conducts accident 

investigations on their own properties. The focus, however, is often on the crewmembers and 

those closest in time and proximity to the accident. Little, if any, examination focuses on the 

contextual factors that allowed the accident to occur. In general, the U.S. railroad industry lacks 

a cohesive theory of human error to drive accident investigation and analysis. 

In 2004, FRA sponsored the development of a preliminary concept of operations for a software 

tool that would enable railroad accident investigators (FRA, railroad, or others) to systematically 

examine human factors issues. That work was completed in 2004. That effort consisted of the 

following tasks: 

• Identify an appropriate human factors framework 

• Document the state of the practice in accident investigations 

• Develop a set of user requirements 

• Produce an initial concept of operations 

The initial concept of operations involved three components: a portable WinCE-based 

application that could be used in the field to support data collection; a desktop/laptop PC 

Windows application that could be used in a hotel room, office, or other location to support data 

analysis, reporting, and identification of corrective actions; and a centrally located server that 

would support and maintain the master accident database (see Figure 1). See Reinach, Viale, 

Wiegmann, and DeGraw, 2004, for more information on this initial effort. 

This report describes follow-on development and demonstration of a prototype software tool 

based on this earlier work. HEIST is a software program that helps accident investigators 

systematically consider a range of possible human factors contributing factors. Investigators do 

not need to be formally trained in human factors to use HEIST. HEIST is based on a wellaccepted systems theory of accident causation and human error (Reason’s Swiss Cheese model) 

and is structured around a validated human factors classification system—the Human Factors 

Analysis and Classification System (HFACS) (HFACS; Wiegmann & Shappell, 2003). HFACS 

was originally developed to address aviation accidents and mishaps. Through earlier work (see 

Reinach, Viale, Wiegmann, & DeGraw, 2004; Reinach & Viale, 2006; Viale & Reinach, 2006), 

this classification system was modified to more specifically apply to the railroad industry. 

Whereas a number of commercially available root cause analysis (RCA) software programs 

exist, as well as human error taxonomies that can be used to classify accident contributing 

factors, none use a classification system to drive data collection in the first place. One of the 
5

major benefits of HEIST is that it uses an HFACS-based taxonomy of human factors 

contributing factors to drive data collection, as well as classification. 

Figure 1. Human factors accident investigation software initial concept of operations 

HEIST is guided by a number of principles, including the following: 

• HEIST investigations are designed to shed light on what happened and why. 

• HEIST is nonpunitive. 

• Accidents/incidents are not solely caused by one event; rather, multiple factors play a role 

in each accident/incident. 

• The immediate act that precedes an accident/incident is simply the last step in a series of 

events that led to the occurrence. 

• HEIST focuses on unwinding the tape to explore all of the factors that led to the incident. 

To do this, individual, organizational, technological, and environmental factors are 

examined. Each of these factors can be, and often is, at least partly responsible for 

providing a situation conducive to the accident/incident’s occurrence. HEIST supports 

examination of all these factors. 

• HEIST can help to methodically and objectively shed light on these multiple contributing 

factors—many of which are otherwise difficult to find. 

1.2 Objective 

The objective of this program was to develop a working prototype of HEIST and demonstrate the 

tool with FRA Office of Safety stakeholders. 
6

1.3 Overall Approach 

The overall approach used to develop HEIST involved the following sequential steps: 

1. Refine the concept of operations based on feedback from FRA Office of Safety 

stakeholders. 

2. Develop a functional specification for the software. 

3. Implement the functional specification (i.e., develop the software). 

4. Debug and improve HEIST using an iterative process. 

5. Demonstrate HEIST to Office of Safety stakeholders and provide a brief user trial period 

to obtain Office of Safety feedback. 

6. Update HEIST based on Office of Safety feedback. 

1.4 Scope 

HEIST looks for active and latent contributing factors. Specifically, it probes for human factors 

contributing factors at the operator, supervisory, technological, and organizational levels, as well 

as contextual factors outside the organization, such as the regulatory and political environment. 

HEIST focuses on human factors contributions. It does not address mechanical-, signal-, 

equipment-, and track-related contributing factors, except if a human factors component applies 

to them. HEIST is designed to support accident and incident investigations, as well as close call 

and operational test failure investigations. HEIST does not currently address highway-rail grade 

crossing accidents, however, since the dynamics involved in grade crossing accidents are more 

complex, involving motorist behaviors and actions. 

1.5 Organization of the Report 

This report is organized into several sections. Section 2 discusses development of HEIST. 

Section 3 describes HEIST and the tools that make up HEIST. Section 4 discusses possible 

future directions to take with further development of HEIST. Lastly, Section 5 presents a list of 

references used in this report. The report also contains two appendices. Appendix A contains 

details on how the classification system used to support HEIST was modified from its original 

form. Appendix B contains a copy of the questions used to structure FRA Office of Safety 

feedback during the HEIST demonstration and user trial period. The report also includes a list of 

abbreviations and acronyms used throughout. 
7

2. HEIST Development 

Section 2 briefly discusses the development process used to produce HEIST. To begin, a kickoff 

meeting was held with FRA Office of Safety stakeholders. Based on feedback at this meeting 

and subsequent conversations with Office of Safety stakeholders, the initial concept of 

operations was modified. Modifications included a reduction in scope to focus on the core 

human factors data collection and analysis tools, as well as a change in hardware platform. 

HEIST was originally planned for a combination of WinCE-based handheld devices and 

laptop/desktop PCs. It was felt, however, that a better solution would be to combine the two 

capabilities into one ruggedized Tablet PC device that could be used in the field, as well as in a 

hotel room, office, or conference room. 

The next step was to develop a functional requirements specification that outlined HEIST’s 

functions and capabilities, as well as user options. This was an iterative process. Once the 

functional requirements specification was complete, the software tools were developed. Many of 

HEIST’s data collection and classification tools started as paper-based tools used in several 

previous FRA-sponsored RCA projects (Reinach & Viale, 2006; Viale & Reinach, 2006). Thus, 

HEIST development relied heavily on updating the tools to reflect lessons learned from the other 

projects and modifying the paper-based tools to become more interactive. To this end, 

significant time was spent exploring and mapping out user interactions with each tool. Section 3 

discusses each individual HEIST tool. 

Many of the tools are based on a modified version of the HFACS taxonomy, referred to as the 

HFACS-Railroad (or HFACS-RR) taxonomy. HFACS was originally modified for use in the 

railroad industry in the earlier FRA-sponsored RCA projects. See Reinach and Viale (2006) for 

details on how the original HFACS taxonomy was modified to apply to the railroad industry. 

HFACS-RR was further modified as part of the HEIST development process to ensure that the 

taxonomy, and its category definitions, could be used to support accident investigations, such as 

HEIST, and close call investigations, such as FRA’s Confidential Close Call Reporting System 

(C3RS). Since FRA sponsored both research programs, it was important that both use a single, 

underlying taxonomy or framework of human error as the basis for development. Appendix A 

discusses the modifications in detail. The new HFACS-RR taxonomy expanded the number of 

low-level HFACS-RR classification categories from 23 (original HFACS-RR) to 33. Figure 2 

presents the updated HFACS-RR taxonomy used to support HEIST data collection and 

classification. 

HEIST software was developed through an iterative process over the course of approximately 

7 months. A user manual was also developed to accompany and support HEIST. Toward the 

end of the development process, HEIST was demonstrated at FRA. FRA Office of Safety 

stakeholders were asked to experiment with HEIST for 2 weeks after the demonstration and to 

provide feedback on the tool’s capabilities and functions, as well as its usability. Appendix B 

presents a list of the user evaluation questions provided to Office of Safety stakeholders to guide 

user feedback. Subsequent to the user trial period, additional enhancements were made to 

HEIST based, in part, on FRA Office of Safety feedback during the demonstration and 

subsequent user testing period. 
8

Figure 2. HFACS-RR revised for HEIST and C3RS 
9

3. HEIST Overview and Tools 

3.1 HEIST System Overview 

HEIST was built using the .Net software development framework. It is designed to be used on a 

ruggedized Tablet PC that can be used in the field, but it can operate on any other computer 

running Microsoft Windows XP (i.e., another laptop or desktop PC). HEIST can be used in the 

field and/or an office environment to collect, analyze, classify, and report on accidents, incidents, 

and close calls. Although not implemented in its current form, HEIST’s concept of operations 

includes transmission of accident/incident/close call data to a centralized accident database. 

Figure 3 shows a schematic of the HEIST concept of operations. 

HEIST is comprised of a number of individual tools—some are interactive while others are 

printable documents. Individual tools, based on the HFACS-RR taxonomy, support data 

collection, data classification, and reporting. Currently, HEIST does not support the 

identification of contributing factors (i.e., analysis). Since identification of contributing factors 

is still a combination of art and science, the design philosophy behind HEIST is to support an 

investigator in collecting information and classifying contributing factors, but the actual 

determination of what contributed to an accident is still up to the investigator. Furthermore, 

HEIST currently does not support corrective action identification. HEIST is intended to 

complement existing methods used by the FRA inspector in conducting accident/incident 

investigations. 

Figure 3. HEIST concept 
10

When launched, HEIST offers the user a number of options. A user may start a new 

investigation or resume an ongoing investigation. He/she may review various online data 

collection aids to support the collection of information relevant to the investigation, classify 

contributing factors for an accident, generate a report, or practice using the human factors 

taxonomy to classify contributing factors. The following sections, organized by HEIST function, 

discuss each of these options. 

3.2 Data Collection Tools 

HEIST allows investigators to enter basic descriptive information related to an accident/incident 

and further provides a number of tools designed to aid the investigator in considering and 

collecting relevant human factors information at each level of HFACS-RR. 

Accident/incident summary form. To begin, HEIST allows investigators to create a new 

accident/incident file and enter basic top-level descriptive information about the event, such as 

date and location of the accident/incident; personnel, equipment, and railroads involved; nature 

of the occurrence; method of operation; and track type; as well as information related to 

environmental conditions. Figure 4 provides a screen shot of the HEIST accident/incident 

summary form. 

Figure 4. HEIST accident/incident summary form page 

In addition to allowing descriptive input, HEIST offers a number of data collection tools that 

serve as a reference for investigators, providing a range of human factors issues to consider when 

collecting information about the accident/incident. These tools are designed to aid investigators 

in considering human factors at the operator, supervisory, technological, and organizational 

levels, as well as contextual factors outside the organization, such as the regulatory and political 

environment. As each accident/incident is different, these tools are not intended to be 
11

exhaustive, but rather they are designed to support the investigator in considering and collecting 

basic relevant human factors information at each level. It is ultimately left to the discretion of 

the investigator to determine which questions and data are most relevant to the accident/incident. 

A description of each of these tools follows. 

Interview guides. HEIST contains three separate interview guides (i.e., sets of interview 

questions): an operator interview guide, a supervisory personnel interview guide, and an upper 

level manager interview guide. Interview questions are organized around the five levels of the 

HFACS-RR human factors taxonomy. A HEIST user chooses only those questions that are 

relevant to the particular investigation. 

Checklist of things to consider. The checklist includes a number of questions and suggestions 

that may aid investigators during the data collection process. The list of items includes questions 

for the investigator to think about, as well as physical items that he/she may want to review as 

part of the data collection part of the investigation (e.g., training records and railroad operating 

rules and procedures). Checklist items are organized around five main topics: task-related 

information, operator information, equipment/environment/operations information, 

supervision/management information, and other information. Although the checklist is not 

organized around the HFACS-RR human factors taxonomy like the interview guides, it does 

address sources of information relevant to all five levels of the HFACS-RR taxonomy. The 

checklist is a broad-based list addressing a variety of possible accidents and scenarios, but it is 

not exhaustive. An inspector can use this checklist to help identify, prioritize, and examine 

relevant information as part of the investigation. This list can be viewed as a PDF or in an 

editable format. 

Data collection aid. This data collection aid is an interactive diagram of the human factors 

taxonomy used in HEIST. An investigator may mouse over any category to obtain a popup 

definition of that category (see Figure 5). In addition, clicking on any lower level category 

(those enclosed in a dashed line) opens a window with recommended data and information to 

consider and collect during the investigation. The data collection aid is designed with the 

HFACS-RR taxonomy as its backbone. Investigators can use the aid to review HFACS-RR 

categories, look at HFACS-RR definitions, and review a list of accident/incident information 

sources specific to each HFACS-RR category. 

Human factors taxonomy diagram. The human factors taxonomy diagram is a printable diagram 

of the HFACS-RR taxonomy. The diagram can be viewed as a PDF or in an editable format. 

Human factors taxonomy definitions. Definitions for each HFACS-RR category are provided 

along with examples. Definitions draw heavily from Wiegmann and Shappell’s A Human Error 

Approach to Aviation Accident Analysis (2003) and Eurocontrol’s Systemic Occurrence Analysis 

Methodology (SOAM, 2005). Definitions can be viewed as a PDF or in an editable format. 
12

Figure 5. HEIST data collection aid (with mouse-over definition shown) 

3.3 Data Classification Tools 

HEIST contains several tools to aid investigators in using the HFACS-RR taxonomy to classify 

contributing factors once they have been identified. 

HEIST Practice. This tool serves as a training aid to enable users to become familiar with the 

HFACS-RR taxonomy and categories by providing them with an opportunity to practice 

classifying contributing factors from National Transportation Safety Board (NTSB) accident 

investigations. The practice module contains synopses and selected contributing factors from 

three NTSB railroad accident investigations. For each accident investigation, the practice tool 

presents the user with the synopsis followed by a list of the contributing factors. The user must 

map each NTSB contributing factor to an HFACS-RR category. To use the tool, a user first 

selects a contributing factor from the list of available contributing factors, and then he/she 

selects, from an interactive diagram, the HFACS-RR category that he/she feels best classifies the 

contributing factor. An investigator can then check the accuracy of his/her classification 

decision against answers that are provided. If an investigator makes an incorrect classification, 

constructive feedback is provided to shepherd the user to the correct classification. Figure 6 

provides a screen shot of the HEIST practice tool. 
13

Figure 6. Screen shot of HEIST practice tool 

HEIST Analysis Tool (HAT). HAT, despite its name, is a classification tool designed to enable 

investigators to enter and classify contributing factors they have identified based on the HFACSRR human factors taxonomy. HAT functions similarly to the HEIST practice tool: users select a 

contributing factor from those they have identified and then use the interactive taxonomy to 

select the most appropriate HFACS-RR category. A help function is included within HAT to 

provide interactive assistance in classifying contributing factors. Within the help function, a user 

is guided to the most appropriate classification based on his/her answers to a series of questions 

(see Figure 7). Once a user has classified the contributing factor, HAT records the classification 

and prompts the investigator to classify another contributing factor. Users repeat this process 

until all contributing factors have been classified. 
14

Figure 7. HAT help function 

3.4 Reporting Tools 

HEIST can generate basic investigation reports. Reports include any or all of the following three 

sections: descriptive information (e.g., time of day, type of occurrence, method of operation); 

illustrations, photos, and diagrams; and results of the HFACS-RR analysis. Reports can be 

viewed online and printed, and their contents can be copied and pasted into a word processor or 

other editable format. 

3.5 Software Requirements 

HEIST runs on computers with Windows XP (Pro or Tablet) Service Pack 2 installed. The host 

computer should have at least a 500 MHz Pentium III class processor or better, 512 MB of 

RAM, and at least 700 MB of hard disk space. Further information on HEIST’s software 

components and the installation procedure are included with the HEIST installation CD and 

discussed in the user manual. 
15

4. Future Directions 

HEIST is currently in what can be considered its alpha (as opposed to a beta or complete) 

version. Although it is robust enough and has enough features to be used in its current form, 

additional enhancements and a field test with FRA Office of Safety inspectors would 

significantly add value to HEIST. Section 4.1 discusses some possible enhancements to improve 

HEIST, while Section 4.2 discusses possible next steps to implement enhancements to HEIST 

and conduct a field test with intended users of HEIST. 

4.1 Future Enhancements 

Proposed enhancements to HEIST address increased functionality, as well as improved usability, 

and are briefly discussed in the following sections. This list is not an exhaustive list. Rather, 

this list is the starting point for all possible improvements. Further discussion with FRA and 

other users is suggested to ensure that the right enhancements are implemented, including 

enhancements not identified below but that may be critical to FRA and other users. 

4.1.1 RCA Tool 

Currently, by design, HEIST includes data collection and data classification tools but not an 

analysis tool. The reason for this omission is that each inspector may have his/her own method 

of analyzing accident data to identify contributing factors. Because this process is part art and 

part science, the design of HEIST defers to the user. It may be valuable, however, to provide an 

RCA tool to aid inspectors who do not necessarily have their own analysis approach or who want 

to explore another approach for identifying accident contributing factors. The tool could be 

optional—available for those who wish to use it to support their investigation, but not required, 

in case some inspectors prefer to use their own approach to identify contributing factors. One 

type of tool may be a simple five-why approach, where the tool may guide a user to repeatedly 

ask (five times) why a certain action or event occurred. This and other RCA approaches should 

be examined to identify the most suitable method to incorporate into HEIST to support railroad 

accident investigations. 

4.1.2 Timeline Tool 

A timeline tool, such as a multilinear events sequencing (MES) diagram, can aid investigators in 

building a unified timeline of events for multiple parties involved in an accident/incident. The 

MES diagram is a single, chronologically arranged depiction of all events relating to the 

accident/incident and divided by each operator involved. A timeline tool aids the investigator in 

sorting out the events that occurred over both large and very small periods of time, and this tool 

can aid the investigator in ensuring that he/she has collected enough information about an 

accident (i.e., if the timeline reveals a gap for one or more individuals for a period of time, the 

investigator may determine that he/she needs to collect more information). 
16

4.1.3 Digital Audio Capture 

HEIST can be equipped with a digital audio recorder embedded in the Tablet PC or other host 

computer to enable inspectors to use HEIST to conveniently record and play back interviews 

with operators, supervisors, and/or officers. 

4.1.4 Freehand Sketch Capture 

Currently, HEIST allows a user to import or add electronic images already stored on the host 

computer. If desirable, HEIST can be designed to include an application that would allow an 

inspector to freehand draw a diagram or other figure/picture. A voice-over capability or 

properties capability could also be explored for this capability, so that an inspector could include 

annotated, descriptive information about the diagram that can be used for later analysis or for 

conveying information to another party, such as a supervisor. 

4.1.5 Regulatory, Railroad, and Other Reference Materials 

It may be valuable for FRA inspectors to use HEIST as a repository for, or have access to, 

electronic, searchable versions of various regulatory, State, and railroad-specific regulations, 

rules, and operating practices to aid the inspector in conducting an investigation. Candidate 

reference materials include: FRA regulations, equipment specifications (e.g., Universal Machine 

Language Equipment Register), and railroad materials, such as track diagrams, time tables, rule 

books, and current bulletins/orders/special instructions. 

4.1.6 Automated Railroad Data Download 

This capability would involve downloading railroad data related to the accident to HEIST. Data 

may include locomotive or remote control locomotive event recorder data, computer-aided 

dispatch data, track diagram information, and automatic equipment identification data. It is 

necessary to determine first whether or not data are available from railroads in an electronic 

format and second whether or not these data can be downloaded. 

4.1.7 Work Schedule Calculator 

A work schedule calculator can help investigators predict operator alertness as a possible 

contributing factor based on work schedule data and sleep habit information. Dr. Steven Hursh 

has created a stand-alone operator alertness calculator based on his Sleep, Activity, Fatigue, and 

Task Effectiveness model (Hursh et al., 2004). FRA has been exploring the use of this tool to 

aid their accident investigations. Dr. Hursh’s work schedule tool could be embedded within, or 

linked to, HEIST. Dr. Hursh’s work schedule and sleep habits data collection instrument also 

would need to be incorporated into HEIST for use with the work schedule tool. 

4.1.8 Central Database 

The current version of HEIST sets up and uses a database that is located on the computer on 

which HEIST is installed. To optimize the value of HEIST, it should have a centrally located 

database that HEIST users can access remotely to upload and download data. This is because the 

real utility of HEIST will be realized only after a significant amount of data have been collected 
17

over time and input into one master database. Then reliable human factors data analyses can be 

performed on the HEIST-enhanced accident data. 

4.2 Possible Next Steps 

Briefly, a logical set of next steps to advance HEIST to a beta version may include the following 

tasks: 

1. Revise HEIST to include a selection of enhancements based on input from FRA Office of 

Safety stakeholders. 

2. Update the user manual. 

3. Conduct a field test with regional Office of Safety inspectors. Office of Safety 

stakeholder input will be critical in assuring participation by FRA regions, as well as 

identifying one or more locations to conduct the field test. 

4. Revise HEIST and the user manual based on field-test participant (i.e., HEIST user) 

feedback. 

19

5. References 

European Organisation for the Safety of Air Navigation (Eurocontrol). (2005). Guidelines on 

the systematic occurrence analysis methodology (SOAM), EAM 2 / GUI 8. Eurocontrol: 

Brussels, Belgium. Retrieved March 22, 2007, from 

www.eurocontrol.int/src/gallery/content/public/documents/deliverables/esarr2_awareness_pa

ckage/eam2_gui8_e10_ri_web.pdf

Hursh, S., Redmond, D., Johnson, M., Thorne, D., Belenky, G., Balkin, T., Storm, W., Miller, J. 

& Eddy, D. (2004). Fatigue Models for Applied Research in Warfighting. Aviation, Space 

and Environmental Medicine, 75, 3, A44-A53. 

Reason, J. (1990). Human Error. New York: Cambridge University Press. 

Reason, J. (1997). Managing the risks of organizational accidents. Aldershot: Ashgate 

Publishing Ltd. 

Reinach, S., & Viale, A. (2006). Human factors root cause analysis of accidents/incidents 

involving remote control locomotive operations. (DOT/FRA/ORD-06/05). Washington, DC: 

Federal Railroad Administration. 

Reinach, S., Viale, A., Wiegmann, D., & DeGraw, K. (2004). Development of a portable 

human error incident investigation tool for the railroad industry. SBIR Phase I final report 

submitted to U.S. Federal Railroad Administration. Contract No. DTRS57-04-C-10027. 

Scarborough, A., & Pounds, J. (2001). Retrospective human factors analysis of ATC 

operational errors. Paper presented at the 11th International Symposium on Aviation 

Psychology, Columbus, OH. 

Viale, A., & Reinach, S. (2006). A pilot examination of a joint railroad management-labor 

approach to root cause analysis of accidents, incidents, and close calls in a 

diesel and car repair shop environment. (DOT/FRA/ORD-06/24). Washington, DC: 

Federal Railroad Administration. 

Wiegmann, D., & Shappell, S. (2003). A human error approach to aviation accident analysis: 

The human factors analysis and classification system. Aldershot: Ashgate Publishing Ltd. 

21

Appendix A. 

HFACS and HFACS-RR 

Appendix A illustrates the transformation that HFACS has undergone to make it more suitable 

for application to the railroad industry. This appendix is organized into three sections. The first 

section discusses Wiegmann and Shappell’s (2003) original HFACS taxonomy. The second 

section discusses the first of two rounds of modifications that were made to HFACS, the result of 

which was called HFACS-RR. The third and final section discusses the most recent 

modifications that were made to HFACS-RR to integrate the needs of the HEIST program and 

the C3RS program, both sponsored by FRA. 

A.1 HFACS 

HFACS (Wiegmann & Shappell, 2003) has its basis in Reason’s generic error modeling system 

and Swiss Cheese model of accident causation (Reason, 1990). The Swiss Cheese model depicts 

accidents as arising from holes in an organization’s defenses at various levels of the 

organization, beginning with the operator and working all the way up to organizational decisions 

and conditions. Active failures by the operator combine with latent conditions or factors 

upstream in the organization to lead to an accident (or incident or close call). Accidents (and 

incidents and close calls) occur, therefore, when all of the active and latent factors (i.e., holes) 

line up to allow accident energy (depicted as a straight line) to penetrate these various 

organizational levels. An organization’s defenses and barriers can, however, prohibit the 

alignment of active and latent factors and conditions, thereby preventing accidents (and incidents 

and close calls). 

Wiegmann and Shappell (2003) originally developed HFACS as a classification system to help 

analyze U.S. naval aviation mishaps. HFACS was subsequently broadened to also include 

commercial and general aviation domains. HFACS models error at four different levels, 

beginning with the operator and moving upward in the organization. The four levels mirror 

Reason’s Swiss Cheese model of error. The four levels of HFACS are unsafe acts (Reason’s 

active failures—the operator activity that occurs closest in time and space to an accident, 

incident, or close call), preconditions for unsafe acts, unsafe supervision, and organizational 

influences. These latter three levels relate to Reason’s latent factors or conditions, and they often 

exist for years before they contribute to an accident, incident, or close call. For each level, 

Wiegmann and Shappell (2003) identified a number of second-level categories. Some secondlevel categories divide further into third-level categories. A total of 19 unique categories of 

contributing factors exist. Figure A-1 illustrates the structure of the HFACS taxonomy, 

including the nesting style of different category levels. HFACS applies Reason’s Swiss Cheese 

model of human error to an accident, incident, or close call classification system and provides a 

theory-driven structure to accident, incident, and close call investigation findings. For a 

discussion of each unique category’s definitions, see Wiegmann and Shappell (2003). 
22

Figure A-1. Original HFACS taxonomy (Wiegmann & Shappell, 2003) 

The use of a theoretically-driven RCA approach ensures that the accident, incident, or close call 

contributing factors identified during an investigation go beyond what happened to why an error 

occurred. Furthermore, such an approach allows for identifying the relationship between 

contributing factors more readily (for example, some types of errors may be linked to other types 

of contributing factors). Classifying errors based on their underlying theoretical nature enables 

identifying global trends across error forms, which on the surface may appear totally different. 

Consequently, and perhaps most importantly, one can identify corrective actions more readily to 

prevent errors and accidents, incidents, and close calls from recurring, since the data collected 
23

during the investigation highlight the underlying systemic problems that contributed to the events 

in the first place. 

HFACS primarily provides the means to analyze data available from existing accident, incident, 

and close call investigations. HFACS is also a methodology, however, that can guide accident, 

incident, and close call investigations and support collection of human factors-related 

information. In fact, some Federal agencies, such as the U.S. Coast Guard and the U.S. 

Department of Defense, are now experimenting with the use of HFACS to support accident, 

incident, and close call investigations, as well as analysis (Wiegmann & Shappell, 2003; A. 

Carvalhais, personal communication, October 11, 2005). 

The initial development and application of HFACS, however, was for the aviation domain. As a 

result, it was necessary to make minor changes to HFACS to optimize its relevancy to the 

railroad industry. The following section discusses these changes. 

A.2 HFACS-RR 

To ensure the best fit between HFACS and the railroad industry and to increase its acceptance 

within the railroad industry, several changes were made to HFACS. The overall tree structure of 

HFACS remained. The modified HFACS taxonomy was simply called HFACS-RR or HFACSRailroad. An advantage of the original HFACS is that it uses generic terms and descriptors that 

are applicable to a range of industries and activities. Although others have made minor 

alterations to HFACS to suit their particular application, for example, to address air traffic 

control (HFACS-ATC; Scarborough & Pounds, 2001) and military activities (Canadian Armed 

Forces or CF-HFACS; see Wiegmann & Shappell, 2003), most of the original HFACS taxonomy 

remains in HFACS-RR to preserve the original structure. This facilitates future comparisons 

between data collected using HFACS-RR and HFACS-based accident, incident, and close call 

analyses in other industries. 

To begin, the names of the top HFACS level were changed to have a more neutral tone. For 

example, unsafe acts of operators became operator acts. Table A-1 presents the original and 

modified terms. 

Table A-1. Original HFACS and new HFACS-RR top-level categories 

Original HFACS Top-Level Modified HFACS-RR Top-Level 

Category Category

Unsafe acts of operators Operator acts 

Preconditions for unsafe acts Preconditions for operator acts 

Unsafe supervision Supervisory factors 

Organizational influences Organizational factors 

A new fifth level named outside factors was also added to the HFACS-RR taxonomy. Outside 

factors include the regulatory environment and the economic/political/social/legal1 environment 

 

1

 The legal environment includes other-than-regulatory laws that affect railroad operations. 
24

in which railroads operate. Outside factors cover those influences outside the railroad or 

organization that affect how the organization operates and its decisions. 

Other changes to the original HFACS taxonomy (and contained in the new HFACS-RR 

taxonomy) include the following: 

• Replaced the term violations with the term contraventions throughout the HFACS-RR 

taxonomy to avoid stigma and biases associated with violations. Violations in the 

railroad industry are often associated strictly with (operating, safety) rules. 

Contraventions are generally more shortcutting and rule bending, and they may not 

necessarily be tied to violating a specific rule. 

• Added a new subcategory under operator acts/contraventions called acts of sabotage. 

Acts of sabotage are related to the investigation only when the act is in response to a 

problematic organizational factor that is identified. 

• Changed the organizational practices category to organizational practices and 

procedures.2

 

• Added fourth subcategory under the organizational factors category called organizational 

contraventions. This subcategory addresses upper level management and executive 

contraventions and short-cutting of existing organizational (i.e., internal) procedures or 

processes. This subcategory also addresses externally imposed municipal, State, and 

Federal regulations. This category parallels supervisory contraventions and 

contraventions of the operators themselves. 

Figure A-2 presents the new HFACS-RR taxonomy with these modifications incorporated. The 

new HFACS-RR taxonomy contains a total of 23 unique categories of accident, incident, and 

close call contributing factors. 

 

2

 Wiegmann and Shappell (2003) originally discuss procedures under the organizational influences/organizational 

process subcategory. The authors changed procedures to practices and procedures in the HFACS-RR taxonomy 

since many of the activities undertaken in a railroad switching yard environment involve practices (more broad 

methods of operation), rather than procedures, which are more specifically prescribed methods. 
25

Figure A-2. HFACS-RR 

A.3 HFACS-RR Update 

Most recently, HFACS-RR underwent another round of modifications, this time to accommodate 

the needs of the C3RS program. The goal was for both HEIST and C3RS to be based upon, and 

use, the same underlying human factors taxonomy. Since it was desirable to maintain the 

HFACS-RR structure, HEIST researchers worked with the C3RS project manager to update the 

HFACS-RR taxonomy specifically to accommodate elements of a second human factors 

taxonomy, Eurocontrol’s Systemic Occurrence Analysis Methodology (SOAM; 2005). The 

update also involved improved definitions for each HFACS-RR category. 
26

The process involved the following steps: 

• Researchers reviewed SOAM and mapped each SOAM category to an existing HFACSRR category. Where researchers felt that the SOAM category was not explicitly covered 

by the HFACS-RR definition, the SOAM category was added to the appropriate HFACSRR category definition, often as an example. Occasionally, the wording of the SOAM 

category was changed when it was felt that the railroad industry would better understand 

the new wording (like HFACS, SOAM was originally developed for the aviation 

industry). 

• Researchers were unable to incorporate six SOAM categories into HFACS-RR due to a 

lack of full understanding of their meaning, or, in one case (error proneness), researchers 

felt that it was not a meaningful or useful category to include. The six unused SOAM 

categories were: poor signal/noise ratio, poor access to job, high-risk target, skill 

overcomes danger, error proneness, and strong motor programs (frequency bias, 

similarity bias). 

• Researchers added one new HFACS-RR category based on SOAM, which was change 

management. It was added as a second-level category under organizational factors 

because researchers felt that change management included a unique set of issues not 

otherwise captured in the existing HFACS-RR taxonomy. 

• An additional level of categories was added to the following five HFACS-RR categories 

based on Wiegmann and Shappell’s (2003) original HFACS taxonomy and definitions: 

o Skill-based errors were subcategorized into attention failures, memory failures, 

and technique errors. 

o Decision errors were subcategorized into procedural errors, poor choices, and 

problem-solving errors. 

o Resource management was subcategorized into human resources, 

equipment/facility resources, and monetary/budget resources. 

o Organizational climate was subcategorized into organizational structure, 

organizational policies, and organizational culture. 

o Organizational process was subcategorized into organizational operations, 

organizational practices and procedures, and organizational oversight. 

• The following changes were made to HFACS-RR category names: 

o Added “context” in parentheses in the preconditions for operator acts category. 

o Added “safety” in parentheses in the organizational oversight category. 

• The following HFACS-RR category definitions were modified: 

o Moved accident investigations from organizational policies to organizational 

(safety) oversight. 

o Changed crew scheduling to rostering and moved from planned inappropriate 

operations to human resources. Although seniority is locally based, establishment 

of work schedules and crew pairing is often carried out by a centrally located or 
headquarters-based department, not the local supervisors who plan train 

movements and operations. 

o Moved signage from physical environment to technological environment. 

o Removed the organizational contraventions category. Now organizational 

contraventions are presented as examples of, and part of the definition of, 

organizational culture. Contraventions/violations, which imply individual 

behavior, make sense to identify at lower levels where people operate within the 

context of an organization. At the organizational level, however, it is more 

meaningful to focus on the organizational environment and its culture, practices 

and procedures, and structure, rather than on contraventions/violations, which 

strongly suggest the actions of individuals. 

• Lastly, whereas HEIST refers to deviations from rules and operating procedures as 

contraventions, the C3RS program will use the term violations. This change is nominal 

only. 

Figure A-3 illustrates the new HFACS-RR taxonomy. The updated HFACS-RR taxonomy has 

33 unique categories. 

27
28

Figure A-3. Updated HFACS-RR taxonomy 
29

Appendix B. 

User Evaluation Form 

Appendix B contains a copy of the user evaluation questions distributed to FRA stakeholders to 

help structure and obtain their feedback after using HEIST. 

1. Please identify any problems (i.e., bugs, glitches, unforeseen software faults or errors) 

you found while using HEIST. Please provide, as best you can, (1) the circumstances 

under which you encountered the problem, as well as (2) a full description of the 

problem. Feel free to use a separate document to list problems you encountered. 

2. What changes to HEIST would you suggest? Consider the interface and how you used 

the software when answering this question. Also consider the quantity of instructions 

provided throughout HEIST and the clarity of the instructions. Please be as detailed as 

possible. Feel free to use a separate document to list suggested changes. 

3. What enhancements, such as future functions and features, would you like to see in future

versions of HEIST? Please be as detailed as possible. Feel free to use a separate 

document to list these enhancements. 

4. How easy was it to use HEIST? (Check the most appropriate description in the table 

below.) 

Very easy to use 

Mostly easy to use 

Moderately easy to use 

Moderately hard to use 

Mostly hard to use 

Very hard to use 

5. What suggestions do you have to make HEIST easier to use? 
30

6. How helpful was the user manual? (Check the most appropriate description in the table 

below.) 

Very easy to use 

Mostly easy to use 

Moderately easy to use 

Moderately hard to use 

Mostly hard to use 

Very hard to use 

7. What suggestions do you have to make the user manual easier to use? Please be specific. 

8. How useful do you feel HEIST would be to the Office of Safety and the railroad industry 

as a whole? (Check the most appropriate description in the table below.) 

9. Please share any additional feedback you have about the current design of HEIST. 

 Very useful 

 Moderately useful 

 Not useful 

--##-- 
31

Abbreviations and Acronyms 

C3RS Confidential Close Call Reporting Systems 

FRA Federal Railroad Administration 

HAT HEIST Analysis Tool 

HEIST Human Error Investigation Software Tool 

HFACS Human Factors Analysis and Classification System 

HFACS-RR Human Factors Analysis and Classification System-Railroad 

MES multilinear events sequencing 

NTSB National Transportation Safety Board 

RCA root cause analysis 

SOAM Systemic Occurrence Analysis Methodology