Critical Review and Redesign of a Petroleum Industry Accident/Incident Reporting System

John J. Yandziak III, Osmar de Lima, Monique Verboonen, Jos Orlando Gomes, and Stephanie Guerlain, Senior Member, IEEE

Abstract Petroleum transportation accidents often cause losses of millions of dollars and take human lives. SIGA (Integrated Anomaly Management System) is an accident/incident reporting system that was designed by the largest petroleum transportation company in Brazil, to help remediate these accidents. SIGAs function is to track reported accidents and their cost, determine the cause of these accidents, identify solutions, communicate accidents to relative parties, document the passing of information, and protect the company and employees from litigation. While the existing system administers the workflow of accident remediation, it lacks the functionality necessary for holistic posterior analysis. Such analysis is critical and would enable the examination of all reports to find patterns. This paper proposes a software solution to track large quantitative data sets composed from incident reports in order to preemptively identify potential hazards and recommend appropriate actions to eliminate future hazards before they occur.

I. INTRODUCTION With daily processes that involve the exploration, excavation, transportation, and distribution of highly combustible chemical products, the petroleum industry is an extremely high-risk industry in terms of the likelihood of large-scale industrial accidents and the potential severity of the economic and social harms that these accidents can inflict. In order to prevent future accidents, the causes of previous accidents must be accurately determined, corrective actions must be put into effect, and a reliable hazard detection system must be in place to focus company safety efforts in the areas where hazard remediation can have the greatest effect on future likelihood and gravity (together the criticality) of industrial accidents [1]. This project provides an analytical tool for Brazils leading petroleum transportation company to identify
Manuscript received April 15, 2006. This work was supported in part by the Coordenao de Aperfeioamento de Pessoal de Nvel Superior (CAPES)/Fund for the Improvement of Secondary Education (FIPSE) Grant for the US-Brazil Cognitive Systems Engineering Program Stephanie Guerlain is with the Systems and Information Engineering Department, University of Virginia, Charlottesville, VA 22904-4747 USA, (corresponding author: phone: 434-924-4438; fax: 434-982-2972; e-mail: guerlain@virginia.edu). John J. Yandziak III is with the University of Virginia, Charlottesville, VA 22903 USA (e-mail: jyandziak@virginia.edu). Osmar de Lima, Monique Verboonen and Jos Orlando Gomes are with the Universidade Federal do Rio de Janeiro, Rio de Janeiro, RJ, Brazil . (e-mails: osmar@virginia.edu, mv4t@virginia.edu, joseorlando@nce.ufrj.br respectively).

emerging high-risk trends, culled from a database of accident and incident reports, in order to identify likely causes of future accidents. . The current system is entitled Sistema Integrada de Gesto de Anomalias (SIGA)translated from Portuguese into Integrated Anomaly Management System. SIGA is one of many examples of an Accident/Incident Reporting Systemsafety information systems utilized by large companies to monitor, administer, and analyze the large amount of descriptive data obtained from witness accident and incident reports. (Experts typically refer to events that actually occurred and caused some form of harm as accidents, while an incident, as defined is a near-miss, which could have resulted in a negative occurence, but did not. ) [1]. The system has been in existence since 2002, and since its creation has registered over 10,000 reports. [2] This project seeks to redesign the current SIGA Accident/Incident Information System in order to provide the following additional features: 1) A new witness reporting form that allows for more accurate, robust incident accounts that are more readily analyzed in a quantitative manner 2) A relational database to keep track of the resulting large amounts of quantitative data, and 3) A filtering and visualization software that enables users to effectively confront the data overload problem in order to identify critical areas within the company where safety resources (both human and financial) can be most effectively leveraged to reduce likelihood and severity of future accidents. II. ACCIDENT/INCIDENT REPORTING SYSTEMS Accident/Incident Reporting Systems are so crucial to hazard management programs in high-risk companies that regulatory agencies have begun to require, standardize, and monitor their use in certain industries. The Occupational Safety and Health Administration (OSHA), under the U.S. Department of Labor, publishes safety standards for both general industry as well as specific industries, including the petroleum industry [3]. OSHA requires accident reporting and investigation for all regulated industries, and, for the petroleum industry specifically, the administration also mandates collection of incident reports in addition to accident reports, through OSHA rule 29 CFR1910.119 [1].

Many systems still do not include incidents in their reporting systems, only accidentsfor example, SIGA did not include them until September 2005 [2]. However, any effective safety information system should consider the inclusion of incident gathering as a component due to its many advantages, particularly those in quantities of data collected. Reason considers incidents as free lessons, primarily for three reasons [4]: 1.) They provide insight into how small defensive failures add up to large disasters, 2.) They occur more frequently than accidents, yield numbers required for penetrating qualitative analysis, 3.) They provide a powerful reminder of system hazards to communicate to top-level management In high-risk industries, where potential hazard consequences can be severe, incidents produce the extra amount of data required obtain a clear picture of potential hazards and their underlying causes, whose elimination is the primary goal of these systems. III. CRITICAL ANALYSIS OF EXISTING SYSTEM A. Description of Existing System The system under review, SIGA, is operated and maintained by the Health, Safety, and Environment department of Brazils leading Petroleum Company. This Accident/Incident Information System solution is administrated entirely through Lotus Notes, a commercially available client-server collaborative software system. The current SIGA design is used primarily to administrate the work flow involved with the submission, analysis, and subsequent remediation of an accident or incident report. Access to the system is granted to all employees of the large petroleum provider, as well as all subcontractors currently participating in a project with the petroleum provider. System administrators grant access to SIGA only after successful completion of a short online training program. The wide majority of the SIGA system users are witnesses, who submit an initial report including the details of their own personal account. Once a witness report is submitted, an administrator reviews the report for inaccuracies or missing information, and then refers the report to the appropriate accident analyst. Typically, the analyst is an employee within the Health, Safety and Environment department with a specialization that is related to the referred reports subject matter who then analyzes the cause of the event and recommends corrective actions. From there, agency managers take on responsibility for actions recommended by the supervisor and sign off on whether or not actions have been completed to satisfaction. Finally, after all recommended actions are completed, the entire report is forwarded to the final evaluator for his or her approval. If the reported hazard is not deemed sufficiently corrected after the final evaluation,

the report is re-entered into the system, and the process starts over from the analysis stage. Each of the five different user types participates in its own respective stage of the report remediation process. Witnesses conduct registration of the report; the accident analysts create recommendations in the approval stage; the agency managers administer implementation of recommended actions; and, the final evaluator oversees the evaluation stage. The bulk of this critical review and redesign will focus on the registration stage, focusing on how the information is gathered and organized, as opposed to the other four stages which serve largely administrative functions. B. Suggested Improvements for Witness Reporting Much of the responsibility of information quality falls on the witness, although often they are not qualified or willing to produce all needed information. While, typically, filling in such standard fields as location, date, descriptive event details, and his or her own unique employee identification number causes little confusion, the form requires additional analysis beyond basic reporting that implements the users subjective organization and evaluation abilities. These additional fields include anomaly type, used for organizational purposes, key words for facilitation of future system searches, possible consequences of the reported situation, and, finally, fields to evaluate the gravity, likelihood, and incidence of the event. The current options available to the user for anomaly typeunexpected result, operational failure, accident, accident with injury, abnormal occurrence, danger, nonconformity, 3rd party complaint, and otherare vague and difficult to distinguish, and a new set of categories must be developed where each category is uniquely meaningful. Key words are best left as subjective entries, though we encourage the entry of as much relative words as possible during report registration in order to encourage more relational connections when conducting any subsequent key word searches. Possible consequences should be limited to a set number of options in order to produce more matching between separate reports and less confusion in reporting. The gravity option is limited to a choice between large and small, the likelihood limited to real or potential, and the incidence to initial or reoccurring. Though the witness may, at times, not be fully qualified to make an accurate evaluation, if s/he can only distinguish between two levels of granularity, the information provided is insufficient to conduct any type of filtration. To quantitatively evaluate the likelihood of a potential hazard, Roland has suggested a 1-5 scale corresponding to frequent, probable, occasional, remote, and improbable [5]. Likewise, following the Department of Defenses hazard-assessment matrix example, severity can be evaluated on a 1-4 scale representing catastrophic, critical, marginal, and negligible. The multiple of these two quantitative measures

forms a criticality variable, an excellent quantitative indicator for the remediative priority of a particular hazard [6]. Also, there currently exists no functionality to allow for multiple witness reports of the same event. One witness is often not willing, for fear of receiving blame, or not able, for lack of situational awareness, to provide a comprehensive account of the witnessed event [4]. A more accurate account of any event should include multiple perspectives blended into one holistic account that blends characteristics from each. IV. PROPOSED SOLUTION QUANTITATIVE
DATA

POPULATING A RELATIONAL DATABASE LINKED TO DATA VISUALIZATION SOFTWARE

The following sections describe the components of our prototype for an improved SIGA Accident/Incident Information System. A. Quantitative Data Population Creating a New Witness Form The previous form and its vague queries that were not conducive to quantitative analysis are now replaced by new fields that require more specific information, either through the use of pull-down menus with limited options or through quantitative evaluation scales with a greater granularity than before.

Anomaly type has been changed to a pull-down menu consisting of eight optionshardware, design, maintenance management, procedures, error-enforcing conditions, training, and defenses adopted from the 11 General Failure Types used by Royal/Shell Group in Tripod-Delta, their own petroleum industry accident/incident information system [8]. For possible consequences, we created the following seven categories (from which the user can choose one or more): injury, death, financial loss, unsafe company culture, damage to organizational reputation, environmental harm, and damage to organizational property. As mentioned before likelihood had its scale changed from real and potential to a 1-5 scale (frequent, probable, occasional, remote, and improbable) and severity changed from high and low to a 1-4 scale (catastrophic, critical, marginal, and negligible). In a similar fashion incidence was modified from initial or reoccurring to first time, second time, third time, or more than three times. This registration stage will also identify if the values entered in the new report match any existent report. If it doesnt match any other report the ball remains green, otherwise it changes to red (see Figure 1). The form also shows the number of reports that match.

Figure 1 Proposed Registration Form for Witness Report

B. Relational Database Organizational Structure This section will describe the conceptual model of our proposed relational database. A conceptual model depicts the structure of the system without the restriction of specifying certain technologies to implement for the proposed solution [9]. Much of this has to do with the processing of Relatrio de Tratamento de Anomalias (RTAs)translated from Portuguese to mean Anomaly Treatment Report, this is the term used to describe all data related to the registration, analysis, approval,

implementation, and evaluation of a individual accident/incident report Any person with access to the system who has a key can open a RTA report. Usually the witness of the accident/incident opens the RTA. When the RTA is opened the key of that person is associated to the report. The registration section of the report must be fulfilled and than it can be either analyzed by the person who registered the report or sent to another person who is going to analyze it. In the Registration section, information about the anomalies is provided, such as: certification scope, managing agency, anomaly type, identification method, location of anomaly

occurrence, key word to be used for future search, anomaly gravity, anomaly likelihood (1-5), anomaly severity (1-4), anomaly criticality (1-20), incidence, date and time of occurrence, possible consequences, and a narrative description immediate corrective actions taken at the scene. It is important that the database only store one report per anomaly or manage to merge different reports of the same anomalies to have a more detailed view of what happened. So, the user has the option to create a new RTA or to add a description in the Registration section of an existing RTA. When the user chooses the create a new RTA option, after the user finishes the registration section, the system is going to compare this report to other reports in the database, searching for RTAs for the same anomalies that might have been created. This is important because it is possible that the user doesnt know about the existence of these reports. The system is going to compare some specifics fields: title, managing agency, anomaly type, location and a range of dates. If it finds RTAs that matches those fields at some specific level, the system is going to present the user a list of these reports. The user must check if any of them are reporting the same anomalies. If this is the case, he can either merge the two reports or add his report as a second version of the first one. In the event he decides to merge them, the system is going to exclude some fields

(certification scope, managing agency, anomaly type, identification method, location of occurrence, key words, anomaly severity, likelihood, and incidence) and maintain the two sections with the description of the anomalies, its possible consequences and the immediate actions. After the registration section is finished the responsible party for the analyses must fulfill the RTA analysis section. In this section he will describe the Disposition Actions and its responsible party(s) and deadline(s), and the Corrective/Preventive Action and its responsible party(s) and deadline(s). In the approval section, a different responsible party for the RTA approves some of the proposed actions. These approved actions should be implemented. Although all the proposed actions from the previous list should be implemented, some are going to be implemented and some are not. The responsible party for the implementation section must identify these actions by clicking on the implemented or not implemented buttons. The last section is the verification. The responsible party for this section must classify the RTA as effective or not. If he classifies as effective, the RTA is ended. It he classifies as not effective the RTA returns to the analysis stage, where new actions can be included and some can be excluded.

Figure 2 Conceptual Model of Proposed Relational Database TreeMap software incorporates a initial overview with a movable field-of-view box, user-controlled zoom factors, dynamic queries in the form of sliders that allow the user to filter uninteresting items according to a indicator variable, and OLAP drilldown capabilities which capacitate quick detail reference on any selected item. [Shneiderman] In our SIGA-customized version of the TreeMap software there are tree nodes, filters, and visual attributes that combine to produce a dynamic query environment that

C. Data Visualization Software Treemaps To combat the data overload problem, we incorporated a SIGA-customized version of Shneidermans Treemaps data visualization software with our own relational database. The widely cited visual-information-seeking mantra states that successful information visualization is conducted through a recursive exploration described as overview first, zoom and filter, then details on demand. Repeat. Snheidermans

visually reveals patterns and trends from a very large set of data. The tree nodes in our software are location of occurrence, responsible agency, and incident category, the visual space is divided according to these nodes, as seen in Figure 3. Within the visual space, the information displayed can be filtered down through the choice of any or all of the following variables: likelihood, gravity, criticality,

and number of reports, simply by manipulating the sliders on the right sidebar. Finally, the visual attributes displayed within the visual space label, size, color can each also be customized to represent the same variables (likelihood, gravity, criticality, and number of reports). Finally, the labels for each rectangle can display the name relevant variable displayed.

Figure 3 TreeMap Data Visualization and Filtration Software Customized for SIGA System B. Recommended Implementation Plan for Large HighRisk Company A robust and accurate safety information system that collects the right data, identifies the most pertinent hazards, and disseminates that hazard information to the right people at the right time is the key to any successful safety management program. A successful implementation must include a safety culture that encourages reporting, a management program that seriously considers recommendations made by the program and its users, as well as effective recommendations that eliminate root causes of hazards, and not just the hazard itself . As the implementation plan currently stands, there is no intent to enter prior incident reports into the current database, because of the amount of manual labor required for this. If a software application can be produced to accomplish the automatic translation of previous reports into quantized database relations, then the company should do so. In order to produce a safety culture that encourages abundant reporting of incidents an effective training program taught by human professors, with rigorous tests

V. RECOMMENDED ACTIONS Though our research has come to a close, the project has the potential to continue in a variety of forms. First, this section will contain recommendations for action for future academic projects related to the continued development of our proposed software solution. Second, we propose a defined plan of action for a large petroleum distributor, or any other company acting in a high-risk arena with an interest in a better safety management system, to fully implement our software solution. A. Recommendations for Future Projects Projects for future academic endeavors include further user testing, development of a functional prototype, implementation of a prototype within a work environment, and a cognitive task analysis (see Vicentes work for an extensive tutorial on this methodology [11]) conducted on workers using the implemented software solution. Each of these steps can also be iterated until an acceptable final product is produced. In the design of a good user interface, user testing must be included along all each iteration of the design process [1].

required for certification, and a renewal requirement every year would raise the average ability level of the typical user as well as encourage more users to buy into the system. VI.
CONCLUSION

Through the combination of a reporting culture that encourages employees to enter incident reports without fear of blame to provide sufficient data, a easy-to-use and meaningful reporting form to maintain data quality, a wellorganized relational database to store the data, and an information visualization software to view large amounts of data at the same time and identify patterns, users of our proposed system should be capable of identify more potential hazards, identify which hazards are most critical, and communicate the presence of those high-priority hazards in order to successfully apply corrective actions that eliminate not only hazards, but their underlying causes as well. ACKNOWLEDGMENT The Capstone team thanks the Health, Safety, and Environment Department at TransPetro for their generous support in describing the SIGA system, suggesting ideas for improvement, and providing valuable feedback on our proposed solution. REFERENCES .
C .D. Wickens, J. Lee, Y. Liu, S.G. Becker. An Introduction to Human Factors Engineering. Upper Saddle River, NJ,: Pearson Prentice Hall, 2004, pp. 360-389. [2] Personal Communication with employees in the Health, Safety, and Enviironment Department of Brazils largest petroleum distributor. [3] Occupational Safety and Health Organization The OSHA Homepage. Obtained at www.osha.gov on April 7th, 2006. [4] J. Reason. Managing the Risk of Organizational Accidents. Brookfield, VT: Ashgate, 1997, pp 117-119 [5] H. Roland & B. Moriarty. System safety engineering and management. 2nd ed. New York: Wiley, 1990. [6] Department of Defense. M.l-STD-882B. Washington D.C.: U.S. Government Printing Office, 1984. [7] D. D. Woods, E.S. Patterson, and E.M. Roth. Can we ever escape from Data Overload? A cognitive systems diagnosis. from Cognition, Technology, and Work, vol, 4, New York: Springer-Verlag, 2002, pp. 22-36. [8] Shell. Review of Tripod-DELTA. Aberdeen: Shell Expro UK, 1997, pp. 17-18. [9] T. M. Connoly and C. E. Begg. Database Systems: a Practical Approach to Design, Implementation, and Management. Essex, England: Pearson, 2005, pp. 342-386. [10] B. Shneiderman, C. Plaisant. Designing the User Interface: Strategies for Effective Human-Computer Interaction. College Park, MD: Pearson Addison Wesley, 2005, pp. 580-600. [11] K.J. Vicente. Cognitive Work Analysis: Towards Safe, Productive, and Healthy Computer-Based Work. Mahwah, NJ: Lawrence Erlbaum, 1999. [1]