The following HTML text is provided to enhance online
readability. Many aspects of typography translate only awkwardly to HTML.
Please use the page image
as the authoritative form to ensure accuracy.
Improving State Voter Registration Databases: Final Report
It is commonly believed that direct linkages (real-time electronic interfaces) between systems are essential for effective data exchange. Although direct linkages generally provide the most current and recent data (because they have direct unmediated access to the database in question), they are often expensive to deploy and complex in operation. By contrast, data can also be exchanged using the sending system’s ability to “export” its data into a known file format (e.g., an Excel spreadsheet, or a comma-delimited file). Such a file can be written onto a physical medium or sent electronically. This approach may not capture the most recent data, but since most systems support a data-export function, it entails a very low cost of operation.
In addition, file comparisons can usually be performed offline, that is, using applications separate from the core VRD application that read the exported files. Offline applications have the major benefit that they can be developed without rewriting the VRD system itself, and they thus pose little danger to its functionality.
Recommendation L-22: Develop national standards for data-exchange formats for voter registrationdatabases.
Standardized field definitions for database records greatly facilitate the common processing of records derived from different databases, as might be entailed, for example in a search for voter registration records for the same person in two different databases. For example, one database may record dates in a yyyy-mm-dd format and the other in a dd-mm-yyyy format. Or, one database may include a suffix such as Jr. or Sr. as part of the last-name field, and another might include a separate field for suffixes.
One approach to implementing standardized field definitions is for every database to adopt the same conventions for recording data. Thus, any export of that data outside the system’s boundaries would automatically be rendered consistent with any other database. On the other hand, requiring all systems of record to convert to the same standard field definition necessarily entails operational costs (e.g., disruption to current ongoing operations, costs of reprogramming internal logic of the applications using the databases, and so on) and is thus impractical.
A second approach, and one recommended by the committee, focuses on standards only for data interchange—that is, standardized field definitions only for data that are intended to be used by another database system. With such an approach, the internal logic of applications can remain unchanged (because the data are stored in the same format as before). But the data are converted into this standard form when data are prepared for export.
Standards for name, date, and SSN representation are, in principle, not difficult to implement. The last-name field should include name suffixes, such as Jr. or III.
The implementation of this recommendation would do much to facilitate the matching of records within different VRDs. But the committee also notes that the data of interest for matching VRD records— name, SSN, date of birth—are sufficiently standardized in their definitions that with the use of string comparators, these data fields can be used for matching purposes.