Core Data Systems
Click on each icon for a description of the system.
Crash data systems are administered by the Washington Department of Transportation (WSDOT) and the Washington State Patrol (WSP). This State repository stores law enforcement officer crash reports.
Driver data systems are administered by the Washington Department of Licensing (DOL). This State repository stores information on licensed drivers within the State and their driver histories. This is also known as the driver license and driver history system. The driver file also could contain a substantial number of records for drivers not licensed within the State—e.g., an unlicensed driver involved in a crash.
Vehicle data systems are administered by the Washington Department of Licensing (DOL). This State repository stores information on registered vehicles within the State (also known as the vehicle registration system). This database can also include records for vehicles not registered in the State—e.g., a vehicle that crashed in the State but was registered in another State.
Roadway data systems are administered by the Washington Department of Transportation (WSDOT) and the County Road Administration Board (CRAB). This State repository stores information about the roadways within the State. It should include information on all roadways within the State and is typically composed of discrete sub‐files that include: roadway centerline and geometric data, location reference data, geographical information system data, travel and exposure data, etc.
Citation & Adjudication data systems are administered by the Administrative Office of the Courts (AOC) and local jurisdictions. The component repositories are managed by multiple State or local agencies, which store traffic citation, arrest, and final disposition of charge data.
Injury Surveillance data systems are administered by the Washington Department of Health (DOH), the Washington Health Care Authority (HCA), and the Office of Financial Management (OFM). The component repositories are managed by multiple State or local agencies, which store data on motor vehicle‐related injuries and deaths. Typical components of an EMS/injury surveillance system are pre‐hospital EMS data, hospital emergency department data systems, hospital discharge data systems, trauma registries, and long term care/rehabilitation patient data systems.
Data Quality Attributes
Click on each icon for a description of the system.
Timeliness reflects the span of time between the occurrence of an event and entry of information into the appropriate database. Timeliness can also measure the time from when the custodial agency receives the data to the point when the data is entered into the database.
Accuracy reflects the degree to which the data is error‐free, satisfies internal consistency checks, and does not exist in duplicate within a single database. Error means the recorded value for some data element of interest is incorrect. Error does not mean the information is missing from the record. Erroneous information in a database cannot always be detected. In some cases, it is possible to determine that the values entered for a variable or data element are not legitimate codes. In other cases, errors can be detected by matching with external sources of information. It may also be possible to determine that duplicate records have been entered for the same event (e.g., title transfer).
Completeness reflects both the number of records that are missing from the database (e.g., events of interest that occurred but were not entered into the database) and the number of missing (blank) data elements in the records that are in a database. In the crash database, internal completeness reflects the amount of specified information captured in each individual crash record. External crash completeness reflects number or percentage of crashes on which crash reports are entered into the database. However, it is not possible to determine precisely external crash completeness as it is impossible to determine the number of unreported crashes. The measures in this report only address internal completeness by measuring what is not missing.
Uniformity reflects the consistency among the files or records in a database and may be measured against some independent standard, preferably a national standard. Within a State all jurisdictions should collect and report the same data using the same definitions and procedures. If the same data elements are used in different State files, they should be identical or at least compatible (e.g., names, addresses, geographic locations). Data collection procedures and data elements should also agree with nationally accepted guidelines and standards such as the Model Minimum Uniform Crash Criteria (MMUCC).
Integration reflects the ability of records in a database to be linked to a set of records in another of the six core databases—or components thereof—using common or unique identifiers. Integration differs in one important respect from the first four attributes of data quality. By definition, integration is a performance attribute that always involves two or more traffic records subsystems (i.e., databases or files). For integration, the model performance measures offer a single performance measure with database‐specific applications that typically are of interest to many States. The samples included are of course not exhaustive. Many States will be interested in establishing links between databases and sub‐databases other than those listed here, and therefore will be interested in measuring the quality of those other integrations. Note that some of the specific examples herein involve integration of files within databases rather than the integration of entire databases.
For the first five attributes, performance measurement is accomplished by the owners and operators of the various databases and sub‐files, by examining the data in the files and the internal workings of the files. Accessibility, which reflects the ability of legitimate users to successfully obtain desired data, is different. Accessibility is measured in terms of customer satisfaction. For every database and file in a traffic records system, there is a set of legitimate users who are entitled to request and receive data. The accessibility of the database or sub‐file is determined by obtaining the users’ perceptions of how well the system responds to their requests. Some users’ perceptions may be more relevant to measurement of accessibility than others. Each database manager should decide which of the legitimate users of the database would be classified as principal users, whose satisfaction with the system’s response to requests for data and other transactions will provide the basis for the measurement of accessibility.