Home Crash data collection and analysis system

Reference URL

Rate

To link to this object, paste this link in email, IM or document

To embed this object, paste this HTML in website

Crash data collection and analysis system

View Description

View PDF & Text

PDF
Text

Text Search...

CRASH DATA COLLECTION AND ANALYSIS SYSTEM

Final Report 537

Prepared by:

Ed Cherry, Rob Floyd, Tyson Graves, Steve Martin, David Ward ARCADIS G&M of North Carolina, Inc. 8222 South 48th Street, Suite 149 Phoenix, AZ 85044

February 2006

Prepared for: Arizona Department of Transportation 206 South 17th Avenue Phoenix, Arizona 85007 In cooperation with US Department of Transportation Federal Highway Administration

DISCLAIMER

The contents of this report reflect the views of the authors who are responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the Arizona Department of Transportation or the Federal Highway Administration. This report does not constitute a standard, specification, or regulation. Trade or manufacturers' names which may appear herein are cited only because they are considered essential to the objectives of the report. The U.S. Government and the State of Arizona do not endorse products or manufacturers.

Technical Report Documentation Page

1. Report No. 2. Government Accession No. 3. Recipient's Catalog No.

FHWA-AZ-06-537

4. Title and Subtitle 5. Report Date

Crash Data Collection and Analysis System

7. Author

February 2006

6. Performing Organization Code 8. Performing Organization Report No. 10. Work Unit No. 11. Contract or Grant No.

Ed Cherry, Rob Floyd, Tyson Graves, Steve Martin, David Ward

9. Performing Organization Name and Address

ARCADIS G&M of North Carolina, Inc. 8222 South 48th Street, Suite 149 Phoenix, Arizona 85044

12. Sponsoring Agency Name and Address

SPR-PL-1-(61) 537

13.Type of Report & Period Covered

Arizona Department of Transportation Final Report 14. Sponsoring Agency Code 206 S. 17th Avenue Phoenix, Arizona 85007 15. Supplementary Notes Prepared in cooperation with the U.S. Department of Transportation, Federal Highway Administration

16. Abstract

The Arizona Department of Transportation (ADOT) is responsible for ensuring the safety and operational efficiency of Arizona's state highways. Fulfilling that responsibility requires extensive data collection and analysis, which are very labor-intensive resource-intensive. Seeking to identify how the agency could accomplish the greatest service improvements with the most efficient use of funds, ADOT engaged ARCADIS to perform a Crash Data Collection and Analysis study and examine the possibilities offered by technological innovations such as Electronic Data Entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). The study resulted in a comprehensive report with three components: an examination of best practices in use in the United States today, a use case and gap analysis examining ADOT's current data work, and a technical memorandum outlining how changes could be implemented. Together, the three parts point to a path to introduce best practices in ADOT's crash-analysis systems. Adopting the best practices outlined can reduce the resources required to maintain these systems, freeing those resources to other safety-related concerns.

17. Key Words

18. Distribution Statement

23. Registrant's Seal

Crash Data, Best Practices, Use Case, Gap Analysis, Technical Memorandum, Crash Analysis, GIS, RDBMS.

19. Security Classification 20. Security Classification

Document is available to the U.S. Public through the National Technical Information Service, Springfield, Virginia, 22161

21. No. of Pages 22. Price

Unclassified

SI* (MODERN METRIC) CONVERSION FACTORS

APPROXIMATE CONVERSIONS TO SI UNITS

Symbol When You Know Multiply By To Find Symbol Symbol

APPROXIMATE CONVERSIONS FROM SI UNITS

When You Know Multiply By To Find Symbol

LENGTH

in ft yd mi Inches Feet Yards Miles 25.4 0.305 0.914 1.61 millimeters meters meters kilometers mm m m km mm m m km millimeters meters meters kilometers

LENGTH

0.039 3.28 1.09 0.621 inches feet yards miles in ft yd mi

AREA

in2 ft2 yd2 ac mi2 fl oz gal ft3 yd3 square inches square feet square yards Acres square miles fluid ounces Gallons cubic feet cubic yards 645.2 0.093 0.836 0.405 2.59 square millimeters square meters square meters hectares square kilometers milliliters liters cubic meters cubic meters mm2 m2 m2 ha km2 mL L m3 m3 mm2 m2 m2 ha km2 mL L m3 m3 Square millimeters Square meters Square meters hectares Square kilometers milliliters liters Cubic meters Cubic meters

AREA

0.0016 10.764 1.195 2.47 0.386 square inches square feet square yards acres square miles fluid ounces gallons cubic feet cubic yards in2 ft2 yd2 ac mi2 fl oz gal ft3 yd3

VOLUME

29.57 3.785 0.028 0.765

VOLUME

0.034 0.264 35.315 1.308

NOTE: Volumes greater than 1000L shall be shown in m3.

MASS

oz lb T Ounces Pounds short tons (2000lb) 28.35 0.454 0.907 grams kilograms megagrams (or "metric ton") Celsius temperature g kg mg (or "t")

MASS

g kg Mg grams kilograms megagrams (or "metric ton") Celsius temperature 0.035 2.205 1.102 ounces pounds short tons (2000lb) oz lb T

TEMPERATURE (exact)

Fahrenheit temperature foot candles foot-Lamberts Poundforce poundforce per square inch

5(F-32)/9 or (F-32)/1.8

1.8C + 32

Fahrenheit temperature foot-candles foot-Lamberts poundforce poundforce per square inch

ILLUMINATION

fc fl lbf lbf/in2 10.76 3.426 4.45 6.89 lux candela/m2 newtons kilopascals lx cd/m2 N kPa lx cd/m2 N kPa lux candela/m2 newtons kilopascals

ILLUMINATION

0.0929 0.2919 0.225 0.145 fc fl lbf lbf/in2

FORCE AND PRESSURE OR STRESS

SI is the symbol for the International System of Units. Appropriate rounding should be made to comply with Section 4 of ASTM E380

TABLE OF CONTENTS

EXECUTIVE SUMMARY ...................................................................................................... 1 1. INTRODUCTION ................................................................................................................ 7 2. BEST PRACTICES.............................................................................................................. 9

2.1 INTRODUCTION .................................................................................................................9 2.2 METHODOLOGY.................................................................................................................9 2.3 SURVEY RESULTS ...........................................................................................................10 2.4 SELECTED STATES BEST PRACTICES.........................................................................13 2.5 IDEAL SYSTEM COMPONENTS.....................................................................................19 2.6 BEST PRACTICES CONCLUSION...................................................................................19

3. USE CASE........................................................................................................................... 21

3.1 INTRODUCTION ...............................................................................................................21 3.2 METHODOLOGY...............................................................................................................21 3.3 USE CASE RESULTS.........................................................................................................23

4. GAP ANALYSIS ................................................................................................................ 31

4.1 INTRODUCTION ...............................................................................................................31 4.2 METHODOLOGY...............................................................................................................31 4.3 BEST PRACTICE RESULTS .............................................................................................33 4.4 USE CASE RESULTS.........................................................................................................33 4.5 COMPARISON ...................................................................................................................34 4.6 GAP ANALYSIS RESULTS...............................................................................................37 4.7 GAP ANALYSIS CONCLUSION ......................................................................................40

5. TECHNICAL MEMORANDUM ..................................................................................... 41

5.1 INTRODUCTION ...............................................................................................................41 5.2 OVERALL GOAL ? MORE EFFICIENT AND ACCURATE DATA COLLECTION ....41 5.3 OVERALL GOAL ? ENTERPRISE DATABASE SYSTEM INTEGRATION ................49 5.4 OVERALL GOAL ? IMPROVEMENT OF ANALYTICAL AND REPORTING CAPABILITIES...................................................................................................................54 5.5 OVERALL GOAL ? MORE EFFICIENT DATA AND ANALYSIS ACCESS ................65 5.6 IDEAL SYSTEM DESIGN .................................................................................................69 5.7 OVERALL IDEAL SYSTEM DESIGN IMPLEMENTATION .........................................69

6. RECOMMENDATION AND IMPLEMENTATION STRATEGY.............................. 73

6.1 INTRODUCTION ...............................................................................................................73 6.2 STRATEGY.........................................................................................................................73 6.3 OVERALL PRIORITIZED IMPLEMENTATION.............................................................77

APPENDIX A. SURVEY QUESTIONS............................................................................... 79

LIST OF TABLES

TABLE 1. SYSTEM DESIGN RECOMMENDATIONS ....................................................................... 18 TABLE 2. INTERVIEW PARTICIPANTS ......................................................................................... 20 TABLE 3. USER DESIRES............................................................................................................ 22 TABLE 4. CURRENT PRACTICES ? DATA COLLECTION............................................................... 34 TABLE 5. CURRENT PRACTICES ? DATA STORAGE .................................................................... 35 TABLE 6. CURRENT PRACTICES ? ANALYSIS AND REPORTING .................................................. 36 TABLE 7. CURRENT PRACTICES - ACCESSIBILITY...................................................................... 37 TABLE 8. GAP CLOSURE ............................................................................................................ 38 TABLE 9. COSTING ? ELECTRONIC DATA ENTRY ...................................................................... 42 TABLE 10. COSTING ? ELECTRONIC DATA TRANSFER............................................................... 44 TABLE 11. COSTING ? GIS IMPLEMENTATION .......................................................................... 45 TABLE 12. COSTING ? GPS IMPLEMENTATION.......................................................................... 45 TABLE 13. COSTING ? MMUCC DATA ELEMENTS ................................................................... 46 TABLE 14. COSTING ? AUTOMATIC DATA POPULATION............................................................ 47 TABLE 15. COSTING ? DOMAINS AND BUSINESS ATTRIBUTE RULES......................................... 48 TABLE 16. COSTING ? CRASH DEFINITION STANDARDS............................................................ 49 TABLE 17. COSTING ? NEW ALISS........................................................................................... 51 TABLE 18. COSTING ? INTEGRATE STATE HIGHWAY SYSTEM LOG ........................................... 52 TABLE 19. COSTING ? INTEGRATE DATA WAREHOUSE SYSTEM ............................................... 52 TABLE 20. COSTING ? DIGITAL INCIDENT REPORT STORAGE.................................................... 54 TABLE 21. COSTING ? ADVANCED STATISTICS, CHARTING, AND GRAPHING CAPABILITIES ..... 55 TABLE 22. COSTING ? USER FRIENDLY GIS TOOLS .................................................................. 56 TABLE 23. COSTING ? SIGNALIZED INTERSECTIONS.................................................................. 57 TABLE 24. COSTING ? PRIORITIZED ACCIDENT LOCATIONS ...................................................... 58 TABLE 25. COSTING ? HIGH RISK/HAZARD ACCIDENT LOCATIONS .......................................... 59 TABLE 26. COSTING ? SAFETY IMPROVEMENT EFFECTIVENESS ................................................ 60 TABLE 27. COSTING ? ACCIDENT AND SEVERITY RATES .......................................................... 61 TABLE 28. COSTING ? STREET NAMES AND ALIASES................................................................ 61 TABLE 29. COSTING ? CONTRACT RELEASE DATES .................................................................. 62 TABLE 30. COSTING ? DATA SHARING AMONGST ADOT, LOCAL, AND REGIONAL AGENCIES 63 TABLE 31. COSTING ? INTERSECTION MAGIC INTEGRATION ..................................................... 64 TABLE 32. COSTING ? MOST HARMFUL EVENTS....................................................................... 65 TABLE 33. COSTING ? WEB PORTAL AND DATA ONE-STOP...................................................... 67 TABLE 34. COSTING ? CUSTOM, STORED, AND HISTORICAL REPORTS...................................... 68 TABLE 35. COSTING ? USER DEFINED DATA EXPORT FORMATTING ......................................... 69 TABLE 36. OVERALL SYSTEM COSTING .................................................................................... 71 TABLE 37. STEP 1 NEW ALISS ................................................................................................. 74 TABLE 38. STEP 2 ALISS AND TRANSPORTATION GIS INTEGRATION ...................................... 74 TABLE 39. STEP 3 ELECTRONIC DATA TRANSFER ..................................................................... 75 TABLE 40. STEP 4 WEB ACCESS FOR DATA QUERY AND DOWNLOAD....................................... 75 TABLE 41. STEP 5 ACCIDENT AND SEVERITY RATES DATA....................................................... 76 TABLE 42. STEP 6 ADDITIONAL DATA COLLECTION EFFORTS .................................................. 76 TABLE 43. STEP 7 ELECTRONIC DATA ENTRY........................................................................... 77

TABLE OF FIGURES

FIGURE 1. FIGURE 2. FIGURE 3. FIGURE 4. FIGURE 5. FIGURE 6. CRASH-DATA SYSTEMS STUDY ? PROJECT DESIGN...................................................6 BEST PRACTICE SURVEY RESULTS ? STATE RANKINGS PER CATEGORY.................. 10 BEST PRACTICE SURVEY RESULTS ? STATE RANKINGS OVERALL........................... 10 CRASH RECORDS DATA FLOW ................................................................................. 30 BEST PRACTICE BENEFITS ....................................................................................... 32 OVERALL IDEAL SYSTEM DESIGN............................................................................ 70

GLOSSARY OF ACRONYMS

ADOT AIDW ALISS ATIS ATSIP BIA CAD CCT CODES CRASH DMV EDE EDT FARS FHWA FMS GIS GPS HCRS ISTEA ITCA ITS MAG MVD MMUCC NHSA NHSDA NHTSA PDA QA/QC RDBMS RWIS SHL TADS TEA TIS TraCS TRB VMS Arizona Department of Transportation ADOT Information Data Warehouse Accident Location Identification Surveillance System Arizona Transportation Information System Association of Transportation Safety Information Professionals Bureau of Indian Affairs Computer-Aided Dispatch Closed-Circuit Television Crash Outcome Data Evaluation System Collision Report Analysis for Safer Highways Department of Motor Vehicles Electronic Data Entry Electronic Data Transfer Fatality Analysis Reporting System Federal Highway Administration Freeway Management System Geographic Information Systems Global Positioning System Highway Conditions and Reporting System Intermodal Surface Transportation Efficiency Act Inter Tribal Council of Arizona Intelligent Transportation System Maricopa Association of Governments Motor Vehicle Division Model Minimum Uniform Crash Criteria National Highway Safety Act National Highway System Designation Act National Highway Traffic Safety Administration Personal Digital Assistant Quality Assurance/Quality Control Relational Database Management Systems Road Weather Information System State Highway Log Traffic Accident Data System Transportation Efficiency Act Traffic-Interchange Signal Traffic and Criminal Software Transportation Research Board Variable-Message Signs

EXECUTIVE SUMMARY

The Arizona Department of Transportation (ADOT) is responsible for the safety and operational efficiency of Arizona's state highways. Fulfilling that responsibility requires extensive data collection and analysis, which are labor-intensive and resource-intensive. Seeking to identify ways the agency could accomplish the greatest service improvements with the most efficient use of funds, ADOT engaged ARCADIS to perform a Crash Data Collection and Analysis study and examine the possibilities offered by technological innovations such as Electronic Data Entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). The study resulted in a comprehensive report with three components: an examination of best practices in use in the United States today, a use case and gap analysis examining ADOT's current data work, and a technical memorandum outlining how changes could be implemented. Together, the three parts point to a path to introduce best practices in ADOT's crash-data analysis related database systems. Adopting the practices outlined below can reduce the resources required to maintain these systems, freeing those resources to other safety-related concerns. BEST PRACTICES To identify the states whose system components can be considered best practices ARCADIS conducted a survey. Based on the survey results, leading states were selected for more in-depth analysis. The research team examined five components of each selected state's crash-data analysis system: data collection, data storage, analysis and reporting, accessibility, and overall system efficiency. The best innovations within each component were then combined to form an ideal system that would maximize efficiencies for any crash-data system, including ADOT's. Some states have proven that electronic, field-based data entry and electronic data transfer (EDT) can expedite data entry and increase efficiency. Reducing data entry points and electronically transferring data increase data consistency and accuracy through the use of data element standards and business rules for validation and quality assurance/quality control (QA/QC). The use of an open RDBMS provides great flexibility in data accessibility and analysis. Direct links to outside databases such as facility, citation, drivers' license, and vehicle registration databases are beneficial. The ideal configuration of analysis and reporting components varies with needs, but ADOT should target specific functions and capabilities. Among them: ? The ability to generate custom reports and queries from a centralized location that optimizes efficiency for end-users and managers. ? User-friendly GIS capabilities that integrate mapping and spatial analysis into reports. ? Easy access to and downloading of previously generated reports. ? The ability to perform advanced statistical analysis and charting by pulling data directly from the enterprise database to ensure that the most current information is used.

? A Web-based application for data retrieval and analysis that provides the greatest data access to the most users. USE CASE AND GAP ANALYSIS A use case study is a multi-level research that identifies current desires, assets, capabilities, and workflows for a particular organization. A gap analysis discovers where the current system falls short of best practices. Among the conclusions: ? Arizona should utilize electronic, field-based data entry and electronic data transfer. Those processes should use domains and business attribute rules for automated QA/QC and standardization of data elements. X,Y coordinates of accident locations should be determined and recorded from the Global Positioning System (GPS) or Geographic Information Systems (GIS) with every incident record to improve accident positional accuracy. External database systems, such as vehicle registration and driver's license databases, should be integrated into an enterprise system of transportation-related databases to minimize data entry. Personnel at crash scenes should collect more Model Minimum Uniform Crash Criteria (MMUCC) data elements, including harmful events1. The user community should standardize data elements for street naming and crash definitions. Signalized intersection and road contract release dates2 should be collected and maintained. Arizona should integrate additional data sources to the Accident Location Identification Surveillance System (ALISS). The State Highway Log (SHL) system should be the primary source of facility information that is attached to the incident record, allowing statewide average of incidents to be calculated by facility. The current ALISS lacks detailed system documentation and the ability to manipulate the database structure as well as a visual data entry form to accommodate any changes in the future. Arizona should automate its data reporting and data exporting routines, giving users direct access to a live crash-data analysis system and allowing them to analyze the data and generate custom reports for export. On-line functions should include GIS, advanced statistical analysis, and graphic and charting capabilities. This on-line access point should be built as a one-stop access point for data and analysis and should include access to digital ALISS reports. The system should also be designed to automatically submit data to the Federal Highway Administration (FHWA) and Fatality Analysis Reporting System (FARS). It should allow users to: ? generate statewide averages of accidents by facility type.

Harmful events are defined as a series of related incidents within an accident or a crash. For example, in a car crash one car rear-ends another car and the struck car then runs into a third car. Then, this car crash will have two harmful events, the first involves the first and second cars and the second involves the second and third cars. First, second, third harmful events and so on indicate the order of the incidents that occur within an accident. Of all the harmful events involved in an accident, most harmful event is the most severe incident that causes the most damage or injury.

A Contract Release Date is the official date on which a highway agency takes control of the road or intersections maintenance from a construction contractor and open the road for traffic.

? generate lists of top ten accident locations for a given area by facility type. ? identify high-risk/hazardous locations. ? assess the effectiveness of improvements ? calculate accident and severity rates over identified stretches of highway ? draw diagrams using Intersections Magic. Basic and user-friendly GIS diagramming and mapping should also be functional. ? Arizona should grant access to its crash-data analysis system to all users within the crash data community through an Internet-based application and a one-stop portal for data access and analysis. A 24/7 solution would provide the greatest access and flexibility for end users. Arizona needs to eliminate redundant data entry. On-line and customizable data downloads, centralized access to tools and data, and live linkages for custom reporting will minimize staff intervention at all levels.

A use case study delves into the specifics of an organization, resulting in a broad and complete understanding of its business practices. For the ADOT study, a combination of interviews and data analysis defined current assets and capabilities. ARCADIS visited ADOT's facilities and interviewed several key players responsible for crash data, as well as people at external entities such as the Federal Highway Administration (FHWA), regional governments, and local municipalities. Three areas were identified as critical for appropriately defining ADOT's business practices. These were internal desires, existing assets and capabilities, and workflows. The internal desires section of this report identifies the current desires expressed by the various users of ADOT's systems and data. The desires are apportioned among the five components used to identify best practices: data collection, data storage, analysis and reporting, accessibility, and overall efficiency. The existing assets and capabilities section gives an overview of ADOT's current systems, databases, GIS capabilities, analytical tools, reporting tools, and data-sharing. The workflows identify data flow and timeframes for getting these data to and from ADOT systems. TECHNICAL MEMORANDUM The technical memorandum of this report proposes solutions to the desires and gaps identified during the earlier portions of the study. It lays out specific course of action to reduce the resources ADOT must allocate to collect and analyze crash data. The strategy aims at delivering the most capability for the least funding while building toward an ideal crash data collection and analysis system. Step 1 ? Creation of a new ALISS database To accomplish the goals set forth in the previous portions of the study, a new database system must be devised to store and retrieve incident records. Generating accident and severity rates, analyzing safety improvement effectiveness, and prioritizing accident locations by facility type all require linking the ALISS and ADOT Information Data

Warehouse (AIDW) databases. Unfortunately, the current ALISS is neither documented nor customizable, making it difficult to establish this linkage. Either funding needs to be applied to the ALISS to document it and make it customizable, or a new system needs to be developed. The project team recommends creating a new ALISS based upon a GIS system and using an RDBMS and ArcSDE. This will provide the basis for a relationship between the AIDW and the ALISS while utilizing software capabilities already in place within ADOT. The new ALISS will need a new interface for data entry and minimal training for current data-entry staff. Once the database is created, the records in the current ALISS must be migrated to the new system. The new system should take advantage of MMUCC standards for data elements with the understanding that not all elements are currently collected in the field. As more agencies move toward electronic data entry, the ability to collect additional MMUCC elements may become available. The database should be designed to incorporate this possibility. The data elements of first, second, and most harmful events should also be incorporated. This change will require an alteration of the accident data collection form. The existing stored reports in the current ALISS will need to be migrated to the new system. These reports are very important to the crash data community as a whole, and the system would be taking a step backward if they were lost in the conversion. Step 2 ? Integrate the new ALISS with the current GIS infrastructure and the data warehouse ADOT GIS is undergoing a migration to a new geodatabase data structure for maintaining roadway information. This system is linear-referenced with dynamic segmentation and is capable of storing a variety of facility information in the relational database scheme. The project team recommends integrating the ALISS with the new GIS roadway database and the AIDW. This will provide all facility information in a GIS format that can be analyzed with the new ALISS. Steps one and two are the most important aspects of this implementation plan and should be performed concurrently to maximize interoperability and minimize cost. Step 3 ? Create Electronic Data Transfer (EDT) routines ADOT is duplicating a significant amount of effort by not accepting electronic transfer of incident records. Several municipalities type incident records into a database system in their offices, only to then send a hard copy to ADOT for entry into the ALISS. The project team recommends that ADOT accept EDT and create import routines and workflows to support this initiative. This will involve a study to determine all the possible data import formats in the systems that the various agencies use for their incident records. The team believes that there are probably only five or six different systems in use and the creation of the import routines should only require minimal effort. Each record should contain the same data elements, minimizing the complexity of creating the import routines.

Step 4 ? Create web access to integrated databases for data query and download Staff resources are required to distribute ALISS data to users both within ADOT and externally. This can be eliminated by utilizing existing software within ADOT GIS. ArcIMS is a Web-based application that allows display, query, and download of GIS data through the Internet at a user's discretion. When the ALISS is integrated with the AIDW and the ADOT GIS database, users can access data through the ArcIMS Website. Basic GIS functionality is inherently available to all users who have access to the Website. This will also provide live access to the ALISS, ensuring that users get up-to-date information for their analyses. ArcIMS can be designed to only display and export information that is not sensitive, or a security system can be implemented to grant or deny users access to sensitive data. Step 5 ? Accident and severity rates database With the linkage among the ALISS, AIDW, and GIS databases, accident and severity rates can be calculated for facility types by numerous factors, including vehicle type, driver's age and gender, weather condition, and geography. These rates should be incorporated into a database for all to use. This database can be created without staff involvement other than routine database administration. Once the database is built, updating the rate values can be automated. These calculations are relatively simple within a GIS system and can be provided through the ArcIMS Website with minimal effort. A study should be undertaken to decide which rate calculations will be made available, including rates by time and geography (i.e. weekly, monthly, yearly by county, ZIP code, region, by facility, type, age, weather, etc.). The study will drive the database design, the number of execution statements required, and the frequency of the rate updates. The rates will then be tied to the appropriate highway GIS features for inclusion into the overall system for users to analyze. This database feasibility is currently being researched by the Maricopa Association of Governments (MAG) and its progress should be monitored. Step 6 ? Additional data collection efforts All analytical capabilities start with good data resources. The collection of data about signalized intersections, contract release dates, and safety improvements would grant users analytical capabilities that they currently do not have. Most of these data should already be maintained by various agencies, including ADOT, and need only to be found and integrated into the GIS system. Some of these data demand more resource to be integrated than others, but the level of effort deeded for the data integration cannot be quantified until the data resources can be found and analyzed. Step 7 ? Electronic data entry It would be optimal for the state to embrace electronic data entry for all incident records. This may not be feasible due to financial limitations, but ADOT should promote its use whenever possible in the hopes that eventually this will become a reality.

needed to bridge the gaps between the existing and proposed systems. The final portion of the study was a Technical Memorandum listing specific steps and resources required to implement the output from the Gap Analysis. The result of this three-part study is the steps necessary to introduce best practices in ADOT's crash-analysis systems and, as a result, reduce the resources required to maintain these systems and allow resources to be reallocated toward additional safetyrelated concerns. ADOT Crash-Data Systems Study

Best Practices -Industry Goals, Standards, and Success -Proven Technologies Technical Memorandum -Desired Capabilities -Needed Resources to Achieve Capabilities -Functional System Design

Gap Analysis -Current System Deficiencies Use Case -Internal Needs -Existing Assets and Capabilities -Workflows

Figure 1. Crash-Data Systems Study ? Project Design

1. INTRODUCTION

The Arizona Department of Transportation (ADOT) is responsible for the safety and operational efficiency of Arizona's state highways. Additionally, the National Highway Safety Act (NHSA) of 2003 mandates that ADOT collect and report crash information. All levels of government use this information in analyses to identify areas where safety is a critical concern and improvements could be made, and to measure the overall effectiveness of the safety improvements. The crash data-collection techniques and analytical processes are very labor-intensive and resource-intensive. They place a significant burden on budgets, especially during times of dwindling financial resources. ADOT engaged the services of ARCADIS for a Crash Data Collection and Analysis study to develop alternatives to mitigate some of these intensive processes through technological innovations such as electronic data entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). To help identify the most appropriate and cost-beneficial solutions for ADOT, a multi-part study was proposed with the following objectives: ? ? ? ? ? to identify and research current ADOT databases and systems to leverage existing information assets to support crash data analysis. to identify internal and external users' need for crash data and analysis to support their safety-analysis functions. to determine ADOT's current processes for collecting crash data and documenting workflows. to research the industry's current crash data analysis best practices for application at ADOT. to define system requirements (data, procedures, tools, and applications) for use by ADOT and local jurisdictions to effectively identify, analyze, map, and report crash information and safety enhancements. to develop and present an implementation plan for improving crash data collection and analysis.

To achieve these objectives, this comprehensive study was produced with three report products (Figure 1). The first component of the study was a Best Practices review of other states' crash systems. This highlights some of the most efficient and technologically advanced systems in use around the country. The best practices of these states served as a benchmark for ADOT to meet or surpass in developing or improving its own systems. The second component was a Use Case study and Gap Analysis. The Use Case was an indepth study of ADOT's desires and current system components of ADOT's existing crash systems. Once ADOT's current systems were defined and its desires and goals were identified, a gap analysis highlighted the deficiencies of the current system and the steps

2. BEST PRACTICES

This section of the study used a research-based approach to determine how leading states handle crash-data systems and to report on the benefits of their techniques. The innovative and efficient practices identified serve as benchmarks to which ADOT can aspire in migrating its crash data systems. 2.1 INTRODUCTION In 1991, the Intermodal Surface Transportation Efficiency Act (ISTEA) required states to have highway safety management systems (Section 1034), with a goal of reducing the number and severity of traffic crashes. In 1995, the National Highway Systems Designation Act (NHSDA) made the implementation of safety management system and other selected management systems optional, while maintaining the required reporting. TEA 21 (1998) and subsequent reauthorizations still require that basic crash-data be compiled by each state. They also require data uniformity so data can be exchanged between states and compared. While states must comply with this legislation, each state has a different method of compliance. Each state has been given the flexibility to control its own crash-data system, and thus there are 50 different crash-data systems. Standardization efforts span multiple states, but each state has its own needs and its system can be remarkably different. This, however, creates wonderful possibilities for ADOT to learn from other organizations. To help realize these possibilities, this best practices review has been undertaken to examine each state's system. To help identify the states that have system components that can be considered best practices, the research team conducted a survey. This survey asked questions designed to highlight efficient and innovative practices in crash-data systems. From the survey results, leading states were selected for more in-depth analysis of the factors that make their systems stand out as best practices. The team examined each selected state for five components: data collection, data storage, analysis and reporting, accessibility, and overall system efficiency. The best innovations within each component were then combined to form an ideal system that would maximize efficiencies for any crash-data system. 2.2 METHODOLOGY To determine the best practices of each of the 49 states surveyed, the research team selected a Web-based electronic survey method. After a contact list for the 49 states' Transportation Departments was compiled, an e-mail was sent inviting each state to respond to questions about its existing crash data system (see Appendix A for survey questions). The data gathered was for descriptive statistical analysis only, due to the qualitative nature of a number of the questions. The descriptive data was analyzed to initially gauge a state's current status and then to narrow down the list to a few states that were considered to have the best practices. The analysis method of the survey was a unique-case orientation. Each state's attributes were compared for data collection, data

ARCADIS Crash Data Systems Best Practice Survey

1-5 R nking S hema a c

Dat a Collection Dat a Storage Analysis & Reporting Accessibilt y Overall Efficiency

0 IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV M S Surveyed States

Note: The bars are in the same order as in the legend.

Figure 2. Best Practice Survey Results ? State Rankings per Category

Arcadis Crash Data Systems Survey Sum Ranking Results

5 4.5 4 3.5

1-5 Ranking Schema

Note: The bars are in the same order as in the legend.

3 2.5 2 1.5 1 0.5 0 IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV MS Surveyed States

IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV MS

Figure 3. Best Practice Survey Results ? State Rankings Overall

storage, analysis and reporting, accessibility, and overall efficiency. The newest implementation date and years in service as well as the use and innovation of new technologies were weighting factors. The ranking schema follows an order of 1 being the lowest score and 5 the highest. Data collection rank was determined by 5, representing new technology such as GPS, electronic data submission and by the standardization of data entry, and 4-1, representing the degree to which this technology was lacking and the status of any new system to replace the old methods. Data Storage was ranked 1-5 where 5 represents the utilization of a customized Oracle database system and 1 represents the maintenance of and dependence on a mainframe system. Analysis and Reporting was ranked by 5 representing the use and design of technological innovations, such as an enterprise management system and GIS, and 1 representing manual or disconnected applications procedures, which were deemed labor intensive and redundant. Accessibility was ranked 1-5 with data retrieval systems that were accessible via web based applications or linked in real time to many users and clients ranking as 5, and hard copy limited reporting systems ranking as 1. Overall Efficiency was ranked 1 -5 based upon the values obtained from the other factors (Data Collection, Data Storage, Analysis and Reporting, and Accessibility) and how well these factors were designed in relation to each other. An integrated system from data entry to data querying without platform changes and or manual steps that cause impedances to the quality and analysis of crash data would rank as 5. The Sum Ranking of the surveyed states was then averaged into a 1-5 ranking schema where 5 demonstrated the overall best practice ranking. Next, current literature was reviewed, including Transportation Research Board (TRB) reports, reports from leading states, and documentation from the Association of Transportation Safety Information Professionals (ATSIP) annual meetings. Finally the research team identified the components of crash data systems with the best practices and selected the states with comprehensive programs that have these components. 2.3 SURVEY RESULTS The survey's objective was to determine and rank each state's data collection, storage, analysis and reporting methods with regard to the particular crash-data system's overall accessibility and efficiency. The survey results are shown in Figures 2 and 3. Four states stood out for their technical advances and implementation and for their over all system designs and efficiency. These states are Iowa, Kentucky, Illinois and Massachusetts. The questions in the survey focused on operating systems, database management systems and support software for analysis and distribution, and the role of those systems in each state's crash-data system. All states surveyed used a Windows NT, 2000 or XP operating system. The dominant database management system was Oracle, which was either an integral part of the design of each new crash-data system or was being migrated from an antiquated mainframe system. 2.3.1 Data Collection Predictably, survey respondents stressed the need for standardizing data-collection methods and accident forms, and incorporating Global Positioning System (GPS)

technology to aid in data accuracy and spatial analysis. Systems such as Traffic and Criminal Software (TraCS) and Model Minimum Uniform Crash Criteria (MMUCC), which will be discussed in following sections, were deemed best practices for collecting and standardizing crash data. The importance of this component was illustrated by Pennsylvania's response, which said that electronic data capture was one of the most advantageous components of its system. 2.3.2 Data Storage As in all computer systems, storage space and methods are always an area of attention for crash data system users and administrators. From the survey findings, the research team concluded that each state customizes database management systems to meet its needs. The majority of respondents had changed this aspect of their systems within the past five years. The robustness of the Oracle or SQL Server components for querying and exporting data made them a best practice among all the states surveyed. In Montana, the Oracle system helps link DOT traffic and facility information to incident records, allowing for advanced queries and analyses. 2.3.3 Data Analysis and Reporting The complexity of crash data has been the motivation for developing many customized analytical software packages. All of the survey respondents used a customized analytical system, and 50 percent of the respondents, including New Mexico, California, South Carolina, and Montana, stressed the importance of integrating GIS and GPS into their analytical procedures. According to the survey results, two factors drive the standardization of crash-data formats and reporting guidelines: the primary end-user's needs for data application and the federal standards of the Federal Highway Administration (FHWA) and the National Highway Traffic Safety Administration (NHTSA). 2.3.4 Accessibility Data collection, data storage, and analysis and reporting played significant roles in determining the accessibility of a state's crash data. There were many variations of by whom and how the data was accessed. The primary users envisioned in designing data access were the traffic safety engineers. Personnel at Departments of Motor Vehicles (DMVs) and Emergency Management Services (EMS) are also data users although they may access and use the data differently. Massachusetts was identified as a best-practice state owing to its use of the Crash Outcome Data Evaluation System (CODES) that integrated many different data-users into one platform. 2.3.5 Overall Efficiency Iowa and Kentucky were ranked highest in Overall Efficiency. Both states are able to collect, monitor, analyze and distribute crash data in real time. Reaching this level is a

testament to the ability of these states to implement technological advances in datacollection and querying. The data collected from this survey has been very useful in understanding the broad spectrum of methods and problems related to crash-data systems, and also provided a snapshot of the nations' crash-data systems. However, because the voluntary survey responses to the limited survey questions are widespread, the results of this survey were only able to provide a preliminary exploration of the best practices of transportation departments' crash-data systems. Therefore, the research team further selected four leading states in crash data management for in-depth analysis of their best practices. 2.4 SELECTED STATES BEST PRACTICES In examining crash-data systems to identify innovative and efficient practices in the four states selected for more in-depth analysis, the research team used the same five system components employed in the survey: data collection, data storage, analysis and reporting, data accessibility, and overall resource efficiency. Each state's system identified as having a best practice in one or more of these areas is described below. The result is a list of the components of an overall ideal system. The states selected for in-depth analysis were Kentucky, Iowa, Illinois, and Massachu-setts. While none of the four states should be considered to have best practices through-out its system, a component was selected from each state's system as a best practice that should be considered and assessed for the development of the ADOT system. 2.4.1 Data Collection Data collection is the area where the most states are using technology to improve their crash-data systems. Innovative practices are improving data quality, reducing staff intervention, and expediting data availability within their systems. Of the four selected states, Kentucky, Iowa, and Illinois stand out as leaders in the realm of data collection. Also noteworthy and described below are the MMUCC standards for crash-data collection. While these standards are not considered best practices, they play a very important role in creating an overall model system. Kentucky uses a custom-developed field system for electronic data entry and collection. Led by the Kentucky State Police, 151 agencies in the state have deployed field units into patrol and response vehicles. The field units are equipped with barcode scanners and GPS units to help auto-populate electronic forms from incidents to violations. The system is live-linked to an enterprise database system that contains vehicle and driver data that is automatically transferred to the electronic form, reducing the time needed for data entry and eliminating data-entry errors. This system employs business rules for data validation that enforce data consistency and serve as a first level QA/QC of the entered data. The GPS system automatically inputs the positional location of the incident, allowing spatial display and query downstream. The system records 90 percent of the MMUCC components for 41 percent of all incident records.

Iowa has developed and utilizes the TraCS field data-collection system. Several states have adopted this system as the national model for collecting incident data. The system is fielddeployed with an array of barcode scanners, swipe-card readers, digital cameras, GPS units, and touch pads to facilitate automatic and digital data entry. TraCS utilizes the GPS location of the incident to tie-in roadway facility information automatically in addition to automatically populating data elements from vehicle, driver, emergency, and crime databases. TraCS has the additional components of a GIS viewer that helps locate intersections and additional area information, a photo-imaging system to directly attach digital photos to an incident report, and electronic diagramming to sketch incident specifics directly at the scene. This system also has a direct tie-in to Iowa's Computer-Aided Dispatch (CAD) system. Illinois uses a combination of Iowa's TraCS and a custom-developed, field-based dataentry system. The data-entry system is deployed in vehicles and is equipped with GPS units to determine incident locations. The Illinois system is accompanied by a diagramming tool that electronically details the events with graphic representation. The electronic forms have embedded business rules to ensure data consistency and accuracy in entered data elements. The completed records are transmitted electronically to a centralized data warehouse for retrieval by any authorized user. MMUCC is a guideline for minimum, standardized data describing motor vehicle crashes and the vehicles, persons, and environments involved. This guideline was created to ensure that officials collected the information necessary to support analysis to improve highway safety at the state and national levels. The first edition of MMUCC was created in 1998; it was revised in 2003 to include new data elements relevant to emerging highway-safety issues such as distracted driving and use of child restraints. State participation is voluntary; however, the data elements are based upon FHWA and other federal criteria. MMUCC has 111 data elements. Seventy-seven of these elements are to be collected at the scene and include date/time, weather, location, vehicles involved, sequence of events, etc. Ten more elements are derived from the previous elements, and include severity, fatalities, and presence of alcohol. Additional driver information and facility information compose the remaining 24 elements, which are designed to be integrated once the incident is entered into an enterprise database system. Implementing MMUCC has several benefits to agencies responsible for highway safety. MMUCC improves the quality of state and national incident data by forcing data consistency among agencies and enabling data-sharing and analysis among all participants. A data standard also enables software to be developed and shared across multiple agencies, reducing initial costs for system development. The three leading states exemplify innovation and efficiency in data collection. While most states are utilizing resources to enter data that was hand-written and later typed, and then entered into an enterprise database system, the three states are saving critical resources for other programs such as mediation and safety analysis. These time-saving approaches are making incident data available in a matter of hours, as opposed to weeks or months. Also incredibly beneficial is that data are entered once and are validated automatically by

business and consistency rules. These rules dramatically reduce data-entry errors and improve the overall accuracy of the database. 2.4.2 Data Storage Data storage is one of the most critical aspects of an efficient system. The development of RDBMS has enabled the seamless storage and retrieval of information to and from almost any application developed within the last several years. The RDBMS database systems reduce the need for manipulating data before transmitting them from system to system, thus saving staff time and resources needed to get information to analysts and decision-makers. All four selected states use an enterprise RDBMS for their data storage systems. Kentucky utilizes a custom database, Collision Report Analysis for Safer Highways (CRASH), for its incident records. This enterprise system accepts electronically transferred incident records from collection agencies and automatically populates the database tables. CRASH not only holds incident records, but also records for all court cases, citations, and firearm registrations. Relationships established among these different data components could support advanced analysis using different information sources. Illinois uses a Microsoft SQL Server database for data storage. The database stores data in a central repository for users to access. Several additional systems link to form a one-stop interface for users to access incident and other related information, thus reducing the need to visit multiple locations for data. Massachusetts employs an Oracle database named CODES. This storage system is part of a national program in which several states participate to help maximize development resources, enforce data consistency, and create data-sharing opportunities. This system uses an enterprising approach that links other databases to form an integrated data solution. EMS, hospital, death, and insurance records are all integrated components of this system. Iowa uses a combination of Oracle, SQL Server, DB2, and Access databases for its data storage. This system accepts electronic field reports and populates the necessary data elements without user intervention. The system then automatically replicates data elements to other databases for use by other agencies, such as FHWA and municipalities. This system also has a direct integration with the state's citation database. While all these states have different approaches to data storage, they all have common components that serve as core efficiencies that need to be noted. Significant time is saved by receiving reports and records electronically with minimal user intervention. The linkages to other enterprise systems enable advanced data analysis. Having the data stored in a RDBMS database makes data sharing and transfer to other systems and users efficient and cost-effective. 2.4.3 Data Analysis and Reporting Data analysis and reporting capabilities vary widely from state to state. Some states are very innovative, connecting their enterprise systems to the World Wide Web to allow 24/7

(24 hours a day, 7 days a week) access, while others choose to allow data access only to desktop users. Some systems can generate custom, ad-hoc reports while others only allow predetermined reporting functionality. The research team has found that most states are using or plan to use GIS in the near future to expand their analytical capabilities. Also detailed in this section is the federally mandated reporting system, Fatality Analysis Reporting System (FARS). FARS itself is not a best practice, however the handling of FARS reporting has implications that could lead to a best practice. Kentucky's system features a Web portal with GIS functionality. GIS allows Web users to connect directly to the enterprise database system to query locations for analyses, including high-accident locations and alcohol-related incidents. The system allows the retrieval of individual incident reports or custom summarized reports for data elements. Extracting data is a core function that allows users to bring raw data into their own systems for further analysis. A user can also use the online statistical analysis package to analyze data directly from the open portal. The Iowa Department of Transportation has created a custom desktop interface to link users to its wide array of system databases. The interface contains limited GIS mapping of incidents and a data-export module to help users bring incident reports into their own applications for further analysis. Iowa's system comes with advanced statistical analysis and charting capabilities as well as a portal to Intersection Magic for diagramming of incidents at specific intersections. Illinois utilizes a heavy GIS component in its analysis and reporting. The GIS component allows for general mapping and visualization of incidents. Custom reports can be generated with graphical components embedded. The GIS integrates facility and infrastructure data such as roads, bridges, and railroads into the analytical capabilities. Illinois also maintains Internet access to summarized quarterly reports for download. In evaluating data analysis and reporting best practices, it is worth considering the Fatality Analysis Reporting System (FARS). In 1975 the USDOT and NHSTA designed and developed a reporting system for fatal accidents to assist the traffic safety community in identifying problem areas. FARS maintains fatality data for all fifty states including Puerto Rico and the District of Columbia. States are required to submit fatality information to the system within 30 days of the fatality. Fatality information is then made avail-able on an annual basis to Federal, state, and local municipalities as well as private groups and research organizations. The system records 100 data elements that are derived from accident, vehicle, driver, and person reports. Each element is standardized and entered on custom FARS report forms for submission to the national system. Some progressive states are including in their FAR report forms plans for automatic FARS reporting to eliminate some of the paperwork involved in meeting the FARS requirements. Among the innovations in analysis and reporting that add value to a user's daily workflow, GIS provides a good graphical component that helps users visualize trends that might not be apparent in a simple tabular format. GIS also allows users to query information at varying levels of geography as opposed to the traditional intersection or area query. The ability to generate custom reports reduces the need for data export, ensuring that the user is

analyzing the most current information available. The usage of centralized statistical analysis and charting tools help enforce data consistency across an organization in outputs as well as using the most current data available. 2.4.4 Accessibility While all the aforementioned systems and technological innovations can dramatically increase an organization's efficiency, the time and resources that are recovered can quickly disappear if users do not have adequate access to the tools and data. Waiting for exported data or specialized software installations can be time-consuming and costly. This has directed the most progressive states toward Internet/intranet solutions that run within stable Internet browsers such as Internet Explorer and Netscape. Kentucky is the leader in data and tool accessibility. Its Web-based system allows users 24/7 access to its information resources. The Web solution enables GIS mapping, summarized database query and export, and individual incident-report lookup. Over 120 agencies within the state and FHWA have direct access to these tools, including 90 predefined management and statistical reports. Iowa also has a progressive accessibility innovation, but it does require users to have licensed GIS software to fully utilize the capabilities. The GIS allows users direct access to the enterprise system from their desktops for data export, spatial query, and mapping. The Iowa system's custom interface allows all users access to the custom analytical tools and database queries directly from their desktops. 2.4.5 Overall Efficiency One of the driving objectives for an improved crash management system for ADOT is to improve the overall efficiency of its practices to collect, store, maintain, and analyze crash data. Improving efficiency will reduce the demand for resources and allow the state to direct the funds toward other important safety-related activities. Kentucky and Iowa exemplify optimal operation efficiency. Through the utilization of its systems, Kentucky has eliminated its entire backlog of incident reports. Its databases are now day-current through the utilization of electronic data entry and electronic data transfer for reports that are entered by hand in the office. By using a single, shared repository for data storage and a Web-deployed interface for minimize staff involvement in the data-entry process and ensure data consistency for end-users. The Web portal also gives managers and analysts quick and seamless access to the necessary resources to achieve decreased response time for critical safety issues. Iowa's TraCS system maximizes readily available data in the data-collection stage, reducing data-entry time and duplicate data entry. The associated business rules mitigate the need for additional staff intervention to validate and do quality control on incident records. Automatic electronic data-transfer processes distribute incident records to all necessary agencies, eliminating the need for end-users to export data from the enterprise system for

Table 1. System Design Recommendations Best Practice Components Data collection System Design Recommendations Electronic data entry Field-based data entry Domains for validation Business attribute rules Automatic data collection from swipe cards/bar code readers GPS locator GIS field display for locating Automatic element entry from remote databases Data collection standards (MMUCC) Data storage Analysis and Reporting Utilize RDBMS Additional enterprise database integration Generate custom ad-hoc reports Custom data queries Data export to multiple formats User friendly GIS capabilities Insert GIS graphics into reports Access to previously generated reports Advanced statistical analysis Chart and graph capabilities Links for additional databases for advanced analysis Accessibility Centralized web application One-stop portal for all information All information is live linked to enterprise data Password security

analysis and reporting. The desktop interface puts custom tools and reporting capabilities at managers' and analysts' fingertips. The use of electronic, field-deployed data entry and electronic data transfer are dramatically reducing staff involvement in the data-collection process. Enterprise database systems are providing quick and seamless data access to those who need the information. Specialized tools on the desktop, or the Internet, are providing managers and analysts quick access to tools and to reports that used to take significant amounts of time to generate. 2.5 IDEAL SYSTEM COMPONENTS The five areas highlighted in this report ? data collections, data storage, analysis and reporting, accessibility, and overall efficiency ? constitute the necessary system components for a comprehensive crash-data system (Table 1). The ideal crash-data system will incorporate the best practices identified for each area, improving system performance, increasing efficiency, and minimizing critical resources. The system starts with data collection. States like Kentucky and Iowa have proven that electronic, field-based data entry and electronic data transfer can expedite data entry and increase efficiency by reducing staff involvement in these processes. This also increases data consistency and accuracy though the use of data element standards and business rules for data validation and QA/QC. The use of an open RDBMS for data storage allows great flexibility in data accessibility and analysis. The integration of outside databases is also very beneficial. Direct links to systems such as facility, average statistics, citation, driver, and vehicle databases prove to be positive. The ideal configuration of analysis and reporting components varies with needs, but a few specific functions and capabilities should be targeted. The ability to generate custom reports and queries from a centralized location seems to provide optimal efficiency for end-users and managers. User-friendly GIS capabilities should be included to perform mapping and analysis with integration into reports to add a graphical component. A system should include access to previously generated reports for easy access and download. The ability to perform advanced statistical analysis and charting by pulling data directly from the enterprise database, ensures the most current information is being used. For accessibility, it is apparent that a Web-based application for data retrieval and analysis provides the most access to the most users. 2.6 BEST PRACTICES CONCLUSION Several states have created efficient and innovative practices to handle crash data. Most efficiency has been gained through automation of frequent processes and minimizing or streamlining data-collection efforts. The less staff intervention, the less time and resources are spent to get the data to analysts and decision-makers. Enterprise databases and common access points increase data accuracy and overall utilization of these systems, leading to safer transportation systems. While the initial cost of these systems and integrations can be high, the return on investment can be quickly realized as staff interaction decreases. The savings can result in cost-cut through reduced need to hire additional staff or redirection of valuable staff time for other safety-related activities.

Table 2. Interview Participants Organization ADOT Department/Group/Section Hazard Elimination Safety Risk Management Traffic Records Transportation GIS TPD ATRC City of Mesa City of Phoenix City of Glendale City of Tempe Maricopa Association of Governments Pima Association of Governments University of Arizona Arizona Dept. of Public Safety Arizona Tribal Council FHWA ITS Engineering Development Planning Safety Traffic Studies Street Transportation Information Systems Transportation Transportation Department

3. USE CASE

In order to create a strategy for ADOT to move its systems into a best practice level for analyzing crash data, its current systems and environment must be defined. A use case study was designed to analyze ADOT's current desires, assets and capabilities, and workflows. This section highlights the methods and results from the use case study, which feeds into the gap analysis along with the results from the best practices study. 3.1 INTRODUCTION A use case study is a multi-level research project that identifies the current desires, assets and capabilities, and workflows for a particular organization. This kind of study delves into the specifics of an organization, resulting in a broad and complete understanding of its business practices. A use case study can be composed of interviews, surveys, document reviews, and data analysis. For ADOT's crash data collection and analysis system study, a combination of interviews and data analysis was used to define ADOT's current assets and capabilities. The research team visited ADOT's facilities and conducted interviews with several key players responsible for crash data, and also interviewed personnel of external entities such as the Federal Highway Administration (FHWA), regional governments, and local municipalities. Some additional interviews were conducted over the phone and through email. ADOT's existing data was also reviewed. Three areas were identified as critical for appropriately defining ADOT's business practices: Internal Desires, Existing Assets and Capabilities, and Workflows. This report has a section on each. The Internal Desires section identifies the current desires expressed by the various users of ADOT's systems and data. These desires fall into the five best practices groups of Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. The section of Existing Assets and Capabilities highlights ADOT's current systems, databases, GIS capabilities, analytical tools, reporting tools, and data sharing. The Workflow section identifies data collection components and data flow from organization to organization. Once all of ADOT's current assets and workflows were identified and its staff's desires defined, a comparison could be made between ADOT's current systems and the ideal system components from the best practices survey. This comparison is called a Gap Analysis, and the results from this analysis are included in this report. 3.2 METHODOLOGY To facilitate the use case study, the research team conducted a series of on-site interviews to identify needed information. These interviews provided the team with detailed descriptions of the desires, systems, and assets currently in place among Arizona's crash data stakeholders. It was not feasible to interview all stakeholders throughout the state, so representative groups were selected. The groups of people that the research team interviewed are shown in Table 2.

Table 3. User Desires System Components Data Collection ADOT User Desires Paperless incident submission Road open dates Automatic QA/QC procedures Street naming conventions Collect signalized intersections Crash definition standards Collect 1st, 2nd, and most harmful events X,Y for all incidents Data Storage Link State Highway System Log and ALISS Digital storage and retrieval of incident reports Ability to change ALISS ALISS documentation Data sharing between local, regional, and state governments Analysis and Reporting Prioritized accident locations High risk/hazard locations Safety improvement effectiveness Accident and severity rates Automatic FHWA reporting GIS database of safety improvements Intersection Magic integration Auto format data query Accessibility Overall Efficiency Municipal and Regional data access Change management procedures Data one-stop

Some people and groups could not attend the on-site interviews and were contacted via phone and e-mail. In some cases, follow-up information was needed from people interviewed in person, and these individuals were contacted via phone or e-mail to acquire more detailed information. While this report was meant to be inclusive, not all groups were interviewed and, therefore, this report may be lacking certain desires, assets, and capabilities. The interviewees identified several data sources, applications, and reports as critical to the business practices of ADOT and the various other organizations. These components were investigated through independent research techniques that varied depending on the type of source material available. GIS data was evaluated using ESRI software. Reports were reviewed by obtaining samples, and software packages were researched on-line and through contacting the developers. 3.3 USE CASE RESULTS The following subsections describe the findings on the three categories: Internal Desires, Existing Assets and Capabilities, and Workflows. 3.3.1 Internal Desires This section of the report contains the desires expressed by various interviewees. Some of these desires are general ideas to improve system efficiency while others are specific to a particular analysis or business process. During the interview process, participants were given opportunities to tell the research team what would make their daily workflows easier and what items they desired to have to help with their works but currently did not have. These expressed desires are listed in Table 3. To make these desires fit into the context of the gap analysis, the team have grouped them into the five categories identified previously in the best practice survey: Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. Each of the desires is presented in the following. 3.3.1.1 Data Collection Paperless Incident Submission. Great efficiencies could be made by eliminating the need for incident reports to be typed/entered by both the incident officers and ADOT personnel. Currently, all records are submitted in hard copy to ADOT and hand entered into the Accident Location Identification Surveillance System (ALISS). Road Open Dates. There is a desire to know when a road segment is opened for traffic. There needs to be a way to indicate whether an accident occurs prior to a road's being open or after. Automatic QA/QC procedures for data entry. There needs to be greater quality assurance/quality control for improved data accuracy. The use of domains and the integration of additional outside databases would help this initiative. The City of Tempe estimated that 10 percent of records have a minor data entry problem.

Street naming conventions. There is a desire for street naming conventions to be used throughout the database. If a municipality changes the name of a street and it becomes official, the database should reflect the change. Signalized intersection database. An inventory of signalized intersections should be included in the facility database and linked to the ALISS. Crash definition standards. There needs to be an agreement within the highway safety community on exactly what constitutes a particular kind of crash. Currently, end-users sometimes need to alter the crash type to run accurate analysis. Collection of data on harmful events. Field officers currently collect these data elements. Harmful events are "value-added" upon data entry into the ALISS. The practice should be expanded to incorporate up to six events. X,Y coordinates for all incidents. Approximately 80 percent of all incidents have approximate X,Y coordinates. There is a desire for 100 percent and high accuracy because the positional location of the incident determines if it is an intersection accident or is along a particular route. 3.3.1.2 Data Storage Linkage between ALISS and State Highway System Log. The interview with FHWA highlighted this very critical need. The data from ALISS and the State Highway System Log are not easily linked for analysis. These two systems need to be linked to determine accident rates by facility type. More efficient storage and retrieval of original incident reports. Currently, incident reports are stored on microfilm and require manual retrieval, printing, and mailing. Users desire access to the original report to help analyze a specific incident or QA/QC the database. Online or digital access to these reports would save time and effort in obtaining these reports. Ability to change ALISS data fields and data entry form. The current ALISS database and data entry form are not customizable. If a new data element needs to be collected in the future, the current system cannot be altered to accommodate this. Current ALISS documentation. No documentation on the system and data fields were provided when ALISS was delivered, making it extremely difficult to maintain and describe the system. Metadata is required. Data sharing between ADOT, regional, and local governments. Some municipalities correct or update incident records, but do not submit the corrected or updated records back to ADOT for revising its database. In addition, facility information is updated at the local level but only occasionally passed to ADOT.

3.3.1.3 Analysis and Reporting Ability to determine prioritized accident locations. There is a desire to identify the most frequent incident locations (i.e., top 10) for a user-defined geographic area and user-chosen criteria (e.g., vehicle type, pedestrian, etc.). Interviewees also said that it would be beneficial to be able to identify locations that had high priority for improvement for a userdefined geographic area. Several groups mentioned that they do this on a regular basis for their jurisdiction, but it is largely a manual analysis. Identify high risk/high hazard locations. The ability to identify locations of high risk to pedestrians, buses, passenger trains, and cars would be very useful. The ability to examine railroad crossing condition, rail speed and volume along with car speed and volume could identify higher-risk locations for cars near rail lines. High risk and hazard locations could also include exposure to buses, pedestrians, and hazmat vehicles. Safety improvement program effectiveness analysis and accident reduction rate analysis. The capability to analyze improvement programs to evaluate effectiveness for the program is necessary. This would require historical crash data for a location, data for improvement programs (dollars spent, location, improvement), and crash data after improvement. This would answer the question, "Did the improvement work and how well?" Accident and severity rates. It is critical to determine accident/crash rates for road segments and intersections by road type. A disconnect between accidents and facility information prevents this analysis. Also important are the severity rates for accidents. It would be very beneficial to be able to compare crash and severity rates for selected road segments with Arizona statewide and the national averages for a particular facility type. It was also noted that the ability to change the length of a road segment into a "corridor" for crash and severity rate analysis would be useful. Automatic FHWA reporting. Efficiencies could be improved by automating the reporting of data to FHWA. ALISS reports in digital format. Currently the reports coming out of ALISS are SQL printouts and not electronic copy. There is a desire to make electronic copy of these reports by using exporting data into MS Excel spreadsheets. GIS inventory of safety improvements. The ability to consider safety improvements such as barrels, bumpers, and guardrails in analysis would be beneficial. Intersection Magic integration. Many municipalities use Intersection Magic to help visualize and analyze incident information. Efficiencies could be achieved by minimizing data formatting. Auto-format data query. Several analytical systems are in use in Arizona, and each needs data to be in a certain format. The ability to generate custom formats for data export would be very beneficial.

3.3.1.4 Accessibility Municipal/regional government data access. Currently, local government agencies contact ADOT to request incident information for their jurisdictions. These data are queried from the ALISS system and mailed to the local agencies. The efficiency of this process could be greatly increased by providing local government agencies on-line access to the ALISS database to download the crash data for their jurisdictions. 3.3.1.5 Overall Efficiency Change management for altered data standards. All departments and agencies desire better communication so they can share and discuss changes made to the various systems. The example of changing the abbreviation "Av" to "Ave" can cause systems and analysis tools not work properly. Decision support one-stop. There is an expressed desire for one-stop access to data. The ability to go to one source for all data needs would minimize data collection efforts and improve response times. 3.3.2 Existing Assets and Capabilities This section highlights the existing assets and capabilities of the crash data community within Arizona. Systems, databases, analyses, and reporting capabilities are described to set the baseline for the gap analysis in the following sections of this report. While this section is meant to be inclusive of all existing assets, there undoubtedly are assets that were not brought to the attention of the research team. The known existing assets are described below. ALISS is the central repository for crash data within Arizona. This is a Microsoft SQL Server database with Visual Basic forms for data entry. All incidents involving an injury or causing a minimum of $1,000 in property damage are reported to this database for record. Accidents within the jurisdictions of military bases or Indian reservations are not required to be reported, though on occasion some are. Incident records are submitted to ADOT Traffic Records Section for inclusion into the database and are entered by hand into the system by the 12 members of the Traffic Records staff. The data entry system has some domains, or lookup tables, to assist in the data entry process, and there is geocoding functionality in which the system automatically locates approximately 80 percent of all records. Most data elements stored in ALISS are included on the Arizona standardized accident form. The elements not on the form, such as most harmful event, are "valueadded" by Traffic Records Section staff at the time of data entry. The ALISS database has over 115 stored reports that generate hardcopy outputs directly from the database. These reports can have customized parameters set to limit or query certain data elements within the database. These reports are stored within SQL and can be generated by contacting the Traffic Records Section. The ALISS database has export functionality to deliver data to local, regional, and national agencies. Queries can be run to extract information based upon area and are delivered to agencies as comma-delimited text files.

The State Highway System Log stores highway facility information. Data elements include number of lanes, shoulder width, speed limits, lane width, and pavement type. Intelligent Transportation Systems (ITS) apply technology based solutions such as advanced sensors, computers, electronics, and communications technologies, to transportation management to improve the overall safety and efficiency of multimodal transportation systems. ADOT's ITS has several systems and databases providing data to the public on a real-time basis. Weather information, highway restrictions and closures, current traffic speeds, ramp metering, live video feeds, and current accident locations are all components of this system. The Highway Conditions and Reporting System (HCRS), Road Weather Information System (RWIS), Freeway Management System (FMS), Variable-Message Signs (VMS), Traffic-Interchange Signal (TIS), and Closed-Circuit Television (CCT) are all systems utilized by ITS. The Highway Conditions Reporting System (HCRS) maintains information on highway closures, conditions, and maintenance. The Road Weather Information System (RWIS) monitors pavement and atmospheric sensors, then processes this information for display within the ITS system. Intersection Magic is an "out of the box" application designed by Pd' Programming, Inc. This application graphically displays various incidents and some of their attributes at a single intersection. This application is licensed and utilized by several municipalities throughout the state. Data are exported out of ALISS or out of local databases, then manipulated and read by Intersection Magic for display. The Maricopa Association of Governments (MAG) GIS database serves as a warehouse for various transportation-related GIS datasets. GIS layers include roads, traffic flows, and signals within MAG's jurisdiction. These data are updated frequently and are adjusted by working with local municipalities. MAG utilizes EMME-2 software for modeling multimodal traffic planning networks. It utilizes matrix manipulation and other tools to distribute and forecast traffic over an urban or regional area. Traffic forecast periods are usually up to 25 years. As is typical of most traffic planning software, EMME-2 users can alter the analysis portion of the program by changing the matrices, inputting assignment procedures, or using interactive calculators for evaluation and impact analysis. Crash data can be one of the add-ons to the program. If statewide averages/rates are generated for facility types, then crash rates can be predicted for various future-year scenarios to complement the traffic forecasts. The Traffic Records Microfilm Inventory maintains all reported incident forms on microfilm. These original records are submitted to ADOT from various agencies within the state. Each record has a unique identifier that correlates the microfilm record with the record in the ALISS. Microfilm incident reports can be reproduced in a hardcopy format for additional incident record information. Upon request, the original incident report can be printed and mailed to end-users for in-depth analysis.

The ADOT GIS database is currently being migrated from an ArcInfo database to a GeoDatabase with dynamic segmentation and linear referencing. The database will soon sit on a Microsoft SQL server running ArcSDE to serve desktop clients. Also under development is an ArcIMS Website to allow Internet access to the database. The GIS database contains information on roadways, intersections, traffic flow directions, and other facility information in addition to base map information. ADOT's GIS has several analytical functions. An ArcIMS Website would allow users to build custom maps from the Arizona Transportation Information System (ATIS) library. The ArcView 3.x extension program allows users with ArcView 3.x to view and analyze geospatial information, including facility information. There is functionality to geocode information from the ALISS database, a GPS tool for collecting information, and tools for integrating bridge and railroad crossings. The GIS is based upon linear referencing technology and therefore allows for incident analysis along a route not just at an intersection. ADOT's Data Warehouse is a data storage and retrieval system designed to be a one-stop location for data access. The warehouse has a query wizard at its front end for data retrieval and export. The Data Transformation Services (DTS) software running on top of the database perform cleansing routines, geocoding, and data validation to help load and export data. Currently, the system is accessible on the ADOT intranet, and all information has the geographic component of a route/milepost. The ADOT Data Warehouse has built- in query and export functions to help end-users acquire safety related data. Route and milepost can be used to define areas for data queries as well as custom-data-element queries. The returned data can then be exported in tabular format for use in analysis. There are 50-60 stored queries to expedite the data retrieval process. Several municipalities' traffic safety departments maintain and use local databases to store their own incident records. Some choose to enter incident records into their local databases and then send the incident report to ADOT, while others wait for ADOT to process the incident report to enter incident records, request the records, and then populate their databases with the ADOT records. These databases are often updated by correcting data entry errors in the ADOT record and are therefore potentially more accurate. Local municipalities have reporting capabilities to generate reports for pedestrian, bicycle, and fatal incidents. They also have analytical capabilities to determine the top 10 high-risk locations for incidents by types such as angles, striping, and visibility. Some municipalities have the ability to geocode their incident data by utilizing GIS software. Some local municipalities have automated tools for formatting data from ADOT to support their analysis routines. Several groups that use Intersection Magic have automated their data from ADOT into the Intersection Magic format to reduce data processing time prior to analysis. Others run ADOT's data through routines that geocode incidents, allowing GIS systems to read these data for advanced analysis using geography. The Traffic Accident Data System (TADS) is a system being developed by the City of Phoenix Police Department that utilizes field-based data collection and entry for incident reports. These reports are electronically transferred into the police database and made available for analysis instantaneously. Soon these records will be submitted electronically to ADOT's ALISS.

The State Maintained Streets Photo Log is available for all to use. This log has captured photos from along all state maintained streets within Arizona. 3.3.3 Workflows There are several different workflows or dataflows within the crash data community in Arizona. Each of these workflows is highlighted in Figure 4 to show general movement of data throughout the community. Each community is different, but each will typically follow one of these models in getting data to and from the ADOT ALISS. In smaller municipalities across Arizona, the police department collects information using a hand-written, field-based form. This form is then photocopied and sent to ADOT for entry into ALISS. ADOT receives the form and hand-enters the data elements. On a periodic basis, the municipality requests the data and an export file is generated and sent to the safety or traffic engineering department of the municipality. The municipality then manipulates the file format, performs a QA/QC check, and analyzes the data. Some progressive municipalities store the data in a database for future use once they receive the file from ADOT. On occasion, the municipality will notify ADOT of errors in the data for correction in ALISS, though this is not common. In medium and large municipalities, the common system is for the police department to collect incident information using a hand-written, field-based form. The form is taken to the office, where the data is hand-entered into the municipality's incident database. An incident report is generated, printed, and mailed to ADOT for hand entry into ALISS. Most municipalities that use this workflow do not request the data back from ADOT, as they already have the information in their own systems. The traffic engineering or safety department then requests the data from the incident database and formats the data as necessary for its analyses. The City of Phoenix police collect incident data via a field-based data-collection system that transmits data directly to the police department's database. Soon this database will electronically submit the accident report directly to ALISS. Once the data is in ALISS, the city requests that the relevant data be sent to the appropriate city personnel, where the data are entered into their system and formatted for analysis. Once a record has reached ALISS, queries are run to distribute data to various other agencies upon request. Groups such as MAG, PAG, and internal ADOT groups request this data for their analyses. Each group must format the data for use in its own analysis systems. ALISS also generates reports for groups such as FHWA and the Fatality Analysis Reporting System (FARS). Frequently, the ALISS data is sent to ADOT's Data Warehouse for query by those who have access to ADOT's intranet.

ADOT Traffic Records Crash Records Data Flow INPUT FLOW INTO ALISS - 135,000 Crash Records per Year

Crash Data Sources Municipalities, Arizona Department of Public Safety - Highway Patrol

Hard Copies

ADOT Traffic Records Receiving Clerk and Information Processing Specialist (Level 2)

2-6 Week DELAY

Hard Copies Sorted by Month and by Fatality Status

Target for Crash Data entry into ALISS: 8 weeks

Hard Copies Non- Fatalities

Hard Copies Suspected Fatalities

Hard Copies Data Problem

ADOT Traffic Records 9 Information Processing Specialists (Level 2)

FARS/Contractors

ADOT Traffic Records 3 Lead Information Processing Specialist (Level 3) Hard Copies Data Problem Resolved

2 - 3 Day DELAY

Up to 3-4 Week delay

Hard Copies Determined as Fatalities

Hard Copies Microfilm copy created

Hard Copies Crash Data Entered into ALISS

Hard Copies Crash Data Entered into FARS

FARS

ADOT Traffic Records

ALISS

Note: 1.

Figure 4. Crash Records Data Flow

ALISS stands for Accident Location Identification Surveillance System. FARS stands for Fatality Analysis Reporting System

4. GAP ANALYSIS

This section of the report is a comparison between the ideal system components from the best practices report and the existing capabilities and assets from the use case study. The gap analysis highlights the deficiencies of the current system and outlines the steps needed to bridge the gaps between existing and proposed systems. It feeds into the third and final part of the study, the technical memorandum. 4.1 INTRODUCTION The best practices report is broken down into five sections: Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. The ideal system components are taken directly from these sections and will serve as the goals for ADOT to aspire to in developing its systems. The gap analysis below compares these ideal components with capabilities and assets already in place within the crash data community. These assets and capabilities were previously defined within the use case study. The outputs from the comparison result in the gap analysis, which then feeds into the technical memorandum. The internal desires section of the use case is also a portion of the gap analysis. These desires serve as additional goals for Arizona's crash data community, whether the desire is expressed as a best practice or not. Internal desires detailed in previous sections of this document will not be repeated in the gap analysis unless the desire is particular to a specific ideal system component. All identified desires are in the technical memorandum, however. 4.2 METHODOLOGY To identify all the components necessary for the gap analysis, a best practice report and a use case study were conducted. The best practice report began with an on-line survey to identify the states that utilized technology to achieve the best practices in data collection, data storage, analysis and reporting, accessibility, and overall efficiency. This survey identified the states of Kentucky, Iowa, Massachusetts, and Illinois as having best practices in at least one of these areas. These states were then examined for specific aspects that improved user efficiency. The most efficient practices were used to define the ideal components for a crash data system and were fed into the gap analysis as a target for ADOT to aspire to. The use case consisted of a series of interviews with many of the stakeholders within Arizona's crash data community. The use case interviews focused on internal user desires, existing assets, existing capabilities, and workflows. Aspects of each section were defined for each group and passed to the gap analysis Once all the necessary information was gathered, a comparison was undertaken to highlight system deficiencies. These deficiencies in combination with the expressed desires not encompassed by the ideal system components are the output for the gap analysis and serve as specific goals for the crash data community within Arizona.

Best Practice Component System Design Recommendation Reduce Staff Intervention Improve Analysis Capabilities

Recommendation Benefits Timely More Improve Accurate Management Efficiency Decisions Data

Improve Reporting Capabilities

Electronic data entry

Field-based data entry

Domains and business attributes for validation

Data Collection

Automatic data collection from swipe cards/bar code readers GPS/GIS for incident locating

Data collection standards

Automatic data entry from remote databases

Data Storage

Use RDBMS

Figure 5. Best Practice Benefits

Additional enterprise database integration

Custom reports and queries for export

Multiple format and customizable data export

User friendly GIS

Analysis and Reporting

Advanced statistics, charting and graphing

Access to previously generated reports

Accessibility

Links to additional data resources for advanced analysis Centralized web application that is live linked to enterprise data One-stop portal for all information

Password security

4.3 BEST PRACTICE RESULTS The five areas highlighted in the best practices report--data collection, data storage, analysis and reporting, accessibility, and overall efficiency-- define the ideal system components for a comprehensive crash-data system. The ideal crash-data system incorporates the best practices to improve system performance, increase efficiency, and minimizes critical resources (Figure 5). Based upon these factors, the system starts with data collection. States like Kentucky and Iowa have proven that electronic, field-based data entry and electronic data transfer can expedite data entry and increase efficiency by reducing staff involvement in these processes. This also increases data consistency and accuracy through the use of data element standards and business rules for validation and QA/QC. The next system component comes from the data storage realm. The use of an open RDBMS allows for great flexibility in data accessibility and analysis. The integration of outside databases is also very beneficial. Direct links to systems such as facility, average statistics, citation, driver, and vehicle databases prove to be beneficial. The ideal configuration of analysis and reporting components varies with desires, but a few specific functions and capabilities should be targeted. The ability to generate custom reports and queries from a centralized location seems to provide optimal efficiency for endusers and managers. User-friendly GIS capabilities should be included to perform mapping and analysis with integration into reports to add a graphical component. A system should include access to previously generated reports. The ability to perform advanced statistical analysis and charting using data directly from the enterprise database ensures that the most current information is being used. For accessibility, it is apparent that a Web-based application for data retrieval and analysis provides the greatest access to the most users. 4.4 USE CASE RESULTS The areas of focus for the use case study ? existing assets and capabilities, and workflows ? define the current operating environment for the crash data community in Arizona. Systems and databases are defined and analysis and reporting capabilities are identified, giving an overall picture of crash data collection and analysis. Although the City of Phoenix Police Department is experimenting with electronic collection of field data to help efficiency Arizona mainly uses hand-written field reports for data collection of incidents. These hand-written reports are then either entered into local databases or passed directly to ADOT for entry into ALISS. In the event that the local municipality enters the data into a local system, the report is still passed to ADOT's ALISS as a hardcopy printout. ADOT staff manually enter all incident records into ALISS for storage. The incident records are geocoded to a location and certain data elements are "value-added." The hard copy is then copied to microfilm for storage. Incident records are

exported from the database and sent to an agency when it requests them. Most agencies reformat ALISS export data to make it acceptable for analytical software such as a GIS and Intersection Magic. Stored queries and reports generate frequently utilized analyses and summaries of incidents in hard copy. The ALISS database is routinely updated in the ADOT Data Warehouse for query and is downloaded through ADOT's intranet. The Data Warehouse stores a variety of transportation-related data, including facility information, and it provides customizable queries to users for data download. The ADOT GIS Section provides access to GIS data, allowing users to visually represent incident records for spatial analysis. 4.5 COMPARISON The ideal system components are compared with the use case components to identify gaps in Arizona's crash data systems. The comparison is organized by the five system components: data collection, data storage, analysis and reporting, accessibility, and overall efficiency. Each component is briefly discussed in the following. The overall output is highlighted in the last section of this report. 4.5.1 Data Collection The best practice in data collection utilizes field-based electronic data entry with a handheld unit or a laptop computer. The incident form contains domains and business attribute rules for data validation QA/QC. The form utilizes automatic data entry from vehicle and driver's license databases as well as global positioning system (GPS) for GIS locating. The incident form also conforms to MMUCC data element standards. The electronic incident forms are automatically transferred to the central repository, and the database is updated without user intervention (Table 4). Table 4. Current Practices ? Data Collection Best Practice Field-based electronic data collection (laptop or Personal Digital Assistant (PDA)) Business attribute rules and domains for QA/QC Automatic data entry from external database (D.L., vehicle) GIS or GPS locating in field unit MMUCC standards Electronic data transfer of incident records ADOT Current Practice Phoenix only. Rest of state uses paper data collection Some domains and business rules None None Essentially compliant None

Arizona's crash data community is beginning to explore some of these system components, but none has been universally adopted. The City of Phoenix is beginning to use field-based, electronic data entry, but the rest of the state is using hard-copy incident reports that are

sent to the central repository. ALISS does employ domains and business attribute rules to help data validation and consistency, and these rules can be expanded to automate data entry routines. GIS and GPS positional attributes are not entered into the report until the report is received at ADOT. Data collection routines do not currently use vehicle registration, driver's license and other outside databases to help the data entry process. Arizona does conform to several Model Minimum Uniform Crash Criteria (MMUCC) dataelement standards. 4.5.2 Data Storage The best practice in data storage uses Relational Database Management Systems (RDBMS). RDBMS has the core functionality of linking to other enterprise databases, allowing users to explore and analyze data not contained within the primary database. These databases can include driver's licenses, vehicle registrations, crime records, transportation facilities, weather, traffic counts, statewide averages, and so on (Table 5). Arizona utilizes a RDBMS to store incident records. Arizona also maintains several other enterprise databases, but none is actively linked to ALISS. The ATIS system is a very good start in relating additional information, but it does not include incident records. Table 5. Current Practices ? Data Storage Best Practice Utilize RDBMS Link or Relate Other Enterprise Databases ADOT Current Practice Utilize RDBMS None

4.5.3 Analysis and Reporting Best practices in analysis and reporting allow users live access to the central repository for incident reports. Such access allows the generation of custom ad-hoc or previously generated reports. Users have access to custom data queries with the ability to export these selected data in several different formats. More advanced systems allow the user to define the fields and formatting of the data export for direct integration into analytical and chart/graphing software packages. These systems employ user-friendly GIS capabilities and the ability to export GIS graphics and analysis results into reports for visualization. Advanced statistical analysis is available as well as external data from related databases (Table 6). Arizona has several of these analysis and reporting components, but most are not quite best practices. Users have access to custom and stored reports from the ALISS by requesting hard copies from the Traffic Records Section at ADOT. Users can also receive custom data queries in multiple formats through the same request system. However, users can only manipulate the format of the output once the data is sent to them. The system does not contain the functionality to specify the formatting of the data structure on export. Users do not have access to the live database, only to data that has been exported by request or through the ADOT intranet to the data warehouse. ADOT does provide advanced GIS

capabilities to users with ArcView 3.x software through the distribution of the ATIS library. Users without GIS software do not have access to any GIS function. Users must rely on their own software for advanced statistical, charting, and graphing functions. Data within the data warehouse do have common linking elements of route and milepost to serve as an ad-hoc relation amongst databases. However, these databases are not completely related, thus requiring additional user intervention to analyze data together. Table 6. Current Practices ? Analysis and Reporting Best Practice Live access to central repository for incident records Custom ad-hoc reports or access to Previously generated reports Custom data queries Export data in multiple formats User defined export formatting User-friendly GIS for analysis and reporting Advanced charting, graphing and statistical analysis Access to external data sources ADOT Current Practice None Can be requested from Traffic Records Can be requested from Traffic Records Can be requested from Traffic Records None User-friendly GIS, however ALISS is not GIS Friendly Users must rely on their own software packages Access is available via the Data Warehouse

4.5.4 Accessibility The Best Practice for data accessibility is a one-stop portal for information. This can be very difficult to achieve, given the magnitude of transportation information available and needed throughout the community, but recent innovations in Web technology have accomplished this task. Centralized Web-based applications are providing users the ability to perform all the best practices analysis and reporting functions from one spot. Web applications typically are accessible 24/7 and have password security to prevent unauthorized access to sensitive information. Information and data sources are live-linked to databases and warehouses, allowing users to access the most up-to-date information (Table 7). Arizona users have access to data resources, but most resources require staff to query the database, export the required data, and send the data to the end users. There are automated data-access tools associated with the data warehouse, but the crash data is not live-linked to the warehouse and users only have access if they can get to the ADOT intranet. The data warehouse is designed to be a one-stop portal to transportation data, and it does a good job

of storing and retrieving data. Unfortunately, the warehouse is only available to ADOT users. The only centralized Web application is for real-time traffic information through the ITS system, and this system does not include incident or facility information. Table 7. Current Practices - Accessibility Best Practice One-Stop portal for information Centralized Web-based application Security for sensitive information Access to live data and databases ADOT Current Practice Data warehouse provides access to ADOT users None Sensitive information not available None

4.5.5 Overall Efficiency The key best practice for overall efficiency involves automation and reduction of staff involvement in day-to-day operations. Items like electronic data transfer and electronic field-based data entry highlighted in the data collection section contribute to overall efficiency. Customizable data query for export from a live system eliminates staff burden for data requests and reduces time for end-users to receive and manipulate data for analysis. One-stop portals reduce the time users spend on searching for data, allowing for more in-depth analyses that were once prohibited by time constraints. Centralized tools give all users access to analytical capabilities, reducing resources required at the local and regional levels and allowing these resources to be better allocated into the safety environment. Arizona has opportunities to improve the overall efficiency. Several agencies enter incident records into their own systems, then the same record is reentered into ALISS, duplicating effort. Electronic data transfer would minimize repetitive entry, thus saving significant resources. Deploying field-based electronic data entry for officers would reduce the duplication of effort by the data entry staff and would improve efficiency. A one-stop portal for data download would free staff resources now used to query and export data for local, regional, and national users. The integration of online tools would reduce software licensing costs and provide greater accessibility to a larger number of users, thus creating a safer environment for all. 4.6 GAP ANALYSIS RESULTS The following sections give the results from the gap analysis with the results of the internal desires section of the use case. While Arizona's crash data community utilizes a few best practice elements, several gaps remain to be filled (Table 8). Table 8 highlights the areas where improvements are needed to bring Arizona up to the best practice levels for crash data

Table 8. Gap Closure Best Practice

Field-based electronic data collection Business attribute rules and domains for QA/QC Automatic data entry from external database GIS or GPS locating in field unit MMUCC standards Electronic data transfer of incident records Utilize RDBMS Link or relate other enterprise databases Live access to central repository for incident records Custom ad-hoc reports or access to previously generated reports Custom data queries Export data in multiple formats User-defined export formatting User-friendly GIS for analysis and reporting Advanced charting, graphing and statistical analysis Access to external data sources One-stop portal for information Centralized Web-based application Security for sensitive information Access to live data and databases

ADOT Current Practice

Phoenix only, rest of state uses paper data collection Some domains and business rules None None Essentially Compliant None Utilize RDBMS None None Can be requested from Traffic Records Can be requested from Traffic Records Can be requested from Traffic Records None User-friendly GIS, however ALISS is not GIS Friendly Users must rely on their own software packages Access is available via the data warehouse Data Warehouse provides access to ADOT users None Sensitive information not available None

Gap Closure

Promote more field-based electronic data collection Expand where applicable Need to integrate external databases and utilize swipe cards or barcode scanners Need to deploy GIS of GPS to field for incident locating Meets Best Practice Need to promote electronic data transfer of incident records Meets Best Practice Need to integrate other enterprise databases Need to make database accessible to users Need to give users access to this functionality Need to give users access to this functionality Need to give users access to this functionality Need to give users access to this functionality GIS Meets Best Practice, but ALISS needs GIS improvements Better access to tools would be beneficial Better, more integrated access would be beneficial Provide access to the rest of the crash data community Need to create portal Create access to data and generate security requirements Grant access to user community

systems. The results are divided into the five best practice components. These results are in the technical memorandum portion of the study for inclusion into the system designs and overall recommendations. 4.6.1 Data Collection Arizona should utilize electronic, field-based data entry and electronic data transfer. This effort should include the creation of browse lists of standard terms and business attribute rules for automated QA/QC and standardization of data elements. Global Positioning System receivers and a geographic information system should be field-deployed to each officer's laptop computer to use in recording the X,Y coordinates of incident locations, which should be stored with each incident record. This will improve the accuracy of positional data in the database. External database systems, such as those for vehicle registrations and driver's licenses, should be integrated with the system to minimize manual data entry. Additional MMUCC data elements should be collected at the scene, including first and second harmful events. The user community should standardize data elements for street naming and crash definitions. Signalized intersections and road contract release dates should be collected and maintained. 4.6.2 Data Storage Arizona should integrate additional data sources into ALISS. The State Highway System Log should be the primary source from which facility information is attached to the incident record, which would allow statewide averages to be calculated. Driver's license, vehicle registration, weather, traffic volume, and other databases should also be integrated into an enterprise system of transportation-related databases. ALISS needs detailed system documentation and the ability to manipulate the database structure and a Visual Basic data entry form to allow for any changes in the future. 4.6.3 Analysis and Reporting Arizona should automate its data reporting and exporting routines, giving users direct access to the live system and allowing for customizable data export formats. On-line functionality should be improved to include GIS, advanced statistical analysis, and graphic and charting capabilities. This on-line access point should be built as a one-stop access point for data and analysis, including digital ALISS reports and automated FHWA and FARS reporting. The system should allow generation of statewide averages by facility type, identification of top 10 crash locations for a given area by type of crash or type of facility, identification of high risk / high hazard locations, the ability to assess the effectiveness of an improvement, accident and severity rates, and Intersections Magic diagramming. Basic and user-friendly GIS diagramming and mapping should also be a functional element. 4.6.4 Accessibility Arizona should grant access to all users within the crash data community through an Internetbased application and a one-stop portal for data access and analysis. A 24/7 solution would provide the greatest access and flexibility for end users.

4.6.5 Overall Efficiency Arizona should eliminate redundant and duplicate data entry. Online and customizable data download, centralized access to tools and data, and live linkages for custom reporting will minimize staff intervention at all levels. Inter Tribal Council of Arizona (ITCA) According to Esther Corbett of the Inter Tribal Council of Arizona (ITCA), only a few of the 21 Native American tribes in Arizona provide regular FARS data, and most do not have facilities to keep crash records. What exist are paper records. Tribes have been willing to participate in studies, but have received no benefit from the studies. Therefore, they are reluctant to participate in further activities. ITCA did a multidisciplinary study of 3 tribes, and as a result obtained $12,000 for implementation of a POLARIS Crash System and an Access Database Management System. The Navaho Nation has since implemented a database and has a Highway Safety group, but how the data is distributed or used beyond internal tribe postings is not well documented. Their website is: www.navajo.org. Law enforcement and public health agencies on the reservations are other hurdles to data collection. The tribes and the Bureau of Indian Affairs (BIA) law enforcement officers use the standard Arizona Highway Patrol (AZ HP) accident report forms. However, record keeping on crashes is sporadic for both types of agencies. Another possible way of gaining the information is from hospital records of the Indian Health Services, however some tribes have started their own hospitals, which complicates data collection. The BIA has a Road Inventory, however tribes do not have access to it. ITCA feels that the tribes need to be informed of the importance of crash data for planning and funding of activities. If the tribes can be persuaded to collect and provide the data, then Memorandums of Understanding can be executed for data sharing. 4.7 GAP ANALYSIS CONCLUSION Arizona's crash data community has a significant number of desires and therefore requires an advanced system to meet them. The results of the best practices, use case, and the gap analysis have highlighted the general system requirements for a best practice system for Arizona. These system requirements are fed into the final portion of this study, the technical memorandum, where the desires are weighed against the practicality and the costs associated with meeting them. All practical components are investigated and detailed to allow ADOT to weigh all options before deciding where to proceed in addressing the desires of the crash data community. The specific components are outlined with a cost estimate and roadmap for their implementation, as well as an overall system design.

5. TECHNICAL MEMORANDUM

This technical memorandum proposes ways to meet ADOT's desires and provide solutions to the gaps identified during the previous portions of this study. An overall systems design strategy as well as individual system components are discussed to provide ADOT with specific courses of action to reduce the resources needed in the collection and analysis of crash data. The benefits, components, implementation steps, and costs associated are all outlined below. 5.1 INTRODUCTION This memorandum addresses four overall goals. These four goals follow the same categories discussed throughout the study: Data Collection, Data Storage, Analysis and Reporting, and Accessibility. The fifth goal of overall efficiency will be met with the achievement of the other four goals. For each goal specific system components are given that help achieve the best practices. Once each component has been discussed, an overall system design is described that is an inclusive solution to all the desires of the crash-data community. The study team realizes that a comprehensive solution is probably not economically feasible for ADOT, and the final section of this report gives implementation steps by their recommended priority. This technical memorandum allows ADOT to pick and choose individual components to meet its desires. The section on each component has a very rough estimate of the costs associated with implementing that component. Dollar figures are estimated from the cost an outside firm would charge for these services and do not reflect any costs that could be saved by having DOT staff perform some or all of the tasks. The technical memorandum portion of this report does not constitute the formal recommendations of the study team. The formal recommendations and their costing are outlined in the final section of this report - Recommendation and Implementation Strategy. 5.2 OVERALL GOAL ? MORE EFFICIENT AND ACCURATE DATA COLLECTION 5.2.1 Solution: Electronic Data Entry (EDE) Benefits EDE optimizes data collection by digitally capturing information at the incident location. Digitally collected information at the incident location minimizes the chance of interpretation errors when the officer returns to the office to enter the information. EDE reduces data collection and entry time by inserting information directly into a system. The time needed to collect information is also reduced by the use of domains (pick lists), minimizing the amount of information that must be typed into the system. These

domains also promote data accuracy and consistency by eliminating typing errors and variations such as "Ave" or "AV" in abbreviations for "Avenue." EDE allows for numerous other capabilities that can improve data collection, such as electronic data transfer, automatic data entry from other data sources, and GIS/GPS integration. Most incident responders already have a computer, and this functionality can be developed within that context. This should require minimal amounts of new equipment acquisition. Components EDE requires that a field response unit have either a laptop computer or a handheld device for data entry. An application is required for a data entry form and the storage of the record once it is entered. This application should be developed with domains and business attribute rules for data standardization and validation. The application will also need an export function to transfer the electronic record to the local agency's database or to ADOT directly. Implementation To properly implement this component, a laptop computer or a handheld device must be deployed to any individual who responds to incidents. Therefore, an inventory must be taken to identify the number of new hardware units required. The inventory should also include the type of units in the field, as that will be critical in the software development. Next, an application needs to be developed that works on the many platforms already in existence. The application should be very user-friendly and should utilize domains and business attribute rules for data consistency and validation. The export routine should have both hardcopy and digital capabilities to support the needs of any organization. The software should be tested prior to a full implementation. Users will require a small amount of training to properly utilize the system. Costing Table 9 shows the estimated costs of implementing electronic data entry. Table 9. Costing ? Electronic Data Entry Component Hardware inventory Hardware (computer) Hardware (Personal Digital Assistant (PDA) Custom data-entry and storage software Domains & business attribute rules Export routines Installation Training Total (not including hardware) Cost $20,000 $2,000/ea $750/ea $65,000 $20,000 $25,000 $100,000 $75,000 $305,000

5.2.2 Solution: Electronic Data Transfer (EDT) Benefits Electronic data transfer eliminates the need for duplicate data entry by automatically sending the electronic incident record to the local database and to ADOT's incident database. This component should be enabled with electronic data entry. This component can be configured to transmit an incident record instantaneously after it is created through the use of radio telemetry, cell phones, or satellite-based Internet, or the records can be transmitted at the end of a shift when the officer returns to the office and connects to a wireless LAN. EDT can still be implemented if a municipality's police department does not use field EDE, but has its staff enter incident information at the office when officers return. When the records are entered into the local system, the municipality can send ADOT an electronic copy via the Internet instead of sending hardcopies. The municipality can send records individually or as a batch. Components EDT requires that Electronic Data Entry has been enabled in the field or that incident records are entered into a database system at a local office. A small export routine is required to package incident records into a format that can be transferred. For ADOT to implement EDT, it needs a small import routine that will accept the export and correctly load the record into the ADOT database. ADOT will need to establish a staff workflow routine to verify that records are being sent to ADOT and are being correctly imported into the system. Implementation To implement EDT, agencies must first implement Electronic Data Entry at either the office or in the field. A small study will need to be undertaken to inventory the datacollection methods of each response unit within the state. This study will identify the number of different systems within the state for which export routines must be created. The small export routine will package each record into a transferable file. There are multiple methods that can transfer the file to ADOT's database for import. A small import procedure needs to be created to accept and import the records.

Costing Table 10 shows the estimated costs. Table 10. Costing ? Electronic Data Transfer Component Data-collection inventory Export routine Import routine Installation Training Workflows Staff @ 10 hours/wk Cost $25,000 $20,000 $25,000 $100,000 $50,000 $10,000 $20,000

Total $250,000* *Training and installation costs can be eliminated by implementing at the same time as electronic data entry. It is anticipated that one staff member will be required to facilitate Electronic Data Transfer. This position will probably require 10 hours per week to ensure that transfers are properly entering the system. A successful candidate for this position should have one year of database experience and an understanding of crash data for QA/QC procedures. 5.2.3 Solution: GIS/GPS Integration Benefits Integrating GIS and GPS can greatly improve the accuracy of incident locations. Only the officer in the field knows exactly where the incident occurs, and he or she should be the one to enter the precise location of the incident on the record. GPS can provide the exact X,Y coordinates to enter onto the form, or a GIS can be used to find the exact location. Using GIS also brings general GIS functionality to the officer in the field for other activities, such as routing, base map information, and other analytical capabilities. A GIS can be integrated into the existing field-based computing hardware within the response vehicle. It can put aerial photography, infrastructure information, and crime data at the responder's fingertips. Free GIS reader software can be deployed to users with no additional licensing costs. Components A GIS requires a laptop computer or a handheld computing device to operate. It also requires a small software application and a published data package for the user. A customized application will need to be written to easily return the X,Y coordinates of a

location for input on the incident record. GPS requires a GPS receiver (hardware) on each response unit. No customized software is required. Implementation To implement a GIS, data must first be acquired to create base maps for responders to use. Either an application needs to be written to easily return the X,Y coordinates of a selected location, or, with appropriate training, a user could obtain the X,Y coordinates from the existing GIS software. The software and data need to be bundled for distribution and instal

Description

Rating
TITLE	Crash data collection and analysis system
CREATOR	Cherry, Ed;
SUBJECT	Traffic accidents--Arizona;
Browse Topic	Transportation
DESCRIPTION	91 pages (PDF version). File size: 407.793 KB. "Final report 537." "February 2006." Performed by ARCADIS G&M, Inc., sponsored by the Arizona Dept. of Transportation in cooperation with U.S. Dept. of Transportation, Federal Highway Administration under contract no. SPR-PL-1-(61) 537
Language	English
Contributor	ARCADIS Geraghty & Miller, Inc;
Publisher	Arizona. Dept. of Transportation.
TYPE	Text
Material Collection	State Documents
Acquisition Note	Publication or link to publication sent to reports@lib.az.us
RIGHTS MANAGEMENT	Copyright to this resource is held by the creating agency and is provided here for educational purposes only. It may not be downloaded, reproduced or distributed in any format without written permission of the creating agency. Any attempt to circumvent the access controls placed on this file is a violation of United States and international copyright laws, and is subject to criminal prosecution.
DATE ORIGINAL	2006-02
Time Period	2000s (2000-2009)
ORIGINAL FORMAT	Born Digital
Source Identifier	TRT 1.2:C 61
Location	64446463
DIGITAL IDENTIFIER	AZ537.pdf
DIGITAL FORMAT	PDF (Portable Document Format)
REPOSITORY	Arizona State Library, Archives and Public Records--Law and Research Library.
File Size	407.793 KB
Full Text	CRASH DATA COLLECTION AND ANALYSIS SYSTEM Final Report 537 Prepared by: Ed Cherry, Rob Floyd, Tyson Graves, Steve Martin, David Ward ARCADIS G&M of North Carolina, Inc. 8222 South 48th Street, Suite 149 Phoenix, AZ 85044 February 2006 Prepared for: Arizona Department of Transportation 206 South 17th Avenue Phoenix, Arizona 85007 In cooperation with US Department of Transportation Federal Highway Administration DISCLAIMER The contents of this report reflect the views of the authors who are responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the Arizona Department of Transportation or the Federal Highway Administration. This report does not constitute a standard, specification, or regulation. Trade or manufacturers' names which may appear herein are cited only because they are considered essential to the objectives of the report. The U.S. Government and the State of Arizona do not endorse products or manufacturers. Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. FHWA-AZ-06-537 4. Title and Subtitle 5. Report Date Crash Data Collection and Analysis System 7. Author February 2006 6. Performing Organization Code 8. Performing Organization Report No. 10. Work Unit No. 11. Contract or Grant No. Ed Cherry, Rob Floyd, Tyson Graves, Steve Martin, David Ward 9. Performing Organization Name and Address ARCADIS G&M of North Carolina, Inc. 8222 South 48th Street, Suite 149 Phoenix, Arizona 85044 12. Sponsoring Agency Name and Address SPR-PL-1-(61) 537 13.Type of Report & Period Covered Arizona Department of Transportation Final Report 14. Sponsoring Agency Code 206 S. 17th Avenue Phoenix, Arizona 85007 15. Supplementary Notes Prepared in cooperation with the U.S. Department of Transportation, Federal Highway Administration 16. Abstract The Arizona Department of Transportation (ADOT) is responsible for ensuring the safety and operational efficiency of Arizona's state highways. Fulfilling that responsibility requires extensive data collection and analysis, which are very labor-intensive resource-intensive. Seeking to identify how the agency could accomplish the greatest service improvements with the most efficient use of funds, ADOT engaged ARCADIS to perform a Crash Data Collection and Analysis study and examine the possibilities offered by technological innovations such as Electronic Data Entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). The study resulted in a comprehensive report with three components: an examination of best practices in use in the United States today, a use case and gap analysis examining ADOT's current data work, and a technical memorandum outlining how changes could be implemented. Together, the three parts point to a path to introduce best practices in ADOT's crash-analysis systems. Adopting the best practices outlined can reduce the resources required to maintain these systems, freeing those resources to other safety-related concerns. 17. Key Words 18. Distribution Statement 23. Registrant's Seal Crash Data, Best Practices, Use Case, Gap Analysis, Technical Memorandum, Crash Analysis, GIS, RDBMS. 19. Security Classification 20. Security Classification Document is available to the U.S. Public through the National Technical Information Service, Springfield, Virginia, 22161 21. No. of Pages 22. Price Unclassified Unclassified 87 SI* (MODERN METRIC) CONVERSION FACTORS APPROXIMATE CONVERSIONS TO SI UNITS Symbol When You Know Multiply By To Find Symbol Symbol APPROXIMATE CONVERSIONS FROM SI UNITS When You Know Multiply By To Find Symbol LENGTH in ft yd mi Inches Feet Yards Miles 25.4 0.305 0.914 1.61 millimeters meters meters kilometers mm m m km mm m m km millimeters meters meters kilometers LENGTH 0.039 3.28 1.09 0.621 inches feet yards miles in ft yd mi AREA in2 ft2 yd2 ac mi2 fl oz gal ft3 yd3 square inches square feet square yards Acres square miles fluid ounces Gallons cubic feet cubic yards 645.2 0.093 0.836 0.405 2.59 square millimeters square meters square meters hectares square kilometers milliliters liters cubic meters cubic meters mm2 m2 m2 ha km2 mL L m3 m3 mm2 m2 m2 ha km2 mL L m3 m3 Square millimeters Square meters Square meters hectares Square kilometers milliliters liters Cubic meters Cubic meters AREA 0.0016 10.764 1.195 2.47 0.386 square inches square feet square yards acres square miles fluid ounces gallons cubic feet cubic yards in2 ft2 yd2 ac mi2 fl oz gal ft3 yd3 VOLUME 29.57 3.785 0.028 0.765 VOLUME 0.034 0.264 35.315 1.308 NOTE: Volumes greater than 1000L shall be shown in m3. MASS oz lb T Ounces Pounds short tons (2000lb) 28.35 0.454 0.907 grams kilograms megagrams (or "metric ton") Celsius temperature g kg mg (or "t") ? MASS g kg Mg grams kilograms megagrams (or "metric ton") Celsius temperature 0.035 2.205 1.102 ounces pounds short tons (2000lb) oz lb T TEMPERATURE (exact) ? TEMPERATURE (exact) C ? F Fahrenheit temperature foot candles foot-Lamberts Poundforce poundforce per square inch 5(F-32)/9 or (F-32)/1.8 C 1.8C + 32 Fahrenheit temperature foot-candles foot-Lamberts poundforce poundforce per square inch ? F ILLUMINATION fc fl lbf lbf/in2 10.76 3.426 4.45 6.89 lux candela/m2 newtons kilopascals lx cd/m2 N kPa lx cd/m2 N kPa lux candela/m2 newtons kilopascals ILLUMINATION 0.0929 0.2919 0.225 0.145 fc fl lbf lbf/in2 FORCE AND PRESSURE OR STRESS FORCE AND PRESSURE OR STRESS SI is the symbol for the International System of Units. Appropriate rounding should be made to comply with Section 4 of ASTM E380 TABLE OF CONTENTS EXECUTIVE SUMMARY ...................................................................................................... 1 1. INTRODUCTION ................................................................................................................ 7 2. BEST PRACTICES.............................................................................................................. 9 2.1 INTRODUCTION .................................................................................................................9 2.2 METHODOLOGY.................................................................................................................9 2.3 SURVEY RESULTS ...........................................................................................................10 2.4 SELECTED STATES BEST PRACTICES.........................................................................13 2.5 IDEAL SYSTEM COMPONENTS.....................................................................................19 2.6 BEST PRACTICES CONCLUSION...................................................................................19 3. USE CASE........................................................................................................................... 21 3.1 INTRODUCTION ...............................................................................................................21 3.2 METHODOLOGY...............................................................................................................21 3.3 USE CASE RESULTS.........................................................................................................23 4. GAP ANALYSIS ................................................................................................................ 31 4.1 INTRODUCTION ...............................................................................................................31 4.2 METHODOLOGY...............................................................................................................31 4.3 BEST PRACTICE RESULTS .............................................................................................33 4.4 USE CASE RESULTS.........................................................................................................33 4.5 COMPARISON ...................................................................................................................34 4.6 GAP ANALYSIS RESULTS...............................................................................................37 4.7 GAP ANALYSIS CONCLUSION ......................................................................................40 5. TECHNICAL MEMORANDUM ..................................................................................... 41 5.1 INTRODUCTION ...............................................................................................................41 5.2 OVERALL GOAL ? MORE EFFICIENT AND ACCURATE DATA COLLECTION ....41 5.3 OVERALL GOAL ? ENTERPRISE DATABASE SYSTEM INTEGRATION ................49 5.4 OVERALL GOAL ? IMPROVEMENT OF ANALYTICAL AND REPORTING CAPABILITIES...................................................................................................................54 5.5 OVERALL GOAL ? MORE EFFICIENT DATA AND ANALYSIS ACCESS ................65 5.6 IDEAL SYSTEM DESIGN .................................................................................................69 5.7 OVERALL IDEAL SYSTEM DESIGN IMPLEMENTATION .........................................69 6. RECOMMENDATION AND IMPLEMENTATION STRATEGY.............................. 73 6.1 INTRODUCTION ...............................................................................................................73 6.2 STRATEGY.........................................................................................................................73 6.3 OVERALL PRIORITIZED IMPLEMENTATION.............................................................77 APPENDIX A. SURVEY QUESTIONS............................................................................... 79 LIST OF TABLES TABLE 1. SYSTEM DESIGN RECOMMENDATIONS ....................................................................... 18 TABLE 2. INTERVIEW PARTICIPANTS ......................................................................................... 20 TABLE 3. USER DESIRES............................................................................................................ 22 TABLE 4. CURRENT PRACTICES ? DATA COLLECTION............................................................... 34 TABLE 5. CURRENT PRACTICES ? DATA STORAGE .................................................................... 35 TABLE 6. CURRENT PRACTICES ? ANALYSIS AND REPORTING .................................................. 36 TABLE 7. CURRENT PRACTICES - ACCESSIBILITY...................................................................... 37 TABLE 8. GAP CLOSURE ............................................................................................................ 38 TABLE 9. COSTING ? ELECTRONIC DATA ENTRY ...................................................................... 42 TABLE 10. COSTING ? ELECTRONIC DATA TRANSFER............................................................... 44 TABLE 11. COSTING ? GIS IMPLEMENTATION .......................................................................... 45 TABLE 12. COSTING ? GPS IMPLEMENTATION.......................................................................... 45 TABLE 13. COSTING ? MMUCC DATA ELEMENTS ................................................................... 46 TABLE 14. COSTING ? AUTOMATIC DATA POPULATION............................................................ 47 TABLE 15. COSTING ? DOMAINS AND BUSINESS ATTRIBUTE RULES......................................... 48 TABLE 16. COSTING ? CRASH DEFINITION STANDARDS............................................................ 49 TABLE 17. COSTING ? NEW ALISS........................................................................................... 51 TABLE 18. COSTING ? INTEGRATE STATE HIGHWAY SYSTEM LOG ........................................... 52 TABLE 19. COSTING ? INTEGRATE DATA WAREHOUSE SYSTEM ............................................... 52 TABLE 20. COSTING ? DIGITAL INCIDENT REPORT STORAGE.................................................... 54 TABLE 21. COSTING ? ADVANCED STATISTICS, CHARTING, AND GRAPHING CAPABILITIES ..... 55 TABLE 22. COSTING ? USER FRIENDLY GIS TOOLS .................................................................. 56 TABLE 23. COSTING ? SIGNALIZED INTERSECTIONS.................................................................. 57 TABLE 24. COSTING ? PRIORITIZED ACCIDENT LOCATIONS ...................................................... 58 TABLE 25. COSTING ? HIGH RISK/HAZARD ACCIDENT LOCATIONS .......................................... 59 TABLE 26. COSTING ? SAFETY IMPROVEMENT EFFECTIVENESS ................................................ 60 TABLE 27. COSTING ? ACCIDENT AND SEVERITY RATES .......................................................... 61 TABLE 28. COSTING ? STREET NAMES AND ALIASES................................................................ 61 TABLE 29. COSTING ? CONTRACT RELEASE DATES .................................................................. 62 TABLE 30. COSTING ? DATA SHARING AMONGST ADOT, LOCAL, AND REGIONAL AGENCIES 63 TABLE 31. COSTING ? INTERSECTION MAGIC INTEGRATION ..................................................... 64 TABLE 32. COSTING ? MOST HARMFUL EVENTS....................................................................... 65 TABLE 33. COSTING ? WEB PORTAL AND DATA ONE-STOP...................................................... 67 TABLE 34. COSTING ? CUSTOM, STORED, AND HISTORICAL REPORTS...................................... 68 TABLE 35. COSTING ? USER DEFINED DATA EXPORT FORMATTING ......................................... 69 TABLE 36. OVERALL SYSTEM COSTING .................................................................................... 71 TABLE 37. STEP 1 NEW ALISS ................................................................................................. 74 TABLE 38. STEP 2 ALISS AND TRANSPORTATION GIS INTEGRATION ...................................... 74 TABLE 39. STEP 3 ELECTRONIC DATA TRANSFER ..................................................................... 75 TABLE 40. STEP 4 WEB ACCESS FOR DATA QUERY AND DOWNLOAD....................................... 75 TABLE 41. STEP 5 ACCIDENT AND SEVERITY RATES DATA....................................................... 76 TABLE 42. STEP 6 ADDITIONAL DATA COLLECTION EFFORTS .................................................. 76 TABLE 43. STEP 7 ELECTRONIC DATA ENTRY........................................................................... 77 TABLE OF FIGURES FIGURE 1. FIGURE 2. FIGURE 3. FIGURE 4. FIGURE 5. FIGURE 6. CRASH-DATA SYSTEMS STUDY ? PROJECT DESIGN...................................................6 BEST PRACTICE SURVEY RESULTS ? STATE RANKINGS PER CATEGORY.................. 10 BEST PRACTICE SURVEY RESULTS ? STATE RANKINGS OVERALL........................... 10 CRASH RECORDS DATA FLOW ................................................................................. 30 BEST PRACTICE BENEFITS ....................................................................................... 32 OVERALL IDEAL SYSTEM DESIGN............................................................................ 70 GLOSSARY OF ACRONYMS ADOT AIDW ALISS ATIS ATSIP BIA CAD CCT CODES CRASH DMV EDE EDT FARS FHWA FMS GIS GPS HCRS ISTEA ITCA ITS MAG MVD MMUCC NHSA NHSDA NHTSA PDA QA/QC RDBMS RWIS SHL TADS TEA TIS TraCS TRB VMS Arizona Department of Transportation ADOT Information Data Warehouse Accident Location Identification Surveillance System Arizona Transportation Information System Association of Transportation Safety Information Professionals Bureau of Indian Affairs Computer-Aided Dispatch Closed-Circuit Television Crash Outcome Data Evaluation System Collision Report Analysis for Safer Highways Department of Motor Vehicles Electronic Data Entry Electronic Data Transfer Fatality Analysis Reporting System Federal Highway Administration Freeway Management System Geographic Information Systems Global Positioning System Highway Conditions and Reporting System Intermodal Surface Transportation Efficiency Act Inter Tribal Council of Arizona Intelligent Transportation System Maricopa Association of Governments Motor Vehicle Division Model Minimum Uniform Crash Criteria National Highway Safety Act National Highway System Designation Act National Highway Traffic Safety Administration Personal Digital Assistant Quality Assurance/Quality Control Relational Database Management Systems Road Weather Information System State Highway Log Traffic Accident Data System Transportation Efficiency Act Traffic-Interchange Signal Traffic and Criminal Software Transportation Research Board Variable-Message Signs EXECUTIVE SUMMARY The Arizona Department of Transportation (ADOT) is responsible for the safety and operational efficiency of Arizona's state highways. Fulfilling that responsibility requires extensive data collection and analysis, which are labor-intensive and resource-intensive. Seeking to identify ways the agency could accomplish the greatest service improvements with the most efficient use of funds, ADOT engaged ARCADIS to perform a Crash Data Collection and Analysis study and examine the possibilities offered by technological innovations such as Electronic Data Entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). The study resulted in a comprehensive report with three components: an examination of best practices in use in the United States today, a use case and gap analysis examining ADOT's current data work, and a technical memorandum outlining how changes could be implemented. Together, the three parts point to a path to introduce best practices in ADOT's crash-data analysis related database systems. Adopting the practices outlined below can reduce the resources required to maintain these systems, freeing those resources to other safety-related concerns. BEST PRACTICES To identify the states whose system components can be considered best practices ARCADIS conducted a survey. Based on the survey results, leading states were selected for more in-depth analysis. The research team examined five components of each selected state's crash-data analysis system: data collection, data storage, analysis and reporting, accessibility, and overall system efficiency. The best innovations within each component were then combined to form an ideal system that would maximize efficiencies for any crash-data system, including ADOT's. Some states have proven that electronic, field-based data entry and electronic data transfer (EDT) can expedite data entry and increase efficiency. Reducing data entry points and electronically transferring data increase data consistency and accuracy through the use of data element standards and business rules for validation and quality assurance/quality control (QA/QC). The use of an open RDBMS provides great flexibility in data accessibility and analysis. Direct links to outside databases such as facility, citation, drivers' license, and vehicle registration databases are beneficial. The ideal configuration of analysis and reporting components varies with needs, but ADOT should target specific functions and capabilities. Among them: ? The ability to generate custom reports and queries from a centralized location that optimizes efficiency for end-users and managers. ? User-friendly GIS capabilities that integrate mapping and spatial analysis into reports. ? Easy access to and downloading of previously generated reports. ? The ability to perform advanced statistical analysis and charting by pulling data directly from the enterprise database to ensure that the most current information is used. 1 ? A Web-based application for data retrieval and analysis that provides the greatest data access to the most users. USE CASE AND GAP ANALYSIS A use case study is a multi-level research that identifies current desires, assets, capabilities, and workflows for a particular organization. A gap analysis discovers where the current system falls short of best practices. Among the conclusions: ? Arizona should utilize electronic, field-based data entry and electronic data transfer. Those processes should use domains and business attribute rules for automated QA/QC and standardization of data elements. X,Y coordinates of accident locations should be determined and recorded from the Global Positioning System (GPS) or Geographic Information Systems (GIS) with every incident record to improve accident positional accuracy. External database systems, such as vehicle registration and driver's license databases, should be integrated into an enterprise system of transportation-related databases to minimize data entry. Personnel at crash scenes should collect more Model Minimum Uniform Crash Criteria (MMUCC) data elements, including harmful events1. The user community should standardize data elements for street naming and crash definitions. Signalized intersection and road contract release dates2 should be collected and maintained. Arizona should integrate additional data sources to the Accident Location Identification Surveillance System (ALISS). The State Highway Log (SHL) system should be the primary source of facility information that is attached to the incident record, allowing statewide average of incidents to be calculated by facility. The current ALISS lacks detailed system documentation and the ability to manipulate the database structure as well as a visual data entry form to accommodate any changes in the future. Arizona should automate its data reporting and data exporting routines, giving users direct access to a live crash-data analysis system and allowing them to analyze the data and generate custom reports for export. On-line functions should include GIS, advanced statistical analysis, and graphic and charting capabilities. This on-line access point should be built as a one-stop access point for data and analysis and should include access to digital ALISS reports. The system should also be designed to automatically submit data to the Federal Highway Administration (FHWA) and Fatality Analysis Reporting System (FARS). It should allow users to: ? generate statewide averages of accidents by facility type. ? ? 1 Harmful events are defined as a series of related incidents within an accident or a crash. For example, in a car crash one car rear-ends another car and the struck car then runs into a third car. Then, this car crash will have two harmful events, the first involves the first and second cars and the second involves the second and third cars. First, second, third harmful events and so on indicate the order of the incidents that occur within an accident. Of all the harmful events involved in an accident, most harmful event is the most severe incident that causes the most damage or injury. 2 A Contract Release Date is the official date on which a highway agency takes control of the road or intersections maintenance from a construction contractor and open the road for traffic. 2 ? generate lists of top ten accident locations for a given area by facility type. ? identify high-risk/hazardous locations. ? assess the effectiveness of improvements ? calculate accident and severity rates over identified stretches of highway ? draw diagrams using Intersections Magic. Basic and user-friendly GIS diagramming and mapping should also be functional. ? Arizona should grant access to its crash-data analysis system to all users within the crash data community through an Internet-based application and a one-stop portal for data access and analysis. A 24/7 solution would provide the greatest access and flexibility for end users. Arizona needs to eliminate redundant data entry. On-line and customizable data downloads, centralized access to tools and data, and live linkages for custom reporting will minimize staff intervention at all levels. ? A use case study delves into the specifics of an organization, resulting in a broad and complete understanding of its business practices. For the ADOT study, a combination of interviews and data analysis defined current assets and capabilities. ARCADIS visited ADOT's facilities and interviewed several key players responsible for crash data, as well as people at external entities such as the Federal Highway Administration (FHWA), regional governments, and local municipalities. Three areas were identified as critical for appropriately defining ADOT's business practices. These were internal desires, existing assets and capabilities, and workflows. The internal desires section of this report identifies the current desires expressed by the various users of ADOT's systems and data. The desires are apportioned among the five components used to identify best practices: data collection, data storage, analysis and reporting, accessibility, and overall efficiency. The existing assets and capabilities section gives an overview of ADOT's current systems, databases, GIS capabilities, analytical tools, reporting tools, and data-sharing. The workflows identify data flow and timeframes for getting these data to and from ADOT systems. TECHNICAL MEMORANDUM The technical memorandum of this report proposes solutions to the desires and gaps identified during the earlier portions of the study. It lays out specific course of action to reduce the resources ADOT must allocate to collect and analyze crash data. The strategy aims at delivering the most capability for the least funding while building toward an ideal crash data collection and analysis system. Step 1 ? Creation of a new ALISS database To accomplish the goals set forth in the previous portions of the study, a new database system must be devised to store and retrieve incident records. Generating accident and severity rates, analyzing safety improvement effectiveness, and prioritizing accident locations by facility type all require linking the ALISS and ADOT Information Data 3 Warehouse (AIDW) databases. Unfortunately, the current ALISS is neither documented nor customizable, making it difficult to establish this linkage. Either funding needs to be applied to the ALISS to document it and make it customizable, or a new system needs to be developed. The project team recommends creating a new ALISS based upon a GIS system and using an RDBMS and ArcSDE. This will provide the basis for a relationship between the AIDW and the ALISS while utilizing software capabilities already in place within ADOT. The new ALISS will need a new interface for data entry and minimal training for current data-entry staff. Once the database is created, the records in the current ALISS must be migrated to the new system. The new system should take advantage of MMUCC standards for data elements with the understanding that not all elements are currently collected in the field. As more agencies move toward electronic data entry, the ability to collect additional MMUCC elements may become available. The database should be designed to incorporate this possibility. The data elements of first, second, and most harmful events should also be incorporated. This change will require an alteration of the accident data collection form. The existing stored reports in the current ALISS will need to be migrated to the new system. These reports are very important to the crash data community as a whole, and the system would be taking a step backward if they were lost in the conversion. Step 2 ? Integrate the new ALISS with the current GIS infrastructure and the data warehouse ADOT GIS is undergoing a migration to a new geodatabase data structure for maintaining roadway information. This system is linear-referenced with dynamic segmentation and is capable of storing a variety of facility information in the relational database scheme. The project team recommends integrating the ALISS with the new GIS roadway database and the AIDW. This will provide all facility information in a GIS format that can be analyzed with the new ALISS. Steps one and two are the most important aspects of this implementation plan and should be performed concurrently to maximize interoperability and minimize cost. Step 3 ? Create Electronic Data Transfer (EDT) routines ADOT is duplicating a significant amount of effort by not accepting electronic transfer of incident records. Several municipalities type incident records into a database system in their offices, only to then send a hard copy to ADOT for entry into the ALISS. The project team recommends that ADOT accept EDT and create import routines and workflows to support this initiative. This will involve a study to determine all the possible data import formats in the systems that the various agencies use for their incident records. The team believes that there are probably only five or six different systems in use and the creation of the import routines should only require minimal effort. Each record should contain the same data elements, minimizing the complexity of creating the import routines. 4 Step 4 ? Create web access to integrated databases for data query and download Staff resources are required to distribute ALISS data to users both within ADOT and externally. This can be eliminated by utilizing existing software within ADOT GIS. ArcIMS is a Web-based application that allows display, query, and download of GIS data through the Internet at a user's discretion. When the ALISS is integrated with the AIDW and the ADOT GIS database, users can access data through the ArcIMS Website. Basic GIS functionality is inherently available to all users who have access to the Website. This will also provide live access to the ALISS, ensuring that users get up-to-date information for their analyses. ArcIMS can be designed to only display and export information that is not sensitive, or a security system can be implemented to grant or deny users access to sensitive data. Step 5 ? Accident and severity rates database With the linkage among the ALISS, AIDW, and GIS databases, accident and severity rates can be calculated for facility types by numerous factors, including vehicle type, driver's age and gender, weather condition, and geography. These rates should be incorporated into a database for all to use. This database can be created without staff involvement other than routine database administration. Once the database is built, updating the rate values can be automated. These calculations are relatively simple within a GIS system and can be provided through the ArcIMS Website with minimal effort. A study should be undertaken to decide which rate calculations will be made available, including rates by time and geography (i.e. weekly, monthly, yearly by county, ZIP code, region, by facility, type, age, weather, etc.). The study will drive the database design, the number of execution statements required, and the frequency of the rate updates. The rates will then be tied to the appropriate highway GIS features for inclusion into the overall system for users to analyze. This database feasibility is currently being researched by the Maricopa Association of Governments (MAG) and its progress should be monitored. Step 6 ? Additional data collection efforts All analytical capabilities start with good data resources. The collection of data about signalized intersections, contract release dates, and safety improvements would grant users analytical capabilities that they currently do not have. Most of these data should already be maintained by various agencies, including ADOT, and need only to be found and integrated into the GIS system. Some of these data demand more resource to be integrated than others, but the level of effort deeded for the data integration cannot be quantified until the data resources can be found and analyzed. Step 7 ? Electronic data entry It would be optimal for the state to embrace electronic data entry for all incident records. This may not be feasible due to financial limitations, but ADOT should promote its use whenever possible in the hopes that eventually this will become a reality. 5 needed to bridge the gaps between the existing and proposed systems. The final portion of the study was a Technical Memorandum listing specific steps and resources required to implement the output from the Gap Analysis. The result of this three-part study is the steps necessary to introduce best practices in ADOT's crash-analysis systems and, as a result, reduce the resources required to maintain these systems and allow resources to be reallocated toward additional safetyrelated concerns. ADOT Crash-Data Systems Study Best Practices -Industry Goals, Standards, and Success -Proven Technologies Technical Memorandum -Desired Capabilities -Needed Resources to Achieve Capabilities -Functional System Design Gap Analysis -Current System Deficiencies Use Case -Internal Needs -Existing Assets and Capabilities -Workflows Figure 1. Crash-Data Systems Study ? Project Design 6 1. INTRODUCTION The Arizona Department of Transportation (ADOT) is responsible for the safety and operational efficiency of Arizona's state highways. Additionally, the National Highway Safety Act (NHSA) of 2003 mandates that ADOT collect and report crash information. All levels of government use this information in analyses to identify areas where safety is a critical concern and improvements could be made, and to measure the overall effectiveness of the safety improvements. The crash data-collection techniques and analytical processes are very labor-intensive and resource-intensive. They place a significant burden on budgets, especially during times of dwindling financial resources. ADOT engaged the services of ARCADIS for a Crash Data Collection and Analysis study to develop alternatives to mitigate some of these intensive processes through technological innovations such as electronic data entry (EDE), Relational Database Management Systems (RDBMS), and Geographic Information Systems (GIS). To help identify the most appropriate and cost-beneficial solutions for ADOT, a multi-part study was proposed with the following objectives: ? ? ? ? ? to identify and research current ADOT databases and systems to leverage existing information assets to support crash data analysis. to identify internal and external users' need for crash data and analysis to support their safety-analysis functions. to determine ADOT's current processes for collecting crash data and documenting workflows. to research the industry's current crash data analysis best practices for application at ADOT. to define system requirements (data, procedures, tools, and applications) for use by ADOT and local jurisdictions to effectively identify, analyze, map, and report crash information and safety enhancements. to develop and present an implementation plan for improving crash data collection and analysis. ? To achieve these objectives, this comprehensive study was produced with three report products (Figure 1). The first component of the study was a Best Practices review of other states' crash systems. This highlights some of the most efficient and technologically advanced systems in use around the country. The best practices of these states served as a benchmark for ADOT to meet or surpass in developing or improving its own systems. The second component was a Use Case study and Gap Analysis. The Use Case was an indepth study of ADOT's desires and current system components of ADOT's existing crash systems. Once ADOT's current systems were defined and its desires and goals were identified, a gap analysis highlighted the deficiencies of the current system and the steps 7 needed to bridge the gaps between the existing and proposed systems. The final portion of the study was a Technical Memorandum listing specific steps and resources required to implement the output from the Gap Analysis. The result of this three-part study is the steps necessary to introduce best practices in ADOT's crash-analysis systems and, as a result, reduce the resources required to maintain these systems and allow resources to be reallocated toward additional safetyrelated concerns. 8 2. BEST PRACTICES This section of the study used a research-based approach to determine how leading states handle crash-data systems and to report on the benefits of their techniques. The innovative and efficient practices identified serve as benchmarks to which ADOT can aspire in migrating its crash data systems. 2.1 INTRODUCTION In 1991, the Intermodal Surface Transportation Efficiency Act (ISTEA) required states to have highway safety management systems (Section 1034), with a goal of reducing the number and severity of traffic crashes. In 1995, the National Highway Systems Designation Act (NHSDA) made the implementation of safety management system and other selected management systems optional, while maintaining the required reporting. TEA 21 (1998) and subsequent reauthorizations still require that basic crash-data be compiled by each state. They also require data uniformity so data can be exchanged between states and compared. While states must comply with this legislation, each state has a different method of compliance. Each state has been given the flexibility to control its own crash-data system, and thus there are 50 different crash-data systems. Standardization efforts span multiple states, but each state has its own needs and its system can be remarkably different. This, however, creates wonderful possibilities for ADOT to learn from other organizations. To help realize these possibilities, this best practices review has been undertaken to examine each state's system. To help identify the states that have system components that can be considered best practices, the research team conducted a survey. This survey asked questions designed to highlight efficient and innovative practices in crash-data systems. From the survey results, leading states were selected for more in-depth analysis of the factors that make their systems stand out as best practices. The team examined each selected state for five components: data collection, data storage, analysis and reporting, accessibility, and overall system efficiency. The best innovations within each component were then combined to form an ideal system that would maximize efficiencies for any crash-data system. 2.2 METHODOLOGY To determine the best practices of each of the 49 states surveyed, the research team selected a Web-based electronic survey method. After a contact list for the 49 states' Transportation Departments was compiled, an e-mail was sent inviting each state to respond to questions about its existing crash data system (see Appendix A for survey questions). The data gathered was for descriptive statistical analysis only, due to the qualitative nature of a number of the questions. The descriptive data was analyzed to initially gauge a state's current status and then to narrow down the list to a few states that were considered to have the best practices. The analysis method of the survey was a unique-case orientation. Each state's attributes were compared for data collection, data 9 ARCADIS Crash Data Systems Best Practice Survey 6 5 1-5 R nking S hema a c 4 Dat a Collection Dat a Storage Analysis & Reporting Accessibilt y Overall Efficiency 3 2 1 0 IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV M S Surveyed States Note: The bars are in the same order as in the legend. Figure 2. Best Practice Survey Results ? State Rankings per Category Arcadis Crash Data Systems Survey Sum Ranking Results 5 4.5 4 3.5 1-5 Ranking Schema Note: The bars are in the same order as in the legend. 3 2.5 2 1.5 1 0.5 0 IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV MS Surveyed States IL KY IA MA CA MT SC GA PA VT NM ME MN NJ SD WV MS Figure 3. Best Practice Survey Results ? State Rankings Overall 10 storage, analysis and reporting, accessibility, and overall efficiency. The newest implementation date and years in service as well as the use and innovation of new technologies were weighting factors. The ranking schema follows an order of 1 being the lowest score and 5 the highest. Data collection rank was determined by 5, representing new technology such as GPS, electronic data submission and by the standardization of data entry, and 4-1, representing the degree to which this technology was lacking and the status of any new system to replace the old methods. Data Storage was ranked 1-5 where 5 represents the utilization of a customized Oracle database system and 1 represents the maintenance of and dependence on a mainframe system. Analysis and Reporting was ranked by 5 representing the use and design of technological innovations, such as an enterprise management system and GIS, and 1 representing manual or disconnected applications procedures, which were deemed labor intensive and redundant. Accessibility was ranked 1-5 with data retrieval systems that were accessible via web based applications or linked in real time to many users and clients ranking as 5, and hard copy limited reporting systems ranking as 1. Overall Efficiency was ranked 1 -5 based upon the values obtained from the other factors (Data Collection, Data Storage, Analysis and Reporting, and Accessibility) and how well these factors were designed in relation to each other. An integrated system from data entry to data querying without platform changes and or manual steps that cause impedances to the quality and analysis of crash data would rank as 5. The Sum Ranking of the surveyed states was then averaged into a 1-5 ranking schema where 5 demonstrated the overall best practice ranking. Next, current literature was reviewed, including Transportation Research Board (TRB) reports, reports from leading states, and documentation from the Association of Transportation Safety Information Professionals (ATSIP) annual meetings. Finally the research team identified the components of crash data systems with the best practices and selected the states with comprehensive programs that have these components. 2.3 SURVEY RESULTS The survey's objective was to determine and rank each state's data collection, storage, analysis and reporting methods with regard to the particular crash-data system's overall accessibility and efficiency. The survey results are shown in Figures 2 and 3. Four states stood out for their technical advances and implementation and for their over all system designs and efficiency. These states are Iowa, Kentucky, Illinois and Massachusetts. The questions in the survey focused on operating systems, database management systems and support software for analysis and distribution, and the role of those systems in each state's crash-data system. All states surveyed used a Windows NT, 2000 or XP operating system. The dominant database management system was Oracle, which was either an integral part of the design of each new crash-data system or was being migrated from an antiquated mainframe system. 2.3.1 Data Collection Predictably, survey respondents stressed the need for standardizing data-collection methods and accident forms, and incorporating Global Positioning System (GPS) 11 technology to aid in data accuracy and spatial analysis. Systems such as Traffic and Criminal Software (TraCS) and Model Minimum Uniform Crash Criteria (MMUCC), which will be discussed in following sections, were deemed best practices for collecting and standardizing crash data. The importance of this component was illustrated by Pennsylvania's response, which said that electronic data capture was one of the most advantageous components of its system. 2.3.2 Data Storage As in all computer systems, storage space and methods are always an area of attention for crash data system users and administrators. From the survey findings, the research team concluded that each state customizes database management systems to meet its needs. The majority of respondents had changed this aspect of their systems within the past five years. The robustness of the Oracle or SQL Server components for querying and exporting data made them a best practice among all the states surveyed. In Montana, the Oracle system helps link DOT traffic and facility information to incident records, allowing for advanced queries and analyses. 2.3.3 Data Analysis and Reporting The complexity of crash data has been the motivation for developing many customized analytical software packages. All of the survey respondents used a customized analytical system, and 50 percent of the respondents, including New Mexico, California, South Carolina, and Montana, stressed the importance of integrating GIS and GPS into their analytical procedures. According to the survey results, two factors drive the standardization of crash-data formats and reporting guidelines: the primary end-user's needs for data application and the federal standards of the Federal Highway Administration (FHWA) and the National Highway Traffic Safety Administration (NHTSA). 2.3.4 Accessibility Data collection, data storage, and analysis and reporting played significant roles in determining the accessibility of a state's crash data. There were many variations of by whom and how the data was accessed. The primary users envisioned in designing data access were the traffic safety engineers. Personnel at Departments of Motor Vehicles (DMVs) and Emergency Management Services (EMS) are also data users although they may access and use the data differently. Massachusetts was identified as a best-practice state owing to its use of the Crash Outcome Data Evaluation System (CODES) that integrated many different data-users into one platform. 2.3.5 Overall Efficiency Iowa and Kentucky were ranked highest in Overall Efficiency. Both states are able to collect, monitor, analyze and distribute crash data in real time. Reaching this level is a 12 testament to the ability of these states to implement technological advances in datacollection and querying. The data collected from this survey has been very useful in understanding the broad spectrum of methods and problems related to crash-data systems, and also provided a snapshot of the nations' crash-data systems. However, because the voluntary survey responses to the limited survey questions are widespread, the results of this survey were only able to provide a preliminary exploration of the best practices of transportation departments' crash-data systems. Therefore, the research team further selected four leading states in crash data management for in-depth analysis of their best practices. 2.4 SELECTED STATES BEST PRACTICES In examining crash-data systems to identify innovative and efficient practices in the four states selected for more in-depth analysis, the research team used the same five system components employed in the survey: data collection, data storage, analysis and reporting, data accessibility, and overall resource efficiency. Each state's system identified as having a best practice in one or more of these areas is described below. The result is a list of the components of an overall ideal system. The states selected for in-depth analysis were Kentucky, Iowa, Illinois, and Massachu-setts. While none of the four states should be considered to have best practices through-out its system, a component was selected from each state's system as a best practice that should be considered and assessed for the development of the ADOT system. 2.4.1 Data Collection Data collection is the area where the most states are using technology to improve their crash-data systems. Innovative practices are improving data quality, reducing staff intervention, and expediting data availability within their systems. Of the four selected states, Kentucky, Iowa, and Illinois stand out as leaders in the realm of data collection. Also noteworthy and described below are the MMUCC standards for crash-data collection. While these standards are not considered best practices, they play a very important role in creating an overall model system. Kentucky uses a custom-developed field system for electronic data entry and collection. Led by the Kentucky State Police, 151 agencies in the state have deployed field units into patrol and response vehicles. The field units are equipped with barcode scanners and GPS units to help auto-populate electronic forms from incidents to violations. The system is live-linked to an enterprise database system that contains vehicle and driver data that is automatically transferred to the electronic form, reducing the time needed for data entry and eliminating data-entry errors. This system employs business rules for data validation that enforce data consistency and serve as a first level QA/QC of the entered data. The GPS system automatically inputs the positional location of the incident, allowing spatial display and query downstream. The system records 90 percent of the MMUCC components for 41 percent of all incident records. 13 Iowa has developed and utilizes the TraCS field data-collection system. Several states have adopted this system as the national model for collecting incident data. The system is fielddeployed with an array of barcode scanners, swipe-card readers, digital cameras, GPS units, and touch pads to facilitate automatic and digital data entry. TraCS utilizes the GPS location of the incident to tie-in roadway facility information automatically in addition to automatically populating data elements from vehicle, driver, emergency, and crime databases. TraCS has the additional components of a GIS viewer that helps locate intersections and additional area information, a photo-imaging system to directly attach digital photos to an incident report, and electronic diagramming to sketch incident specifics directly at the scene. This system also has a direct tie-in to Iowa's Computer-Aided Dispatch (CAD) system. Illinois uses a combination of Iowa's TraCS and a custom-developed, field-based dataentry system. The data-entry system is deployed in vehicles and is equipped with GPS units to determine incident locations. The Illinois system is accompanied by a diagramming tool that electronically details the events with graphic representation. The electronic forms have embedded business rules to ensure data consistency and accuracy in entered data elements. The completed records are transmitted electronically to a centralized data warehouse for retrieval by any authorized user. MMUCC is a guideline for minimum, standardized data describing motor vehicle crashes and the vehicles, persons, and environments involved. This guideline was created to ensure that officials collected the information necessary to support analysis to improve highway safety at the state and national levels. The first edition of MMUCC was created in 1998; it was revised in 2003 to include new data elements relevant to emerging highway-safety issues such as distracted driving and use of child restraints. State participation is voluntary; however, the data elements are based upon FHWA and other federal criteria. MMUCC has 111 data elements. Seventy-seven of these elements are to be collected at the scene and include date/time, weather, location, vehicles involved, sequence of events, etc. Ten more elements are derived from the previous elements, and include severity, fatalities, and presence of alcohol. Additional driver information and facility information compose the remaining 24 elements, which are designed to be integrated once the incident is entered into an enterprise database system. Implementing MMUCC has several benefits to agencies responsible for highway safety. MMUCC improves the quality of state and national incident data by forcing data consistency among agencies and enabling data-sharing and analysis among all participants. A data standard also enables software to be developed and shared across multiple agencies, reducing initial costs for system development. The three leading states exemplify innovation and efficiency in data collection. While most states are utilizing resources to enter data that was hand-written and later typed, and then entered into an enterprise database system, the three states are saving critical resources for other programs such as mediation and safety analysis. These time-saving approaches are making incident data available in a matter of hours, as opposed to weeks or months. Also incredibly beneficial is that data are entered once and are validated automatically by 14 business and consistency rules. These rules dramatically reduce data-entry errors and improve the overall accuracy of the database. 2.4.2 Data Storage Data storage is one of the most critical aspects of an efficient system. The development of RDBMS has enabled the seamless storage and retrieval of information to and from almost any application developed within the last several years. The RDBMS database systems reduce the need for manipulating data before transmitting them from system to system, thus saving staff time and resources needed to get information to analysts and decision-makers. All four selected states use an enterprise RDBMS for their data storage systems. Kentucky utilizes a custom database, Collision Report Analysis for Safer Highways (CRASH), for its incident records. This enterprise system accepts electronically transferred incident records from collection agencies and automatically populates the database tables. CRASH not only holds incident records, but also records for all court cases, citations, and firearm registrations. Relationships established among these different data components could support advanced analysis using different information sources. Illinois uses a Microsoft SQL Server database for data storage. The database stores data in a central repository for users to access. Several additional systems link to form a one-stop interface for users to access incident and other related information, thus reducing the need to visit multiple locations for data. Massachusetts employs an Oracle database named CODES. This storage system is part of a national program in which several states participate to help maximize development resources, enforce data consistency, and create data-sharing opportunities. This system uses an enterprising approach that links other databases to form an integrated data solution. EMS, hospital, death, and insurance records are all integrated components of this system. Iowa uses a combination of Oracle, SQL Server, DB2, and Access databases for its data storage. This system accepts electronic field reports and populates the necessary data elements without user intervention. The system then automatically replicates data elements to other databases for use by other agencies, such as FHWA and municipalities. This system also has a direct integration with the state's citation database. While all these states have different approaches to data storage, they all have common components that serve as core efficiencies that need to be noted. Significant time is saved by receiving reports and records electronically with minimal user intervention. The linkages to other enterprise systems enable advanced data analysis. Having the data stored in a RDBMS database makes data sharing and transfer to other systems and users efficient and cost-effective. 2.4.3 Data Analysis and Reporting Data analysis and reporting capabilities vary widely from state to state. Some states are very innovative, connecting their enterprise systems to the World Wide Web to allow 24/7 15 (24 hours a day, 7 days a week) access, while others choose to allow data access only to desktop users. Some systems can generate custom, ad-hoc reports while others only allow predetermined reporting functionality. The research team has found that most states are using or plan to use GIS in the near future to expand their analytical capabilities. Also detailed in this section is the federally mandated reporting system, Fatality Analysis Reporting System (FARS). FARS itself is not a best practice, however the handling of FARS reporting has implications that could lead to a best practice. Kentucky's system features a Web portal with GIS functionality. GIS allows Web users to connect directly to the enterprise database system to query locations for analyses, including high-accident locations and alcohol-related incidents. The system allows the retrieval of individual incident reports or custom summarized reports for data elements. Extracting data is a core function that allows users to bring raw data into their own systems for further analysis. A user can also use the online statistical analysis package to analyze data directly from the open portal. The Iowa Department of Transportation has created a custom desktop interface to link users to its wide array of system databases. The interface contains limited GIS mapping of incidents and a data-export module to help users bring incident reports into their own applications for further analysis. Iowa's system comes with advanced statistical analysis and charting capabilities as well as a portal to Intersection Magic for diagramming of incidents at specific intersections. Illinois utilizes a heavy GIS component in its analysis and reporting. The GIS component allows for general mapping and visualization of incidents. Custom reports can be generated with graphical components embedded. The GIS integrates facility and infrastructure data such as roads, bridges, and railroads into the analytical capabilities. Illinois also maintains Internet access to summarized quarterly reports for download. In evaluating data analysis and reporting best practices, it is worth considering the Fatality Analysis Reporting System (FARS). In 1975 the USDOT and NHSTA designed and developed a reporting system for fatal accidents to assist the traffic safety community in identifying problem areas. FARS maintains fatality data for all fifty states including Puerto Rico and the District of Columbia. States are required to submit fatality information to the system within 30 days of the fatality. Fatality information is then made avail-able on an annual basis to Federal, state, and local municipalities as well as private groups and research organizations. The system records 100 data elements that are derived from accident, vehicle, driver, and person reports. Each element is standardized and entered on custom FARS report forms for submission to the national system. Some progressive states are including in their FAR report forms plans for automatic FARS reporting to eliminate some of the paperwork involved in meeting the FARS requirements. Among the innovations in analysis and reporting that add value to a user's daily workflow, GIS provides a good graphical component that helps users visualize trends that might not be apparent in a simple tabular format. GIS also allows users to query information at varying levels of geography as opposed to the traditional intersection or area query. The ability to generate custom reports reduces the need for data export, ensuring that the user is 16 analyzing the most current information available. The usage of centralized statistical analysis and charting tools help enforce data consistency across an organization in outputs as well as using the most current data available. 2.4.4 Accessibility While all the aforementioned systems and technological innovations can dramatically increase an organization's efficiency, the time and resources that are recovered can quickly disappear if users do not have adequate access to the tools and data. Waiting for exported data or specialized software installations can be time-consuming and costly. This has directed the most progressive states toward Internet/intranet solutions that run within stable Internet browsers such as Internet Explorer and Netscape. Kentucky is the leader in data and tool accessibility. Its Web-based system allows users 24/7 access to its information resources. The Web solution enables GIS mapping, summarized database query and export, and individual incident-report lookup. Over 120 agencies within the state and FHWA have direct access to these tools, including 90 predefined management and statistical reports. Iowa also has a progressive accessibility innovation, but it does require users to have licensed GIS software to fully utilize the capabilities. The GIS allows users direct access to the enterprise system from their desktops for data export, spatial query, and mapping. The Iowa system's custom interface allows all users access to the custom analytical tools and database queries directly from their desktops. 2.4.5 Overall Efficiency One of the driving objectives for an improved crash management system for ADOT is to improve the overall efficiency of its practices to collect, store, maintain, and analyze crash data. Improving efficiency will reduce the demand for resources and allow the state to direct the funds toward other important safety-related activities. Kentucky and Iowa exemplify optimal operation efficiency. Through the utilization of its systems, Kentucky has eliminated its entire backlog of incident reports. Its databases are now day-current through the utilization of electronic data entry and electronic data transfer for reports that are entered by hand in the office. By using a single, shared repository for data storage and a Web-deployed interface for minimize staff involvement in the data-entry process and ensure data consistency for end-users. The Web portal also gives managers and analysts quick and seamless access to the necessary resources to achieve decreased response time for critical safety issues. Iowa's TraCS system maximizes readily available data in the data-collection stage, reducing data-entry time and duplicate data entry. The associated business rules mitigate the need for additional staff intervention to validate and do quality control on incident records. Automatic electronic data-transfer processes distribute incident records to all necessary agencies, eliminating the need for end-users to export data from the enterprise system for 17 Table 1. System Design Recommendations Best Practice Components Data collection System Design Recommendations Electronic data entry Field-based data entry Domains for validation Business attribute rules Automatic data collection from swipe cards/bar code readers GPS locator GIS field display for locating Automatic element entry from remote databases Data collection standards (MMUCC) Data storage Analysis and Reporting Utilize RDBMS Additional enterprise database integration Generate custom ad-hoc reports Custom data queries Data export to multiple formats User friendly GIS capabilities Insert GIS graphics into reports Access to previously generated reports Advanced statistical analysis Chart and graph capabilities Links for additional databases for advanced analysis Accessibility Centralized web application One-stop portal for all information All information is live linked to enterprise data Password security 18 analysis and reporting. The desktop interface puts custom tools and reporting capabilities at managers' and analysts' fingertips. The use of electronic, field-deployed data entry and electronic data transfer are dramatically reducing staff involvement in the data-collection process. Enterprise database systems are providing quick and seamless data access to those who need the information. Specialized tools on the desktop, or the Internet, are providing managers and analysts quick access to tools and to reports that used to take significant amounts of time to generate. 2.5 IDEAL SYSTEM COMPONENTS The five areas highlighted in this report ? data collections, data storage, analysis and reporting, accessibility, and overall efficiency ? constitute the necessary system components for a comprehensive crash-data system (Table 1). The ideal crash-data system will incorporate the best practices identified for each area, improving system performance, increasing efficiency, and minimizing critical resources. The system starts with data collection. States like Kentucky and Iowa have proven that electronic, field-based data entry and electronic data transfer can expedite data entry and increase efficiency by reducing staff involvement in these processes. This also increases data consistency and accuracy though the use of data element standards and business rules for data validation and QA/QC. The use of an open RDBMS for data storage allows great flexibility in data accessibility and analysis. The integration of outside databases is also very beneficial. Direct links to systems such as facility, average statistics, citation, driver, and vehicle databases prove to be positive. The ideal configuration of analysis and reporting components varies with needs, but a few specific functions and capabilities should be targeted. The ability to generate custom reports and queries from a centralized location seems to provide optimal efficiency for end-users and managers. User-friendly GIS capabilities should be included to perform mapping and analysis with integration into reports to add a graphical component. A system should include access to previously generated reports for easy access and download. The ability to perform advanced statistical analysis and charting by pulling data directly from the enterprise database, ensures the most current information is being used. For accessibility, it is apparent that a Web-based application for data retrieval and analysis provides the most access to the most users. 2.6 BEST PRACTICES CONCLUSION Several states have created efficient and innovative practices to handle crash data. Most efficiency has been gained through automation of frequent processes and minimizing or streamlining data-collection efforts. The less staff intervention, the less time and resources are spent to get the data to analysts and decision-makers. Enterprise databases and common access points increase data accuracy and overall utilization of these systems, leading to safer transportation systems. While the initial cost of these systems and integrations can be high, the return on investment can be quickly realized as staff interaction decreases. The savings can result in cost-cut through reduced need to hire additional staff or redirection of valuable staff time for other safety-related activities. 19 Table 2. Interview Participants Organization ADOT Department/Group/Section Hazard Elimination Safety Risk Management Traffic Records Transportation GIS TPD ATRC City of Mesa City of Phoenix City of Glendale City of Tempe Maricopa Association of Governments Pima Association of Governments University of Arizona Arizona Dept. of Public Safety Arizona Tribal Council FHWA ITS Engineering Development Planning Safety Traffic Studies Street Transportation Information Systems Transportation Transportation Department 20 3. USE CASE In order to create a strategy for ADOT to move its systems into a best practice level for analyzing crash data, its current systems and environment must be defined. A use case study was designed to analyze ADOT's current desires, assets and capabilities, and workflows. This section highlights the methods and results from the use case study, which feeds into the gap analysis along with the results from the best practices study. 3.1 INTRODUCTION A use case study is a multi-level research project that identifies the current desires, assets and capabilities, and workflows for a particular organization. This kind of study delves into the specifics of an organization, resulting in a broad and complete understanding of its business practices. A use case study can be composed of interviews, surveys, document reviews, and data analysis. For ADOT's crash data collection and analysis system study, a combination of interviews and data analysis was used to define ADOT's current assets and capabilities. The research team visited ADOT's facilities and conducted interviews with several key players responsible for crash data, and also interviewed personnel of external entities such as the Federal Highway Administration (FHWA), regional governments, and local municipalities. Some additional interviews were conducted over the phone and through email. ADOT's existing data was also reviewed. Three areas were identified as critical for appropriately defining ADOT's business practices: Internal Desires, Existing Assets and Capabilities, and Workflows. This report has a section on each. The Internal Desires section identifies the current desires expressed by the various users of ADOT's systems and data. These desires fall into the five best practices groups of Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. The section of Existing Assets and Capabilities highlights ADOT's current systems, databases, GIS capabilities, analytical tools, reporting tools, and data sharing. The Workflow section identifies data collection components and data flow from organization to organization. Once all of ADOT's current assets and workflows were identified and its staff's desires defined, a comparison could be made between ADOT's current systems and the ideal system components from the best practices survey. This comparison is called a Gap Analysis, and the results from this analysis are included in this report. 3.2 METHODOLOGY To facilitate the use case study, the research team conducted a series of on-site interviews to identify needed information. These interviews provided the team with detailed descriptions of the desires, systems, and assets currently in place among Arizona's crash data stakeholders. It was not feasible to interview all stakeholders throughout the state, so representative groups were selected. The groups of people that the research team interviewed are shown in Table 2. 21 Table 3. User Desires System Components Data Collection ADOT User Desires Paperless incident submission Road open dates Automatic QA/QC procedures Street naming conventions Collect signalized intersections Crash definition standards Collect 1st, 2nd, and most harmful events X,Y for all incidents Data Storage Link State Highway System Log and ALISS Digital storage and retrieval of incident reports Ability to change ALISS ALISS documentation Data sharing between local, regional, and state governments Analysis and Reporting Prioritized accident locations High risk/hazard locations Safety improvement effectiveness Accident and severity rates Automatic FHWA reporting GIS database of safety improvements Intersection Magic integration Auto format data query Accessibility Overall Efficiency Municipal and Regional data access Change management procedures Data one-stop 22 Some people and groups could not attend the on-site interviews and were contacted via phone and e-mail. In some cases, follow-up information was needed from people interviewed in person, and these individuals were contacted via phone or e-mail to acquire more detailed information. While this report was meant to be inclusive, not all groups were interviewed and, therefore, this report may be lacking certain desires, assets, and capabilities. The interviewees identified several data sources, applications, and reports as critical to the business practices of ADOT and the various other organizations. These components were investigated through independent research techniques that varied depending on the type of source material available. GIS data was evaluated using ESRI software. Reports were reviewed by obtaining samples, and software packages were researched on-line and through contacting the developers. 3.3 USE CASE RESULTS The following subsections describe the findings on the three categories: Internal Desires, Existing Assets and Capabilities, and Workflows. 3.3.1 Internal Desires This section of the report contains the desires expressed by various interviewees. Some of these desires are general ideas to improve system efficiency while others are specific to a particular analysis or business process. During the interview process, participants were given opportunities to tell the research team what would make their daily workflows easier and what items they desired to have to help with their works but currently did not have. These expressed desires are listed in Table 3. To make these desires fit into the context of the gap analysis, the team have grouped them into the five categories identified previously in the best practice survey: Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. Each of the desires is presented in the following. 3.3.1.1 Data Collection Paperless Incident Submission. Great efficiencies could be made by eliminating the need for incident reports to be typed/entered by both the incident officers and ADOT personnel. Currently, all records are submitted in hard copy to ADOT and hand entered into the Accident Location Identification Surveillance System (ALISS). Road Open Dates. There is a desire to know when a road segment is opened for traffic. There needs to be a way to indicate whether an accident occurs prior to a road's being open or after. Automatic QA/QC procedures for data entry. There needs to be greater quality assurance/quality control for improved data accuracy. The use of domains and the integration of additional outside databases would help this initiative. The City of Tempe estimated that 10 percent of records have a minor data entry problem. 23 Street naming conventions. There is a desire for street naming conventions to be used throughout the database. If a municipality changes the name of a street and it becomes official, the database should reflect the change. Signalized intersection database. An inventory of signalized intersections should be included in the facility database and linked to the ALISS. Crash definition standards. There needs to be an agreement within the highway safety community on exactly what constitutes a particular kind of crash. Currently, end-users sometimes need to alter the crash type to run accurate analysis. Collection of data on harmful events. Field officers currently collect these data elements. Harmful events are "value-added" upon data entry into the ALISS. The practice should be expanded to incorporate up to six events. X,Y coordinates for all incidents. Approximately 80 percent of all incidents have approximate X,Y coordinates. There is a desire for 100 percent and high accuracy because the positional location of the incident determines if it is an intersection accident or is along a particular route. 3.3.1.2 Data Storage Linkage between ALISS and State Highway System Log. The interview with FHWA highlighted this very critical need. The data from ALISS and the State Highway System Log are not easily linked for analysis. These two systems need to be linked to determine accident rates by facility type. More efficient storage and retrieval of original incident reports. Currently, incident reports are stored on microfilm and require manual retrieval, printing, and mailing. Users desire access to the original report to help analyze a specific incident or QA/QC the database. Online or digital access to these reports would save time and effort in obtaining these reports. Ability to change ALISS data fields and data entry form. The current ALISS database and data entry form are not customizable. If a new data element needs to be collected in the future, the current system cannot be altered to accommodate this. Current ALISS documentation. No documentation on the system and data fields were provided when ALISS was delivered, making it extremely difficult to maintain and describe the system. Metadata is required. Data sharing between ADOT, regional, and local governments. Some municipalities correct or update incident records, but do not submit the corrected or updated records back to ADOT for revising its database. In addition, facility information is updated at the local level but only occasionally passed to ADOT. 24 3.3.1.3 Analysis and Reporting Ability to determine prioritized accident locations. There is a desire to identify the most frequent incident locations (i.e., top 10) for a user-defined geographic area and user-chosen criteria (e.g., vehicle type, pedestrian, etc.). Interviewees also said that it would be beneficial to be able to identify locations that had high priority for improvement for a userdefined geographic area. Several groups mentioned that they do this on a regular basis for their jurisdiction, but it is largely a manual analysis. Identify high risk/high hazard locations. The ability to identify locations of high risk to pedestrians, buses, passenger trains, and cars would be very useful. The ability to examine railroad crossing condition, rail speed and volume along with car speed and volume could identify higher-risk locations for cars near rail lines. High risk and hazard locations could also include exposure to buses, pedestrians, and hazmat vehicles. Safety improvement program effectiveness analysis and accident reduction rate analysis. The capability to analyze improvement programs to evaluate effectiveness for the program is necessary. This would require historical crash data for a location, data for improvement programs (dollars spent, location, improvement), and crash data after improvement. This would answer the question, "Did the improvement work and how well?" Accident and severity rates. It is critical to determine accident/crash rates for road segments and intersections by road type. A disconnect between accidents and facility information prevents this analysis. Also important are the severity rates for accidents. It would be very beneficial to be able to compare crash and severity rates for selected road segments with Arizona statewide and the national averages for a particular facility type. It was also noted that the ability to change the length of a road segment into a "corridor" for crash and severity rate analysis would be useful. Automatic FHWA reporting. Efficiencies could be improved by automating the reporting of data to FHWA. ALISS reports in digital format. Currently the reports coming out of ALISS are SQL printouts and not electronic copy. There is a desire to make electronic copy of these reports by using exporting data into MS Excel spreadsheets. GIS inventory of safety improvements. The ability to consider safety improvements such as barrels, bumpers, and guardrails in analysis would be beneficial. Intersection Magic integration. Many municipalities use Intersection Magic to help visualize and analyze incident information. Efficiencies could be achieved by minimizing data formatting. Auto-format data query. Several analytical systems are in use in Arizona, and each needs data to be in a certain format. The ability to generate custom formats for data export would be very beneficial. 25 3.3.1.4 Accessibility Municipal/regional government data access. Currently, local government agencies contact ADOT to request incident information for their jurisdictions. These data are queried from the ALISS system and mailed to the local agencies. The efficiency of this process could be greatly increased by providing local government agencies on-line access to the ALISS database to download the crash data for their jurisdictions. 3.3.1.5 Overall Efficiency Change management for altered data standards. All departments and agencies desire better communication so they can share and discuss changes made to the various systems. The example of changing the abbreviation "Av" to "Ave" can cause systems and analysis tools not work properly. Decision support one-stop. There is an expressed desire for one-stop access to data. The ability to go to one source for all data needs would minimize data collection efforts and improve response times. 3.3.2 Existing Assets and Capabilities This section highlights the existing assets and capabilities of the crash data community within Arizona. Systems, databases, analyses, and reporting capabilities are described to set the baseline for the gap analysis in the following sections of this report. While this section is meant to be inclusive of all existing assets, there undoubtedly are assets that were not brought to the attention of the research team. The known existing assets are described below. ALISS is the central repository for crash data within Arizona. This is a Microsoft SQL Server database with Visual Basic forms for data entry. All incidents involving an injury or causing a minimum of $1,000 in property damage are reported to this database for record. Accidents within the jurisdictions of military bases or Indian reservations are not required to be reported, though on occasion some are. Incident records are submitted to ADOT Traffic Records Section for inclusion into the database and are entered by hand into the system by the 12 members of the Traffic Records staff. The data entry system has some domains, or lookup tables, to assist in the data entry process, and there is geocoding functionality in which the system automatically locates approximately 80 percent of all records. Most data elements stored in ALISS are included on the Arizona standardized accident form. The elements not on the form, such as most harmful event, are "valueadded" by Traffic Records Section staff at the time of data entry. The ALISS database has over 115 stored reports that generate hardcopy outputs directly from the database. These reports can have customized parameters set to limit or query certain data elements within the database. These reports are stored within SQL and can be generated by contacting the Traffic Records Section. The ALISS database has export functionality to deliver data to local, regional, and national agencies. Queries can be run to extract information based upon area and are delivered to agencies as comma-delimited text files. 26 The State Highway System Log stores highway facility information. Data elements include number of lanes, shoulder width, speed limits, lane width, and pavement type. Intelligent Transportation Systems (ITS) apply technology based solutions such as advanced sensors, computers, electronics, and communications technologies, to transportation management to improve the overall safety and efficiency of multimodal transportation systems. ADOT's ITS has several systems and databases providing data to the public on a real-time basis. Weather information, highway restrictions and closures, current traffic speeds, ramp metering, live video feeds, and current accident locations are all components of this system. The Highway Conditions and Reporting System (HCRS), Road Weather Information System (RWIS), Freeway Management System (FMS), Variable-Message Signs (VMS), Traffic-Interchange Signal (TIS), and Closed-Circuit Television (CCT) are all systems utilized by ITS. The Highway Conditions Reporting System (HCRS) maintains information on highway closures, conditions, and maintenance. The Road Weather Information System (RWIS) monitors pavement and atmospheric sensors, then processes this information for display within the ITS system. Intersection Magic is an "out of the box" application designed by Pd' Programming, Inc. This application graphically displays various incidents and some of their attributes at a single intersection. This application is licensed and utilized by several municipalities throughout the state. Data are exported out of ALISS or out of local databases, then manipulated and read by Intersection Magic for display. The Maricopa Association of Governments (MAG) GIS database serves as a warehouse for various transportation-related GIS datasets. GIS layers include roads, traffic flows, and signals within MAG's jurisdiction. These data are updated frequently and are adjusted by working with local municipalities. MAG utilizes EMME-2 software for modeling multimodal traffic planning networks. It utilizes matrix manipulation and other tools to distribute and forecast traffic over an urban or regional area. Traffic forecast periods are usually up to 25 years. As is typical of most traffic planning software, EMME-2 users can alter the analysis portion of the program by changing the matrices, inputting assignment procedures, or using interactive calculators for evaluation and impact analysis. Crash data can be one of the add-ons to the program. If statewide averages/rates are generated for facility types, then crash rates can be predicted for various future-year scenarios to complement the traffic forecasts. The Traffic Records Microfilm Inventory maintains all reported incident forms on microfilm. These original records are submitted to ADOT from various agencies within the state. Each record has a unique identifier that correlates the microfilm record with the record in the ALISS. Microfilm incident reports can be reproduced in a hardcopy format for additional incident record information. Upon request, the original incident report can be printed and mailed to end-users for in-depth analysis. 27 The ADOT GIS database is currently being migrated from an ArcInfo database to a GeoDatabase with dynamic segmentation and linear referencing. The database will soon sit on a Microsoft SQL server running ArcSDE to serve desktop clients. Also under development is an ArcIMS Website to allow Internet access to the database. The GIS database contains information on roadways, intersections, traffic flow directions, and other facility information in addition to base map information. ADOT's GIS has several analytical functions. An ArcIMS Website would allow users to build custom maps from the Arizona Transportation Information System (ATIS) library. The ArcView 3.x extension program allows users with ArcView 3.x to view and analyze geospatial information, including facility information. There is functionality to geocode information from the ALISS database, a GPS tool for collecting information, and tools for integrating bridge and railroad crossings. The GIS is based upon linear referencing technology and therefore allows for incident analysis along a route not just at an intersection. ADOT's Data Warehouse is a data storage and retrieval system designed to be a one-stop location for data access. The warehouse has a query wizard at its front end for data retrieval and export. The Data Transformation Services (DTS) software running on top of the database perform cleansing routines, geocoding, and data validation to help load and export data. Currently, the system is accessible on the ADOT intranet, and all information has the geographic component of a route/milepost. The ADOT Data Warehouse has built- in query and export functions to help end-users acquire safety related data. Route and milepost can be used to define areas for data queries as well as custom-data-element queries. The returned data can then be exported in tabular format for use in analysis. There are 50-60 stored queries to expedite the data retrieval process. Several municipalities' traffic safety departments maintain and use local databases to store their own incident records. Some choose to enter incident records into their local databases and then send the incident report to ADOT, while others wait for ADOT to process the incident report to enter incident records, request the records, and then populate their databases with the ADOT records. These databases are often updated by correcting data entry errors in the ADOT record and are therefore potentially more accurate. Local municipalities have reporting capabilities to generate reports for pedestrian, bicycle, and fatal incidents. They also have analytical capabilities to determine the top 10 high-risk locations for incidents by types such as angles, striping, and visibility. Some municipalities have the ability to geocode their incident data by utilizing GIS software. Some local municipalities have automated tools for formatting data from ADOT to support their analysis routines. Several groups that use Intersection Magic have automated their data from ADOT into the Intersection Magic format to reduce data processing time prior to analysis. Others run ADOT's data through routines that geocode incidents, allowing GIS systems to read these data for advanced analysis using geography. The Traffic Accident Data System (TADS) is a system being developed by the City of Phoenix Police Department that utilizes field-based data collection and entry for incident reports. These reports are electronically transferred into the police database and made available for analysis instantaneously. Soon these records will be submitted electronically to ADOT's ALISS. 28 The State Maintained Streets Photo Log is available for all to use. This log has captured photos from along all state maintained streets within Arizona. 3.3.3 Workflows There are several different workflows or dataflows within the crash data community in Arizona. Each of these workflows is highlighted in Figure 4 to show general movement of data throughout the community. Each community is different, but each will typically follow one of these models in getting data to and from the ADOT ALISS. In smaller municipalities across Arizona, the police department collects information using a hand-written, field-based form. This form is then photocopied and sent to ADOT for entry into ALISS. ADOT receives the form and hand-enters the data elements. On a periodic basis, the municipality requests the data and an export file is generated and sent to the safety or traffic engineering department of the municipality. The municipality then manipulates the file format, performs a QA/QC check, and analyzes the data. Some progressive municipalities store the data in a database for future use once they receive the file from ADOT. On occasion, the municipality will notify ADOT of errors in the data for correction in ALISS, though this is not common. In medium and large municipalities, the common system is for the police department to collect incident information using a hand-written, field-based form. The form is taken to the office, where the data is hand-entered into the municipality's incident database. An incident report is generated, printed, and mailed to ADOT for hand entry into ALISS. Most municipalities that use this workflow do not request the data back from ADOT, as they already have the information in their own systems. The traffic engineering or safety department then requests the data from the incident database and formats the data as necessary for its analyses. The City of Phoenix police collect incident data via a field-based data-collection system that transmits data directly to the police department's database. Soon this database will electronically submit the accident report directly to ALISS. Once the data is in ALISS, the city requests that the relevant data be sent to the appropriate city personnel, where the data are entered into their system and formatted for analysis. Once a record has reached ALISS, queries are run to distribute data to various other agencies upon request. Groups such as MAG, PAG, and internal ADOT groups request this data for their analyses. Each group must format the data for use in its own analysis systems. ALISS also generates reports for groups such as FHWA and the Fatality Analysis Reporting System (FARS). Frequently, the ALISS data is sent to ADOT's Data Warehouse for query by those who have access to ADOT's intranet. 29 ADOT Traffic Records Crash Records Data Flow INPUT FLOW INTO ALISS - 135,000 Crash Records per Year Crash Data Sources Municipalities, Arizona Department of Public Safety - Highway Patrol Hard Copies ADOT Traffic Records Receiving Clerk and Information Processing Specialist (Level 2) 2-6 Week DELAY Hard Copies Sorted by Month and by Fatality Status Target for Crash Data entry into ALISS: 8 weeks Hard Copies Non- Fatalities Hard Copies Suspected Fatalities Hard Copies Data Problem ADOT Traffic Records 9 Information Processing Specialists (Level 2) FARS/Contractors 30 ADOT Traffic Records 3 Lead Information Processing Specialist (Level 3) Hard Copies Data Problem Resolved 2 - 3 Day DELAY Up to 3-4 Week delay Hard Copies Determined as Fatalities Hard Copies Microfilm copy created Hard Copies Crash Data Entered into ALISS Hard Copies Crash Data Entered into FARS FARS ADOT Traffic Records ALISS Note: 1. 2. Figure 4. Crash Records Data Flow ALISS stands for Accident Location Identification Surveillance System. FARS stands for Fatality Analysis Reporting System 4. GAP ANALYSIS This section of the report is a comparison between the ideal system components from the best practices report and the existing capabilities and assets from the use case study. The gap analysis highlights the deficiencies of the current system and outlines the steps needed to bridge the gaps between existing and proposed systems. It feeds into the third and final part of the study, the technical memorandum. 4.1 INTRODUCTION The best practices report is broken down into five sections: Data Collection, Data Storage, Analysis and Reporting, Accessibility, and Overall Efficiency. The ideal system components are taken directly from these sections and will serve as the goals for ADOT to aspire to in developing its systems. The gap analysis below compares these ideal components with capabilities and assets already in place within the crash data community. These assets and capabilities were previously defined within the use case study. The outputs from the comparison result in the gap analysis, which then feeds into the technical memorandum. The internal desires section of the use case is also a portion of the gap analysis. These desires serve as additional goals for Arizona's crash data community, whether the desire is expressed as a best practice or not. Internal desires detailed in previous sections of this document will not be repeated in the gap analysis unless the desire is particular to a specific ideal system component. All identified desires are in the technical memorandum, however. 4.2 METHODOLOGY To identify all the components necessary for the gap analysis, a best practice report and a use case study were conducted. The best practice report began with an on-line survey to identify the states that utilized technology to achieve the best practices in data collection, data storage, analysis and reporting, accessibility, and overall efficiency. This survey identified the states of Kentucky, Iowa, Massachusetts, and Illinois as having best practices in at least one of these areas. These states were then examined for specific aspects that improved user efficiency. The most efficient practices were used to define the ideal components for a crash data system and were fed into the gap analysis as a target for ADOT to aspire to. The use case consisted of a series of interviews with many of the stakeholders within Arizona's crash data community. The use case interviews focused on internal user desires, existing assets, existing capabilities, and workflows. Aspects of each section were defined for each group and passed to the gap analysis Once all the necessary information was gathered, a comparison was undertaken to highlight system deficiencies. These deficiencies in combination with the expressed desires not encompassed by the ideal system components are the output for the gap analysis and serve as specific goals for the crash data community within Arizona. 31 Best Practice Component System Design Recommendation Reduce Staff Intervention Improve Analysis Capabilities Recommendation Benefits Timely More Improve Accurate Management Efficiency Decisions Data Improve Reporting Capabilities Electronic data entry Field-based data entry Domains and business attributes for validation Data Collection Automatic data collection from swipe cards/bar code readers GPS/GIS for incident locating Data collection standards Automatic data entry from remote databases Data Storage Use RDBMS 32 Figure 5. Best Practice Benefits Additional enterprise database integration Custom reports and queries for export Multiple format and customizable data export User friendly GIS Analysis and Reporting Advanced statistics, charting and graphing Access to previously generated reports Accessibility Links to additional data resources for advanced analysis Centralized web application that is live linked to enterprise data One-stop portal for all information Password security 4.3 BEST PRACTICE RESULTS The five areas highlighted in the best practices report--data collection, data storage, analysis and reporting, accessibility, and overall efficiency-- define the ideal system components for a comprehensive crash-data system. The ideal crash-data system incorporates the best practices to improve system performance, increase efficiency, and minimizes critical resources (Figure 5). Based upon these factors, the system starts with data collection. States like Kentucky and Iowa have proven that electronic, field-based data entry and electronic data transfer can expedite data entry and increase efficiency by reducing staff involvement in these processes. This also increases data consistency and accuracy through the use of data element standards and business rules for validation and QA/QC. The next system component comes from the data storage realm. The use of an open RDBMS allows for great flexibility in data accessibility and analysis. The integration of outside databases is also very beneficial. Direct links to systems such as facility, average statistics, citation, driver, and vehicle databases prove to be beneficial. The ideal configuration of analysis and reporting components varies with desires, but a few specific functions and capabilities should be targeted. The ability to generate custom reports and queries from a centralized location seems to provide optimal efficiency for endusers and managers. User-friendly GIS capabilities should be included to perform mapping and analysis with integration into reports to add a graphical component. A system should include access to previously generated reports. The ability to perform advanced statistical analysis and charting using data directly from the enterprise database ensures that the most current information is being used. For accessibility, it is apparent that a Web-based application for data retrieval and analysis provides the greatest access to the most users. 4.4 USE CASE RESULTS The areas of focus for the use case study ? existing assets and capabilities, and workflows ? define the current operating environment for the crash data community in Arizona. Systems and databases are defined and analysis and reporting capabilities are identified, giving an overall picture of crash data collection and analysis. Although the City of Phoenix Police Department is experimenting with electronic collection of field data to help efficiency Arizona mainly uses hand-written field reports for data collection of incidents. These hand-written reports are then either entered into local databases or passed directly to ADOT for entry into ALISS. In the event that the local municipality enters the data into a local system, the report is still passed to ADOT's ALISS as a hardcopy printout. ADOT staff manually enter all incident records into ALISS for storage. The incident records are geocoded to a location and certain data elements are "value-added." The hard copy is then copied to microfilm for storage. Incident records are 33 exported from the database and sent to an agency when it requests them. Most agencies reformat ALISS export data to make it acceptable for analytical software such as a GIS and Intersection Magic. Stored queries and reports generate frequently utilized analyses and summaries of incidents in hard copy. The ALISS database is routinely updated in the ADOT Data Warehouse for query and is downloaded through ADOT's intranet. The Data Warehouse stores a variety of transportation-related data, including facility information, and it provides customizable queries to users for data download. The ADOT GIS Section provides access to GIS data, allowing users to visually represent incident records for spatial analysis. 4.5 COMPARISON The ideal system components are compared with the use case components to identify gaps in Arizona's crash data systems. The comparison is organized by the five system components: data collection, data storage, analysis and reporting, accessibility, and overall efficiency. Each component is briefly discussed in the following. The overall output is highlighted in the last section of this report. 4.5.1 Data Collection The best practice in data collection utilizes field-based electronic data entry with a handheld unit or a laptop computer. The incident form contains domains and business attribute rules for data validation QA/QC. The form utilizes automatic data entry from vehicle and driver's license databases as well as global positioning system (GPS) for GIS locating. The incident form also conforms to MMUCC data element standards. The electronic incident forms are automatically transferred to the central repository, and the database is updated without user intervention (Table 4). Table 4. Current Practices ? Data Collection Best Practice Field-based electronic data collection (laptop or Personal Digital Assistant (PDA)) Business attribute rules and domains for QA/QC Automatic data entry from external database (D.L., vehicle) GIS or GPS locating in field unit MMUCC standards Electronic data transfer of incident records ADOT Current Practice Phoenix only. Rest of state uses paper data collection Some domains and business rules None None Essentially compliant None Arizona's crash data community is beginning to explore some of these system components, but none has been universally adopted. The City of Phoenix is beginning to use field-based, electronic data entry, but the rest of the state is using hard-copy incident reports that are 34 sent to the central repository. ALISS does employ domains and business attribute rules to help data validation and consistency, and these rules can be expanded to automate data entry routines. GIS and GPS positional attributes are not entered into the report until the report is received at ADOT. Data collection routines do not currently use vehicle registration, driver's license and other outside databases to help the data entry process. Arizona does conform to several Model Minimum Uniform Crash Criteria (MMUCC) dataelement standards. 4.5.2 Data Storage The best practice in data storage uses Relational Database Management Systems (RDBMS). RDBMS has the core functionality of linking to other enterprise databases, allowing users to explore and analyze data not contained within the primary database. These databases can include driver's licenses, vehicle registrations, crime records, transportation facilities, weather, traffic counts, statewide averages, and so on (Table 5). Arizona utilizes a RDBMS to store incident records. Arizona also maintains several other enterprise databases, but none is actively linked to ALISS. The ATIS system is a very good start in relating additional information, but it does not include incident records. Table 5. Current Practices ? Data Storage Best Practice Utilize RDBMS Link or Relate Other Enterprise Databases ADOT Current Practice Utilize RDBMS None 4.5.3 Analysis and Reporting Best practices in analysis and reporting allow users live access to the central repository for incident reports. Such access allows the generation of custom ad-hoc or previously generated reports. Users have access to custom data queries with the ability to export these selected data in several different formats. More advanced systems allow the user to define the fields and formatting of the data export for direct integration into analytical and chart/graphing software packages. These systems employ user-friendly GIS capabilities and the ability to export GIS graphics and analysis results into reports for visualization. Advanced statistical analysis is available as well as external data from related databases (Table 6). Arizona has several of these analysis and reporting components, but most are not quite best practices. Users have access to custom and stored reports from the ALISS by requesting hard copies from the Traffic Records Section at ADOT. Users can also receive custom data queries in multiple formats through the same request system. However, users can only manipulate the format of the output once the data is sent to them. The system does not contain the functionality to specify the formatting of the data structure on export. Users do not have access to the live database, only to data that has been exported by request or through the ADOT intranet to the data warehouse. ADOT does provide advanced GIS 35 capabilities to users with ArcView 3.x software through the distribution of the ATIS library. Users without GIS software do not have access to any GIS function. Users must rely on their own software for advanced statistical, charting, and graphing functions. Data within the data warehouse do have common linking elements of route and milepost to serve as an ad-hoc relation amongst databases. However, these databases are not completely related, thus requiring additional user intervention to analyze data together. Table 6. Current Practices ? Analysis and Reporting Best Practice Live access to central repository for incident records Custom ad-hoc reports or access to Previously generated reports Custom data queries Export data in multiple formats User defined export formatting User-friendly GIS for analysis and reporting Advanced charting, graphing and statistical analysis Access to external data sources ADOT Current Practice None Can be requested from Traffic Records Can be requested from Traffic Records Can be requested from Traffic Records None User-friendly GIS, however ALISS is not GIS Friendly Users must rely on their own software packages Access is available via the Data Warehouse 4.5.4 Accessibility The Best Practice for data accessibility is a one-stop portal for information. This can be very difficult to achieve, given the magnitude of transportation information available and needed throughout the community, but recent innovations in Web technology have accomplished this task. Centralized Web-based applications are providing users the ability to perform all the best practices analysis and reporting functions from one spot. Web applications typically are accessible 24/7 and have password security to prevent unauthorized access to sensitive information. Information and data sources are live-linked to databases and warehouses, allowing users to access the most up-to-date information (Table 7). Arizona users have access to data resources, but most resources require staff to query the database, export the required data, and send the data to the end users. There are automated data-access tools associated with the data warehouse, but the crash data is not live-linked to the warehouse and users only have access if they can get to the ADOT intranet. The data warehouse is designed to be a one-stop portal to transportation data, and it does a good job 36 of storing and retrieving data. Unfortunately, the warehouse is only available to ADOT users. The only centralized Web application is for real-time traffic information through the ITS system, and this system does not include incident or facility information. Table 7. Current Practices - Accessibility Best Practice One-Stop portal for information Centralized Web-based application Security for sensitive information Access to live data and databases ADOT Current Practice Data warehouse provides access to ADOT users None Sensitive information not available None 4.5.5 Overall Efficiency The key best practice for overall efficiency involves automation and reduction of staff involvement in day-to-day operations. Items like electronic data transfer and electronic field-based data entry highlighted in the data collection section contribute to overall efficiency. Customizable data query for export from a live system eliminates staff burden for data requests and reduces time for end-users to receive and manipulate data for analysis. One-stop portals reduce the time users spend on searching for data, allowing for more in-depth analyses that were once prohibited by time constraints. Centralized tools give all users access to analytical capabilities, reducing resources required at the local and regional levels and allowing these resources to be better allocated into the safety environment. Arizona has opportunities to improve the overall efficiency. Several agencies enter incident records into their own systems, then the same record is reentered into ALISS, duplicating effort. Electronic data transfer would minimize repetitive entry, thus saving significant resources. Deploying field-based electronic data entry for officers would reduce the duplication of effort by the data entry staff and would improve efficiency. A one-stop portal for data download would free staff resources now used to query and export data for local, regional, and national users. The integration of online tools would reduce software licensing costs and provide greater accessibility to a larger number of users, thus creating a safer environment for all. 4.6 GAP ANALYSIS RESULTS The following sections give the results from the gap analysis with the results of the internal desires section of the use case. While Arizona's crash data community utilizes a few best practice elements, several gaps remain to be filled (Table 8). Table 8 highlights the areas where improvements are needed to bring Arizona up to the best practice levels for crash data 37 Table 8. Gap Closure Best Practice Field-based electronic data collection Business attribute rules and domains for QA/QC Automatic data entry from external database GIS or GPS locating in field unit MMUCC standards Electronic data transfer of incident records Utilize RDBMS Link or relate other enterprise databases Live access to central repository for incident records Custom ad-hoc reports or access to previously generated reports Custom data queries Export data in multiple formats User-defined export formatting User-friendly GIS for analysis and reporting Advanced charting, graphing and statistical analysis Access to external data sources One-stop portal for information Centralized Web-based application Security for sensitive information Access to live data and databases ADOT Current Practice Phoenix only, rest of state uses paper data collection Some domains and business rules None None Essentially Compliant None Utilize RDBMS None None Can be requested from Traffic Records Can be requested from Traffic Records Can be requested from Traffic Records None User-friendly GIS, however ALISS is not GIS Friendly Users must rely on their own software packages Access is available via the data warehouse Data Warehouse provides access to ADOT users None Sensitive information not available None Gap Closure Promote more field-based electronic data collection Expand where applicable Need to integrate external databases and utilize swipe cards or barcode scanners Need to deploy GIS of GPS to field for incident locating Meets Best Practice Need to promote electronic data transfer of incident records Meets Best Practice Need to integrate other enterprise databases Need to make database accessible to users Need to give users access to this functionality Need to give users access to this functionality Need to give users access to this functionality Need to give users access to this functionality GIS Meets Best Practice, but ALISS needs GIS improvements Better access to tools would be beneficial Better, more integrated access would be beneficial Provide access to the rest of the crash data community Need to create portal Create access to data and generate security requirements Grant access to user community 38 systems. The results are divided into the five best practice components. These results are in the technical memorandum portion of the study for inclusion into the system designs and overall recommendations. 4.6.1 Data Collection Arizona should utilize electronic, field-based data entry and electronic data transfer. This effort should include the creation of browse lists of standard terms and business attribute rules for automated QA/QC and standardization of data elements. Global Positioning System receivers and a geographic information system should be field-deployed to each officer's laptop computer to use in recording the X,Y coordinates of incident locations, which should be stored with each incident record. This will improve the accuracy of positional data in the database. External database systems, such as those for vehicle registrations and driver's licenses, should be integrated with the system to minimize manual data entry. Additional MMUCC data elements should be collected at the scene, including first and second harmful events. The user community should standardize data elements for street naming and crash definitions. Signalized intersections and road contract release dates should be collected and maintained. 4.6.2 Data Storage Arizona should integrate additional data sources into ALISS. The State Highway System Log should be the primary source from which facility information is attached to the incident record, which would allow statewide averages to be calculated. Driver's license, vehicle registration, weather, traffic volume, and other databases should also be integrated into an enterprise system of transportation-related databases. ALISS needs detailed system documentation and the ability to manipulate the database structure and a Visual Basic data entry form to allow for any changes in the future. 4.6.3 Analysis and Reporting Arizona should automate its data reporting and exporting routines, giving users direct access to the live system and allowing for customizable data export formats. On-line functionality should be improved to include GIS, advanced statistical analysis, and graphic and charting capabilities. This on-line access point should be built as a one-stop access point for data and analysis, including digital ALISS reports and automated FHWA and FARS reporting. The system should allow generation of statewide averages by facility type, identification of top 10 crash locations for a given area by type of crash or type of facility, identification of high risk / high hazard locations, the ability to assess the effectiveness of an improvement, accident and severity rates, and Intersections Magic diagramming. Basic and user-friendly GIS diagramming and mapping should also be a functional element. 4.6.4 Accessibility Arizona should grant access to all users within the crash data community through an Internetbased application and a one-stop portal for data access and analysis. A 24/7 solution would provide the greatest access and flexibility for end users. 39 4.6.5 Overall Efficiency Arizona should eliminate redundant and duplicate data entry. Online and customizable data download, centralized access to tools and data, and live linkages for custom reporting will minimize staff intervention at all levels. Inter Tribal Council of Arizona (ITCA) According to Esther Corbett of the Inter Tribal Council of Arizona (ITCA), only a few of the 21 Native American tribes in Arizona provide regular FARS data, and most do not have facilities to keep crash records. What exist are paper records. Tribes have been willing to participate in studies, but have received no benefit from the studies. Therefore, they are reluctant to participate in further activities. ITCA did a multidisciplinary study of 3 tribes, and as a result obtained $12,000 for implementation of a POLARIS Crash System and an Access Database Management System. The Navaho Nation has since implemented a database and has a Highway Safety group, but how the data is distributed or used beyond internal tribe postings is not well documented. Their website is: www.navajo.org. Law enforcement and public health agencies on the reservations are other hurdles to data collection. The tribes and the Bureau of Indian Affairs (BIA) law enforcement officers use the standard Arizona Highway Patrol (AZ HP) accident report forms. However, record keeping on crashes is sporadic for both types of agencies. Another possible way of gaining the information is from hospital records of the Indian Health Services, however some tribes have started their own hospitals, which complicates data collection. The BIA has a Road Inventory, however tribes do not have access to it. ITCA feels that the tribes need to be informed of the importance of crash data for planning and funding of activities. If the tribes can be persuaded to collect and provide the data, then Memorandums of Understanding can be executed for data sharing. 4.7 GAP ANALYSIS CONCLUSION Arizona's crash data community has a significant number of desires and therefore requires an advanced system to meet them. The results of the best practices, use case, and the gap analysis have highlighted the general system requirements for a best practice system for Arizona. These system requirements are fed into the final portion of this study, the technical memorandum, where the desires are weighed against the practicality and the costs associated with meeting them. All practical components are investigated and detailed to allow ADOT to weigh all options before deciding where to proceed in addressing the desires of the crash data community. The specific components are outlined with a cost estimate and roadmap for their implementation, as well as an overall system design. 40 5. TECHNICAL MEMORANDUM This technical memorandum proposes ways to meet ADOT's desires and provide solutions to the gaps identified during the previous portions of this study. An overall systems design strategy as well as individual system components are discussed to provide ADOT with specific courses of action to reduce the resources needed in the collection and analysis of crash data. The benefits, components, implementation steps, and costs associated are all outlined below. 5.1 INTRODUCTION This memorandum addresses four overall goals. These four goals follow the same categories discussed throughout the study: Data Collection, Data Storage, Analysis and Reporting, and Accessibility. The fifth goal of overall efficiency will be met with the achievement of the other four goals. For each goal specific system components are given that help achieve the best practices. Once each component has been discussed, an overall system design is described that is an inclusive solution to all the desires of the crash-data community. The study team realizes that a comprehensive solution is probably not economically feasible for ADOT, and the final section of this report gives implementation steps by their recommended priority. This technical memorandum allows ADOT to pick and choose individual components to meet its desires. The section on each component has a very rough estimate of the costs associated with implementing that component. Dollar figures are estimated from the cost an outside firm would charge for these services and do not reflect any costs that could be saved by having DOT staff perform some or all of the tasks. The technical memorandum portion of this report does not constitute the formal recommendations of the study team. The formal recommendations and their costing are outlined in the final section of this report - Recommendation and Implementation Strategy. 5.2 OVERALL GOAL ? MORE EFFICIENT AND ACCURATE DATA COLLECTION 5.2.1 Solution: Electronic Data Entry (EDE) Benefits EDE optimizes data collection by digitally capturing information at the incident location. Digitally collected information at the incident location minimizes the chance of interpretation errors when the officer returns to the office to enter the information. EDE reduces data collection and entry time by inserting information directly into a system. The time needed to collect information is also reduced by the use of domains (pick lists), minimizing the amount of information that must be typed into the system. These 41 domains also promote data accuracy and consistency by eliminating typing errors and variations such as "Ave" or "AV" in abbreviations for "Avenue." EDE allows for numerous other capabilities that can improve data collection, such as electronic data transfer, automatic data entry from other data sources, and GIS/GPS integration. Most incident responders already have a computer, and this functionality can be developed within that context. This should require minimal amounts of new equipment acquisition. Components EDE requires that a field response unit have either a laptop computer or a handheld device for data entry. An application is required for a data entry form and the storage of the record once it is entered. This application should be developed with domains and business attribute rules for data standardization and validation. The application will also need an export function to transfer the electronic record to the local agency's database or to ADOT directly. Implementation To properly implement this component, a laptop computer or a handheld device must be deployed to any individual who responds to incidents. Therefore, an inventory must be taken to identify the number of new hardware units required. The inventory should also include the type of units in the field, as that will be critical in the software development. Next, an application needs to be developed that works on the many platforms already in existence. The application should be very user-friendly and should utilize domains and business attribute rules for data consistency and validation. The export routine should have both hardcopy and digital capabilities to support the needs of any organization. The software should be tested prior to a full implementation. Users will require a small amount of training to properly utilize the system. Costing Table 9 shows the estimated costs of implementing electronic data entry. Table 9. Costing ? Electronic Data Entry Component Hardware inventory Hardware (computer) Hardware (Personal Digital Assistant (PDA) Custom data-entry and storage software Domains & business attribute rules Export routines Installation Training Total (not including hardware) Cost $20,000 $2,000/ea $750/ea $65,000 $20,000 $25,000 $100,000 $75,000 $305,000 42 5.2.2 Solution: Electronic Data Transfer (EDT) Benefits Electronic data transfer eliminates the need for duplicate data entry by automatically sending the electronic incident record to the local database and to ADOT's incident database. This component should be enabled with electronic data entry. This component can be configured to transmit an incident record instantaneously after it is created through the use of radio telemetry, cell phones, or satellite-based Internet, or the records can be transmitted at the end of a shift when the officer returns to the office and connects to a wireless LAN. EDT can still be implemented if a municipality's police department does not use field EDE, but has its staff enter incident information at the office when officers return. When the records are entered into the local system, the municipality can send ADOT an electronic copy via the Internet instead of sending hardcopies. The municipality can send records individually or as a batch. Components EDT requires that Electronic Data Entry has been enabled in the field or that incident records are entered into a database system at a local office. A small export routine is required to package incident records into a format that can be transferred. For ADOT to implement EDT, it needs a small import routine that will accept the export and correctly load the record into the ADOT database. ADOT will need to establish a staff workflow routine to verify that records are being sent to ADOT and are being correctly imported into the system. Implementation To implement EDT, agencies must first implement Electronic Data Entry at either the office or in the field. A small study will need to be undertaken to inventory the datacollection methods of each response unit within the state. This study will identify the number of different systems within the state for which export routines must be created. The small export routine will package each record into a transferable file. There are multiple methods that can transfer the file to ADOT's database for import. A small import procedure needs to be created to accept and import the records. 43 Costing Table 10 shows the estimated costs. Table 10. Costing ? Electronic Data Transfer Component Data-collection inventory Export routine Import routine Installation Training Workflows Staff @ 10 hours/wk Cost $25,000 $20,000 $25,000 $100,000 $50,000 $10,000 $20,000 Total $250,000* *Training and installation costs can be eliminated by implementing at the same time as electronic data entry. It is anticipated that one staff member will be required to facilitate Electronic Data Transfer. This position will probably require 10 hours per week to ensure that transfers are properly entering the system. A successful candidate for this position should have one year of database experience and an understanding of crash data for QA/QC procedures. 5.2.3 Solution: GIS/GPS Integration Benefits Integrating GIS and GPS can greatly improve the accuracy of incident locations. Only the officer in the field knows exactly where the incident occurs, and he or she should be the one to enter the precise location of the incident on the record. GPS can provide the exact X,Y coordinates to enter onto the form, or a GIS can be used to find the exact location. Using GIS also brings general GIS functionality to the officer in the field for other activities, such as routing, base map information, and other analytical capabilities. A GIS can be integrated into the existing field-based computing hardware within the response vehicle. It can put aerial photography, infrastructure information, and crime data at the responder's fingertips. Free GIS reader software can be deployed to users with no additional licensing costs. Components A GIS requires a laptop computer or a handheld computing device to operate. It also requires a small software application and a published data package for the user. A customized application will need to be written to easily return the X,Y coordinates of a 44 location for input on the incident record. GPS requires a GPS receiver (hardware) on each response unit. No customized software is required. Implementation To implement a GIS, data must first be acquired to create base maps for responders to use. Either an application needs to be written to easily return the X,Y coordinates of a selected location, or, with appropriate training, a user could obtain the X,Y coordinates from the existing GIS software. The software and data need to be bundled for distribution and instal

you wish to report:

Your comment:

Your Name:

Submit

Cancel

...

Find results with:

Searching collections:

Home Crash data collection and analysis system

Crash data collection and analysis system

Description