Cover Image

Not for Sale

View/Hide Left Panel
Click for next page ( 66

The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement

Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 65
Database Analysis 65 additional resources, but would fit well within NHTSA's crash data program. Adding the follow- ing data fields is suggested: Right of way. This data element would identify which vehicle, if any, within a crash had the right of way prior to the collision. This could be readily coded from the PAR in most cases. Some state crash reports include right of way on the report. Right of way would be very use- ful in most crashes in identifying the vehicle that primarily contributed to the crash. Accident type. The General Estimates System (GES) file and Crashworthiness Data System (CDS) file both include an accident type variable coded at the vehicle level that captures the relative position and movement of the vehicle prior to its first harmful event. The TIFA data adds this to trucks in fatal crashes, but capturing this within the FARS system would be a valu- able addition. An accident type field can identify key relationships that describe how the crash occurred and suggest contribution (for example, by identifying the vehicle that crossed over the center line in a head-on collision). The following two fields would be useful although this would take additional resources and possibly require some change in the management of the FARS file: Critical event is a field that would identify and describe the event that precipitated the vehicle crash. This field is included in both the GES and CDS files, so the agency is very familiar with (and, indeed, invented) its use. Critical reason captures the "reason" for the critical event, classified broadly as driver, vehicle, or environment, with detailed levels under each. The variable is useful for identifying the immediate failure that led to the crash and would shed considerable light on crash causation. The field was used in the LTCCS, conducted jointly by the FMCSA and NHTSA, and in the National Motor Vehicle Crash Causation Survey (NMVCCS), conducted by NHTSA. Thus, the agency already has developed coding procedures for both variables. However, adding these fields might require some changes to the FARS protocol. Both are dif- ficult to code consistently and require a high level of focus and analysis. Currently, virtually all FARS fields are coded by analysts located off-site, that is in the 50 states and District of Colum- bia. But the coding of both GES and CDS is more centralized. In the LTCCS, both critical event and critical reason were coded by a small number of analysts in two locations. The National Cen- ter for Statistics and Analysis (NCSA) could adopt a similar method for the FARS file, if these data elements were added. 4.3.8 Potential Measures to Improve Data Quality The FARS quality control system is complete and mature. It is subject to annual review and adjustment, including continuous training of the coders. FARS might be improved if the system could be adapted to take advantage of the additional information provided through the TIFA system. FARS has not engaged TIFA in this regard, although one problem has been that information from TIFA has not been available in a timely fashion. However, greater cooperation between the systems would be valuable for both. 4.3.9 Compatibility with Other Databases The FARS file does not include case identifiers that can be used to uniquely link to other data systems, such as the PAR number. Including the PAR number would provide a hard link. (Note that the MCMIS Crash file report number field in the past was supposed to include the PAR number in one of the fields, and it is recommended that MCMIS require that again. Currently, many states use a random report number, rather than using the PAR number.)