Problems with Diebold
DIMS Voter-Registration System
Through personal observations, analysis of DIMS reports or data extracts, and discussions with Cuyahoga County Board of Elections employees, I have documented the following problems with the Diebold DIMS Voter-Registration System and the data maintained within DIMS system.
1) DIMS allows the entry of bad addresses (incorrect street names). These bad addresses can be entered without notification by the system that the street name is misspelled. Only later are these bad addresses flagged as “Fatal Pending.” They should be flagged at the point of data entry, or, better yet, “selected” from a set of valid county street names. Many of these “fatal pending” individuals were denied their vote because of data-entry errors of their address. (See “Fatal Pending” analysis at--http://ohiovigilance.org/Counties/Cuyahoga/Analysis/CuyFatalPendingAnalysis.pdf)
2) DIMS doesn’t have a good means of preventing duplicate records for the same individual. According to a BOE manager, the system is “not very forgiving.” I saw numerous examples of duplication in the poll books as well as in data extract files.
3) When I went to vote absentee, the clerk tried to find me “in the system” by my name, but couldn’t. She then asked for my address, and was able to find me by my address. She related that she had to resort to that “workaround” fairly often (i.e. look up people by their address rather than their name) and said that the system was new (implemented in September 2004) and still had bugs. When I asked if they were going to fix the bugs before the election, she replied “Oh, no, there isn’t time. They’ll have to fix them after the election.”
4) Many people tried to locate their correct precinct through the Cuyahoga Board of Elections website, but were unable to do so. I tried entering my address several times, without success, before finally locating my correct precinct. Others weren’t so lucky. The data used for the website “precinct lookup” had to come from DIMS, the voter-registration system.
5) I found a handful of duplicate precincts in the database—same precinct name, but different internal precinct numbers.
6) There are several tables, where “would-be voters” are maintained: (1) valid voters, with status of “A” (active) “I” (inactive) or “C” (cancelled) ; (2) provisional voters—voters who voted provisionally on election day, probably because their name failed to show up on the voter-registration poll books; and (3) “fatal pending” individuals -- people who were ineligible to vote because there was something wrong with their registration (bad street name, missing date of birth. The DIMS database design allowed the same person to be located in two or three of these tables, each with slightly different spellings of name or address. (See “Fatal Pending” analysis at--http://ohiovigilance.org/Counties/Cuyahoga/Analysis/CuyFatalPendingAnalysis.pdf)
7) There is no history of a person’s status—“A”, then “I”, then “C”, etc. Only the current status is maintained.
8) There are many individuals with no voting history who are eligible to vote--“A” or “I” status. (see Cancelled Voter analysis at http://ohiovigilance.org/Counties/Cuyahoga/Analysis/CuyCancelledNonVotingAnalysis.pdf.) I was surprised to find tens of thousands who were still eligible to vote even though they should have been purged, yet tens of thousands who were purged for not having voted in the last two federal elections. The purging process should be more strictly controlled to prevent the discriminate purging of voters.
9) DIMS should have the ability to print out notification cards to individuals who have recently been purged or, better yet, for those who are targeted for purging. I overheard several distraught voters who claimed they were never notified that they were (or would be) purged, only to find out, too late, that they would not be able to vote in the 2004 election.
10)
There are many cases of bad voter names—e.g.
names like “
11)
There are many cases of bad dates—many with
default dates of “
12) I was told by a BOE programmer that DIMS didn’t have a place to store “cancellation date.” Several other employees disagree with this claim.
13)
According to a BOE employee (who learned from a Diebold employee), DIMS was designed for
14) According to a manager in the Absentee department, the DIMS Absentee Voting logic had numerous problems. For example, one report was said to print out records for every other voter. There were many who never received their requested absentee ballots, and I was told that “boxes” of absentee-ballot requests were never entered into DIMS.
15) When clerks were using DIMS to record rejected provisional ballots, they were not permitted to enter sufficiently detailed rejection reasons. For example, for the many voters whose registration had been cancelled due to non voting in the last two federal elections, the only appropriate rejection reason was “Not Registered.” Rejection reasons should have included, as sub-categories of “Not Registered” at least the following: “purged for not voting”, “purged for felony”, “fatal pending – bad address”, “fatal pending – no birth-date”, “voted in the wrong precinct”, etc.
16) When the old voter-registration data was converted to the new DIMS system, hundreds of voters were somehow dropped from the rolls. (See study conducted by Dr. Norman Robbins.)
17) When old voter-registration data was converted to the new DIMS system, the cancellation date was not carried over. I asked for voter-registration data with cancellation date back in mid November and received this data in March of 2005.
18) Most computer applications have a mechanism for generating extract files that can be imported into other applications. I was told that, with DIMS, the process of generating extract files from as few as two “joined” tables was laborious and difficult. I was told by a programmer that she was having trouble doing an “outer join” to give me cancelled voters’ demographic info along with cancellation reason. I was told by the head of IS that it was unreasonable for me to ask for extract files of rejected provisional voters—that the effort required to generate this file was too great to justify my request. If this it true, then there is something lacking in the DIMS software/database design.
19) The data in DIMS is very dirty. This can be seen by just observing the unrealistic data, the duplicates, the inconsistent statuses of voters, the bogus dates, the bad addresses, etc. A study was conducted by Deloitte & Touche in 2002 that describes the severe data quality problems. What measures were taken to clean up this data?
20) I received DIMS report which listed the provisional voters who voted in the wrong precinct. Of the 2150 individuals who were identified as having voted in the wrong precinct, 365 were in the correct precinct after all. Was this a DIMS data-quality problem or a procedural problem? DIMS should not have permitted people to be rejected for “wrong precinct” when the voted in the correct precinct.
Having been a systems analyst and software developer for 35 years, I was shocked to learn that DIMS was installed two months before the largest election in modern times. Installation of any “canned system” requires a significant amount of 1) customization to fit the particular environment, 2) data conversion between the old and the new systems, 3) system testing, preferably in parallel with the old system, and 4) training of system users. Given the time frame in which DIMS was implemented, it is not at all surprising to learn of the above cited system problems.
Victoria Lovegren, Ph.D.
Founder,
Report revised