Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Although no comprehensive crash records system was iden- tified as a model or âbest practice,â many examples of one or more components of a successful crash records system were found. It is often the case that the agency that serves as the custodian for the crash records system determines which component of the system is considered most important in terms of new funding and development initiatives. For exam- ple, if the crash records system is under the purview of a state law enforcement agency, then often the crash data collec- tion component is emphasized. If the crash records system is under the control of the state DOT, the emphasis is often on the ability to locate crashes well and to link to other data sources for analysis. If a regulatory agency such as a depart- ment of revenue manages the crash records system, the agency often designs a system that allows easy access to a single crash record for sales. To the extent that these agencies work together, especially through a forum such as a traffic records coordinating committee, the strengths and weaknesses in a crash records system can be balanced to serve the needs of all of the stakeholders. With a growing understanding of the needs of diverse users of crash data, there is more attention than ever paid to the timeliness, completeness, accuracy, and accessibility of these data. This awareness has led to a deeper appreciation for the costs of achieving excellence in a traffic records sys- tem. To meet the needs of multiple users, the system must be flexible and its quality must be monitored. Cost savings in one part of the system can have disastrous consequences for other parts of the system. Unfortunately, this is where the breakdowns in the system can still occur. Local law enforce- ment agencies, pressed for resources, sometimes conclude that they can no longer afford to respond to property-damage- only crashes. Statewide crash custodians, pressed to cut the cost of data entry or to catch up on a backlog of crash reports, skip edit checks or even stop performing procedures such as location coding or text-field data entry. Sometimes new soft- ware is installed without adequate testing and suddenly a crash records system that was previously known for having high- quality data is left with no data at all. It can take an agency years to recover from such missteps. It appears that there still exist some major sources of con- flict in supporting crash records systems. The tensions that practitioners most often cite are those among the needs of data collectors, data managers, and data users. A successful approach would be one that addresses the needs and concerns 20 of all three groups and identifies solutions to problems at one level that may make things better at other levels of the report- ing process. Because it is not possible to identify an existing system that satisfies this multilevel definition, it is important to examine the successes at each level to see how their appli- cation might be adapted to meet the needs of all stakeholders. For purposes of discussing successful crash records sys- tems, it is necessary to identify successful practices in the three major components of such a system: ⢠Crash data collection, ⢠Crash processing and management, and ⢠Data linkages for reporting and analysis. CRASH DATA COLLECTION Law enforcement agencies task sworn officers and other des- ignated report writers to respond to crashes in their jurisdic- tions. In addition to arranging for appropriate emergency ser- vices, securing the scene, gathering evidence, and clearing the roadway as soon as practical, investigators must create the basic record of the circumstances involved in the crash. Even when officers fully understand the importance of high- quality crash data, their ability to perform this task is chal- lenged by competing priorities, specific gaps in training or expertise, and often a simple lack of access to the source of required information. A successful example of addressing this problem is the use of civilian crash investigators for all crashes that do not require a sworn officerâs presence. There are cities in Florida and other states that have successfully used trained crash investigators for many years. A successful system for crash data collection would incor- porate the technologies needed by crash investigators to ensure accurate data, ease of completion of the form, as well as seamless transfer of the data to the supervisor, the local crash records system (if desired), and the statewide crash records system. In this respect, the choice of software and hardware tools should meet their needs and be a good fit with the existing and planned information technology initiatives at both the local and state agencies. In that respect, âone size fits allâ may not be possible, as we have seen when large cities within a state may be unwilling to use software devel- oped or purchased by the state. A recent example of this phe- nomenon is the city of Chicago, which does not believe that CHAPTER FOUR SUCCESSFUL CRASH RECORDS SYSTEMS AND INITIATIVES
21 the Illinois crash data collection tool meets their needs. To facilitate the receipt of suitable electronic crash records from Chicago, the state of Illinois has initiated a data-for-data part- nership as an incentive, providing Chicago with the state data they could not have accessed by themselves in exchange for crash data that meets the state criteria. Conversely, some states such as Iowa are able to support all of the local agencies with the same state-provided crash data collection tool. It is important to recognize that crash records systems are not static. No matter how effective a data collection tool may be today, these systems must be maintained and upgraded to take advantage of newer technologies. A system that works well today may suddenly become untenable when a local department upgrades its dispatch and records management systems. Software written in one language may be costly to change when the main providers of the development tools no longer support that language. At present, this is the case for systems written in Visual Basic, because Microsoft has announced it will no longer support the language. Just as with legacy applications written in COBOL a generation ago, the cost of maintaining Visual Basic programs will gradually increase and the ability to update the software with new func- tionality will diminish over time. At a minimum, systems need to be updated when the crash report form changes. To meet reporting requirements, the electronic report may need to be modified to meet the new standard. Changes may be required to the data entry screens, the underlying database, the report image (printed or electronically generated graphic), and other features of the software. Planning for these updates is the responsibility of the state or local agencies that purchased them. The lead times for many governmental agencies are such that planning more than one year out is crucial to timely implementation of any change. A sign of a successful system is one supported by an agency that has built the cost of main- tenance into the annual budget and begun funding updates and improvements right from the start. The Indiana and Illi- nois crash records systems were developed in part using more current .Net technology. Systems such as those in Ken- tucky and Iowa are already planning upgrades to the newer technology as well. What Are Crash Data Collection Tools? There are many examples of automated crash data collection tools. The simplest of these tools are designed to allow com- pletion of a form in a word processing application that allows for printing out a completed hard copy crash form to send to the state reporting agency. Except for solving the problem of illegible handwriting, these low-end systems really do little to improve the crash reporting process. The information on the form is not captured as data and there are few edit checks or other built-in tools to assist the officer in completing the form accurately according to departmental standards. On the high-end of automated crash data collection tools are systems such as TraCS, used in Iowa and other states, and MCRS used in Illinois. These systems allow crash data entry in the field with validation edits, use of maps to pinpoint locations, and electronic transfer of data to other systems. More importantly, these data collection systems either allow access through the state telecommunications network for ver- ifying driver and vehicle data or provide the tools to scan information from the vehicle identification number, registra- tion papers, vehicle plate, and driverâs license. This ability to communicate with other systems while in the field reduces data entry by automatically filling data fields and better ensures linkage to these data files in the future for analysis and reporting. At this level of sophistication, examples of tools that should be included are those that: ⢠Read bar codes or magnetic strips from the driverâs license and the vehicle identification number and/or vehi- cle plate, ⢠Collect coordinates of the crash location using GPS or GIS locator routines, ⢠Automatically populate data fields whenever possi- ble, and ⢠Share information among the various reports that the officer has to complete. As mentioned previously, sometimes even the best of crash data collection tools are not sufficient to convince a large city to give up its own local systems. For example, Chicago and its surrounding counties generate approximately 50% of the crashes in Illinois. To obtain these crash records in electronic form, the Illinois DOT is promoting the data-for-data part- nership. They plan to provide web services that include access to data that Chicago cannot get on its own, in exchange for receiving the cityâs crash data in the appropriate electronic format. One web service will serve as an Internet-based con- duit from the local agency (in this case Chicago) to access statewide driver and vehicle files to verify data. A second web service will serve as the GIS for all localities to use to pinpoint the crash location, thus ensuring consistency in loca- tion coding. The Illinois DOT is committed to adding other services as identified and sharing these services with locali- ties in exchange for the electronic submission of their crash records in the required format. Why Implement Crash Data Collection Tools? Implementation of the proper crash data collection tools can reduce the overall time spent processing crashes. The savings may not always be realized in the field (by the officer com- pleting the forms), because it may take just as long to collect the information as it would with a paper form. For example, it may take just as long to gather witness statements and to com- plete other time-consuming tasks. Overall, agencies that use crash data collection tools will realize significant cost savings by reducing paper handling and duplication of data entry tasks,
22 while improving the data accuracy. When supervisors review crash reports, for example, if the collection tool incorporates sufficiently robust error trapping and field validation, the reports are more complete and meet the departmentâs stan- dards for consistency. The supervisor can thus concentrate on the sufficiency of the information and not spend time check- ing to see that every required field is completed. Once reports are accepted, they can be stored directly in the departmentâs crash records system, if desired, thus avoiding data entry at the local agency. In addition, if the state crash records sys- tem is capable of accepting reports electronically, the local agency can send data directly to that system without having the data printed and mailed. This saves time and resources at both the local law enforcement agency and the state crash custodial agency. That these quality improvements and time savings also accrue to the state crash records operation means that the best solution for local law enforcement can also be the best solu- tion for central data managers as well. Higher quality data are available faster and without the need for intervening data entry steps. This also helps users who need better data faster. In short, the implementation of high-end crash reporting tools in law enforcement agencies is a way to benefit all crash records stakeholders. How a Crash Data Collection System Works There are many ways to implement a successful crash data collection system. The following is one example that incor- porates currently available technology and yields the desired benefits in terms of improved quality, timeliness, and reduced data entry and printing later in the process. Other variations can yield similar successful results. The reporting function begins on a portable computer or, at a minimum, a vehicle-based computer, when an officer, or civilian crash investigator, arrives at the crash scene. When the officer begins to complete the crash report form, the soft- ware provides guidance through the process by highlighting required fields and providing pick lists, common definitions, and built-in help files as needed. A swipe of the driverâs license initiates a check against state driver records for the individual involved in the crash and returns with name, address, and vehi- cle information, along with any alerts associated with that person (e.g., outstanding warrants and license status). The officer can accept the name and address and the software will automatically populate the form. Entry of a license plate num- ber for the vehicle initiates another check with state motor vehicle records and information about that vehicle comes back to populate fields as needed or alert the officer to prob- lems (e.g., this is a stolen vehicle or other alerts). The perti- nent information is also stored in a contact record so that the system uses it to automatically complete name, address, vehi- cle, and license information on any of the many types of reports completed. For states without the necessary tele- communications capabilities, an investigator may also col- lect much of this information by scanning a driverâs license, registration papers, vehicle identification number, or vehicle license plate. Meanwhile, the linked GPS unit gathers the geographic coordinates of the crash location. This assists the officer in determining the exact location of the crash at a later time. A record can be created of the county, road name, distance to and from the nearest point or intersection, and may correct the GPS coordinates to snap to the location referencing sys- tem used by the state DOT. The location information is now available to be used on any other types of reports as needed. In the Illinois example, roadway and traffic characteristics are automatically attached to the crash at the time the loca- tion is identified to create a single linked record with both crash and roadway variables. The officer then completes the form, making a drawing of the scene, recording a narrative description of the crash, and entering witness statements as needed. Many of the fields use a pop-up pick list from which the officer selects from the pos- sible responses. The software reminds the officer to fill in the required fields and automatically activates any required sup- plemental data fields and forms based on the information the officer has entered so far. As the form is completed, addi- tional edit checks alert the officer to mistakes or inconsis- tencies that may cause the departmental or state crash records system to reject the report. The officer can then electronically forward the completed report to the supervisorâs computer for review. The report can be transferred through the state telecommunications, or by means of a wireless network, by docking a portable com- puter at the end of the shift. The supervisor checks the report and adds comments for corrections before sending it back to the officer, or forwards it to the official crash database if the report is acceptable. At that point, the crash report may be processed through another set of edits and quality control measures. Additional edits may be needed, particularly in a case where the data collection is not occurring while directly connected into the state system. In some cases, the system is a local crash system that then forwards the crash data elec- tronically to the state system and in some instances, the crash report is moved directly into the official state crash records system. Ancillary Benefits to a Crash Data User Because an automated tool can collect crash data with a robust set of edit checking features, the quality of the data can be improved significantly. This also improves the timeliness of data in the crash records system because there is little or no delay for data entry and forms management at the crash cus- todial agency.
23 Edit checks in a crash collection tool can serve as a training tool by providing feedback to the law enforcement department and the officer immediately on receipt. Instead of finding out about errors months after the event, officers and supervisors can get immediate feedback while the information is still fresh and the people involved in the crash can easily be contacted. This continuous training and feedback improves the overall quality of the crash data. CRASH PROCESSING AND MANAGEMENT The official crash records custodian typically resides in a DOT, department of revenue (DOR), or department of pub- lic safety. In any case, the responsibility for collecting and managing crash data may not be a central mission of the cus- todial agency and it may, at best, be responsible for the field data collection of only a portion of the data they manage. For example, the primary operational missions of a DOR are to title vehicles, license drivers, and collect fees. If a DOR is the custodial agency for crashes, and yet it is rarely a user of those data, there may not be an understanding or emphasis on expending resources to develop a successful crash records system. Likewise, when another agency is the custodian of the crash records system, but would like to link to driver and vehicle files, the DOR may not have their operational data in a form that is conducive to combining with crash data. Traditionally, agency staff works from a paper forms pro- cess and enters data manually to create a crash records system. Typically, specially trained staff has completed required tasks, such as adding location codes and pre-processing coding forms before data entry. The information is entered as recorded on the form (or as annotated by the location coders and others). In some cases, such as in the Arkansas system, off- site contractors do the data entry. In Tennesseeâs state crash records system, a batch transaction file is run through a series of edit checks before the crash is added to the official database and error reports are printed from the overnight data run. Until recently, an entire batch of 25 to 50 crash reports had to all pass the edit checks before any single crash could be accepted into the system. Either the errors that would block acceptance of the crash report are corrected or, as is still the case in many states, the form is returned to the officer who wrote the origi- nal report. For states using this traditional procedure, the data entry lag is such that there is little expectation that a returned crash report will ever make it back for entry into the system. In most states, a separate process of document manage- ment is accomplished either through microfilm, paper stor- age, or, more recently, digital imaging. This process creates an archive of the original crash report forms for later use and is used to route the crash record to the appropriate staff for entry into the crash records system. The most successful examples of document management include a digital imag- ing component that allows paper crash forms and supple- mental documentation to be accessed easily during data entry or later during analyses of the data. The document manage- ment system can easily be modified to adjust routing of doc- uments to various stations to be handled, such as to the FARS analyst. What Is Crash Processing and Management? A successful crash records system accepts electronic data from law enforcement agencies throughout the state, either directly or from local crash records systems. The hope of col- lecting all crash reports electronically may never be realized; however, most states are able to significantly reduce their man- ual data entry process by working with state police and large local law enforcement agencies. Through a combination of an automated crash data collection tool and web-based crash report forms for use by departments that lack field automa- tion, the majority of the crash reports could be delivered to the state crash database in electronic form. This has the advan- tage of creating a centralized record that includes all fields on the crash report form, already checked for accuracy and com- pleteness, and available in the database in a timely fashion following completion by the crash investigator. Examples of successful systems include those where the state encourages electronic data by ⢠Defining standards for acceptance of crashes into their system (e.g., Maryland and Michigan). ⢠Making data collection software free to the local agen- cies (e.g., Iowa and Kentucky). ⢠Allowing officers to work directly on-line to the state system (e.g., Illinois and Indiana). The most successful systems accommodate both elec- tronic and paper crash forms. With the view that there will always be some level of manual data entry required, changes to the stateâs processing of paper documents is usually required when it moves to accept electronic data. These pro- cess changes typically result from the need to retain an image archive. The reason for this process change is that managing paper documents is not the same as processing electronic forms when it comes time to generate an image. The electronic form exists as data in a database. It contains the narrative and diagram and many other fields that are not typically entered manually into a crash records system. In other words, it is pos- sible to generate the image of a crash report form from data created electronically, but it may not be possible to do so with a crash record entered manually without a diagram or narra- tive. If all paper crashes are digitally imaged in a document management system, however, it is much easier for users to locate all of the crash forms when needed. Why Create a Crash Records System? There are numerous benefits of creating a successful crash records system. Two examples are the reduced cost of data
entry and the reduction in duplicate data entry into multiple crash records systems. The data entry staff will only have to deal directly with those reports that are submitted on paper. The state may still need specialized post-processing staff to handle location codes (or at least verification of locations), as well as any other post-processing that cannot be automated. However, the overall data entry requirements will be much more focused toward quality control issues once a sizable portion of the crashes is submitted electronically. This has the immediate effect of reducing the backlog of crash reports awaiting data entry. Because the reports are checked for errors sooner (even paper reports get attention sooner than before), it is much more likely that errors can be corrected. Crash reports received electronically will have already gone through error checking and validation before acceptance into the state- wide system; therefore, overall quality of the crash data will be improved. Another benefit of a successful crash records system is its ability to deal with image archiving in a more reliable and less space-intensive fashion. For crash reports that arrive in electronic form, the image can be generated by the system as needed and need not be stored as a graphic file. If the storage of graphic files is desired to maintain a record of changes to the crash report, the storage media are smaller and less prone to damage or image degradation than are microfilm or hard copy storage. Thus, the cost of maintaining the archive is reduced. Staff time required to create the image archive will diminish as more crash reports are received electronically. Most states using state-of-the-art document management systems are able to image their crash report forms and all supplemental documentation well within 24 h of receipt (e.g., Illinois, Indiana, and Iowa). Aside from the technical benefits, however, the primary reason to create a successful crash records system is the advan- tage that all users can access the same crash data that is com- plete, timely, and accurate. The time and financial resources currently expended on crash data collection, management and use, and multiple agencies and jurisdictions can be reduced significantly through coordinating these efforts. A successful crash records system will allow access to images as well as data, will be linkable to other data sources for safety analyses, and will provide a stable and reliable source of information for decision making. How Crash Processing and Management Work When a crash report is completed using a crash data collec- tion tool, the resulting data can be forwarded to the crash records system through a secure connection (e.g., TCP/IP, secure ftp, or other transfer protocol). At the receiving end, the data are run through any additional edit checks that may be needed and added to a pending file of the crash records system. At the same time, the image of the crash can be gen- erated using a graphic form processing tool and the image is 24 stored in an image archive database. This image is never changed, but newly received updates to the crash report data may result in a new image that can be added to the historical image archive. The image archive stores all versions of the crash report required by state law and the policies of the cus- todial agency. The web-based crash data entry form can also be used by agencies that lack the resources to implement field data record- ing. This system would have the same edit checks and transfer procedures as the crash data collection tool. A crash report that passes the edit checks on the web-based form is forwarded to the crash records system where it can be processed just like any other electronically submitted crash report. The newly developed Texas crash records system includes just such a web-based tool for use by smaller law enforcement agencies that do not believe that they have a need for a complete crash data collection tool or do not have the equipment to support automation in the field. Some local agencies may still submit a paper crash report form. The processing of these forms can be imaged with a dig- ital scanning process and the data entry operation can consist of a heads-up display for processing of the formâs content and for review. The new Illinois and Indiana crash records sys- tems use digital document management systems and heads- up data entry in this manner. The data entry employee still has to key in much of the form; however, it is now entered more quickly and there is no handling of paper once the imaging process is completed. When data entry is completed, the data for this crash are stored in the same manner as if it had been submitted electronically. The reason for the pending file in the crash records system is to allow for any necessary post-processing, including loca- tion verification and supervisory review. For example, the crash data collection tool in Illinois allows an officer to pin- point a location on a map; however, because of the impor- tance of location coding to the Illinois DOT, a post-process location unit verifies the coordinates based on the description of that location from their roadway characteristics database. Once the location has been verified, the roadway and traffic characteristics are automatically linked to the crash record. Once this post-processing is complete, the data are added to the official crash database, often within 24 h of receipt at the custodial agency. The image archive is updated nightly so that it too is available within 24 h of receipt. As much as pos- sible, the post-processing is automated so that most crash reports need minimal intervention to be added to database and image archives. Ancillary Benefits of Crash Processing and Management A successful crash records system has data that are timely, complete, and more accurate than ever before. Edit checks in
25 the data collection tools virtually eliminate the most common forms of mistakes so the data are more accurate and more con- sistent. Crash data are available much sooner than in the past and are more reliable, whether for interim reports or multiyear analyses. Decision makers can use current crash data and adjust to changes much more rapidly than in the past. In many cases, local agencies (e.g., law enforcement and engineering) can reduce the need to store data locally, dramat- ically reducing the cost of maintaining a local crash records system and creating multiple copies of the same data. In addi- tion, agencies that previously did not have automated sys- tems can use the statewide data as their source for informa- tion on crashes in their jurisdictions. The pressure to create redundant data systems is lessened and the agencies that con- tribute data to the statewide system can realize some cost savings, whereas others like county and city engineers and planning organizations may avoid those costs altogether. For agencies that wish to continue with their local systems, exports from the statewide crash database can be made readily avail- able for their use. Conversely, if data are entered into their local system, crash records can be electronically transferred to the state crash records system. DATA LINKAGES FOR REPORTING AND ANALYSIS Ultimately, to be worth the effort and expense of its creation and maintenance, a crash records system must support analy- ses for highway and traffic safety. Furthermore, the decisions based on these analyses must yield better solutions than other less expensive ways of making decisions. The underlying realization that environment, vehicles, and human factors all play a role in crash frequency and severity points directly to a need for data systems that can link these information sources. The current reality in most states is that no single agency has control of all the necessary data to make up a complete traffic records system. Most components of a traf- fic records system serve a primary operational purpose that may be far removed from highway and traffic safety analy- sis. It is through the work of practitioners and the coopera- tion of the stakeholders that anything approximating a com- prehensive traffic records system can be created. It is critical that data collectors and managers understand that the infor- mation in crash records systems must be of sufficient com- pleteness, accuracy, and timeliness to be useful for highway and traffic safety decision making. As the capabilities of computer systems and software have grown in recent years, the ability to support large-scale integrated databases at a reasonable cost has become a real- ity. At the same time, states have worked to overcome insti- tutional barriers to sharing data with authorized users both within and outside of government agencies. At the time of this synthesis, there existed successful examples of linkage of traffic records system components. Whether establishing a crash data clearinghouse or assigning trained staff and resources to conduct ad hoc linkages, the important result is a knowledge base that can support ongoing safety data analy- ses. The basics of what constitutes a knowledge base for traf- fic records are sound no matter what means is used to estab- lish it. More important is the potential for focusing on serving users needs efficiently with knowledgeable staff that makes this concept appealing for decision makers, data system man- agers, and budget-minded agency heads alike. For these rea- sons, this section of the synthesis focuses on supporting the linkage of the crash records system to other data sources for reporting and analysis. What Is a Knowledge Base? A knowledge base, whether established physically as a data clearinghouse or as a staff that performs ad hoc linkages and analyses, is a one-stop-shopping place to get the needed data and assistance to support highway and traffic safety analysis. Any potential user of any component of the traffic records system should be able to access the knowledge base and retrieve ⢠The data they need (including multiple years of data) from available sources, such as crash, roadway, driver/ vehicle, medical, enforcement, and court records; ⢠Reliable databases that link records from the various data sources; ⢠Expert advice on the contents and limitations of these data and how to use them reliably in combination; ⢠Assistance and advice on conducting analyses and inter- preting the results; and ⢠Access to other traffic safety stakeholders, including data collectors, managers, and other users. Many states are moving toward an actual data clearing- house that meets the definition of a knowledge base. Col- orado, Delaware, Kentucky, and Massachusetts all have var- ious pieces of this type of system built and available for use. Many states make multiple years of linked roadway and crash data available to highway safety professionals. Some states, such as Missouri, have a data clearinghouse that includes not just crash and roadway data, but multiple other roadway-related databases as well. Thus, linkage of at least part of the components of a traffic records system is within the reach of practically every state. Creation and staff sup- port of a crash data clearinghouse is not a one-time effort and it requires ongoing resource commitments. What may be less obvious is that a knowledge base of professionals that can support ad hoc linkages of data also requires con- tinuous resource commitments to be successful, and most states continue to support ad hoc linkages of the various data sources for safety analyses. The most successful of these states invest in training and knowledgeable support staff to support these efforts.
Why Create a Knowledge Base? The best argument in favor of a select group of professionals to support linkages and analyses is that it will provide consis- tent and trained service for decision makers by delivering data and analytic support. This type of argument would require that multiple agencies compare the cost of their analytic sup- port and data sharing efforts at this time and estimate what they could relinquish if a single knowledge-based staff took on selected tasks. A likely impetus for creation of such a knowledge base comes from the inability of agencies to meet the rising demand for access to data and requests for assistance in using the data. In an era of budget constraints and contraction of agency services to only the âcoreâ business missions, a cen- tralized knowledge base is one way to gain efficiency and pro- vide a necessary service that normally would be outside of any single agencyâs purview. It is also a way to eliminate the nonconstructive arguments between agencies about the âoffi- cialâ numbers on traffic-related injuries, deaths, and costs because everyone would be working from the same set of numbers. Communication about the data and how to use the data correctly is also simplified when there is a single source. How a Knowledge Base Works On a periodic basis agreed to by each agency that acts as cus- todian of a component of the traffic records system, a copy of their data is forwarded to the data clearinghouse or the staff resources assigned to be the knowledge base for safety linkage and analysis. The agency will also provide current documentation, a data dictionary, and contact information. Ideally, the data submitted are as complete as possible in that personal identifiers are left in the file at this point to assist in linkages. However, the staff would be responsible for remov- ing any identifiers based on the custodial agencyâs require- ments before releasing any information. Because files may contain information that cannot be released to the public, archival copies are generally not made available to anyone except those authorized by the custodial agency and only for limited purposes. The staff will generate an extract for general release that has all personal identifying information redacted in accor- dance with applicable privacy laws. At that point, the data will be available for general release to authorized users. The staff can then use the original data again to create one or more linked databases as needed. Because linkages among traffic records components often are most reliable when using per- sonal identifiers as linking variables, the personal informa- tion is left in the files until the linkage is performed. When this is not possible, or where that linkage fails, a probabilis- tic matching process may be needed. The resulting linked datasets can then be purged of personal identifiers and made available to authorized users. 26 This knowledge base staff can perform other important duties in conjunction with the release or analysis of data. These duties include calculating quality control measures, processing data dictionaries and coding manuals, creating basic standardized reports, updating contact information, and documenting the availability of the data. All of these prod- ucts support the authorized users, including the custodial agencies. By virtue of their experience working with each of the data sources, the staff acquires knowledge of the contents and limitations of each database. They become ideally suited to serve as an analytic resource to assist other users, and they can communicate the caveats about each database and help users formulate questions in a manner that can be reliably answered using the data. When users need help conducting an analysis, the staff can explain the coding and structure of each file or they can conduct analyses for the users. Ancillary Benefits of a Knowledge Base A knowledge base, whether through a data clearinghouse method or through a specialized staff method, brings the pos- sibility of meeting usersâ needs in a highly visible manner. It is assumed that better customer service will support expanded use of the data by a larger number of people drawn from a broader spectrum of users. To the extent that these new users see themselves as stakeholders in the traffic records system, they can in turn support improvements to all the components of the traffic records system. One important possible benefit of a traffic records knowledge base is the building of a coali- tion that will help to support expansion and improvement of the system that supports them. With this in mind, it is sug- gested that the knowledge base include customer service measurements and that the staff maintain a customer contact database. SUMMARY Data collection, data management, and data usage are the three areas that define the success of a crash records system. There is currently no single system in the United States that would meet any reasonable definition of a best practice approach to all three areas simultaneously. There are, how- ever, examples of systems that are successful in one area or another. Based on these examples, and using the literature and consultant experience with traffic records systems, some overall descriptions of systems that are possible with todayâs technology and could serve the needs of stakeholders at all levels of the traffic safety community were developed. These descriptions are summarized here. Crash Data Collection The most promising approach to crash data collection is an automated field data collection tool that is used to capture
27 data collection and electronic data transfer. The savings in reduced data entry, along with improvements in data quality and timeliness, will benefit all stakeholders. Data Linkages for Reporting and Analysis Crash data alone do not serve as the sole basis upon which to make highway and traffic safety decisions. A comprehensive traffic records system is required with linkable components to support analyses of all types of data. In most states, a full traffic records system could not exist in a single agency and have it fit well with the core business of that agency. For example, an agency that is responsible for issuing licenses to drivers and titles to vehicles may not have the resources to support other components of a traffic records system that do not assist them in completing their agencyâs primary mis- sion. A traffic records knowledge base, either through a data clearinghouse or through resources dedicated specifically for ad hoc data linkages and analyses, is a method for a state to achieve the goal of serving the needs of all highway and traf- fic safety stakeholders. A knowledge base supports all or most components of the traffic records system readily available to the users for analy- sis and reporting. Data sources are linked directly with the crash data or linked indirectly through probabilistic matching. This type of knowledge base is one way to increase the util- ity of crash data for less experienced users and to help build strong advocates for traffic records improvement throughout the state. The Missouri DOT is an example of a directly linked data system that primarily supports only that agencyâs users. The Massachusetts data warehouse is an example of a university-based system with Internet access for analysis and reporting given to all approved users. Although the number of traffic records data clearinghouses is increasing, most states conduct data linkages on an ad hoc basis, often using university-based staff. information as close to the event as possible. Field data col- lection hardware can include a portable or in-vehicle com- puter, GPS unit, magnetic strip and/or bar code reader, and other technology as desired. The officer using this tool would be able to link with the state driver and vehicle data to com- plete sections of the crash report without having to reenter information that already exists electronically. Officers may also scan information directly from vehicle identification numbers and/or registration documents, license plates, or driv- erâs licenses to obtain information for their reports. The field software tool can include edit checks that match those in the statewide crash report system and prompt offi- cers to complete all required fields, including supplemental reports. A supervisor could then automatically review the resulting crash report. Once accepted, the report can be sent to the agencyâs local records management system, if desired, as well as to the statewide crash records system. This paper- less process would also support generation of a graphic image of the form suitable for printing and archival storage. The primary advantage of automated field data collection software is a reduction in the time spent in records manage- ment and supervisory review. The improvement in quality and timeliness of the crash data benefits all stakeholders in the traffic safety community. Crash Data Management Crash records systems must have the capability to accept data electronically. Adding this capability often results in major updates to the structure and processing of a statewide crash database. However, the document management and archival storage of crash reports must accommodate both electronic and paper forms if the system does not create an electronic image of the crash report form. Some manual post-processing of crash information, especially for quality control of loca- tion coding, is advisable even with automation of the field
