Accuracy of Names and the Lack of Consistency between the US Social Security Administration and the CA Department of Motor Vehicles

I don’t know about you but there are few things that I’ve had as long as my name. Like many German immigrant families that moved to the United States, my ancestors chose a specific spelling of my name, Myers. I don’t know if this was intentional or just circumstantial, but to this day, whenever I provide my name over the phone, attending events, or registering for something, I have to clarify that my name is spelled “MY”ers not “MEY”ers.

You wouldn’t think this is a big deal, but to this day, I still have people who read forms that I have completed as “Myers” and the final product comes out like this (see image at right of my son’s basketball league jersey, spelled incorrectly).

There are two?Underlying Concepts within the Accuracy dimension as shown below.

Well, how could it be wrong you might ask. Recently, in the US there has been a move to include both last names in the legal name after marriage. I have second hand experience relating to this when an individual seeking to sign papers to transfer the deed for her home into the trust created for her and her husband. The notary identified the hyphen between her maiden name and married names (e.g. Lee-Smith) in the trust documents, but the lack of such on her drivers’ license.

It turns out that the Social Security Administration’s (SSA) system is antiquated and does not allow for hyphen characters to be stored in the system. It does however allow storage of an alias for the last name with a hyphen for the purpose of printing Social Security Cards. So to citizens this looks like it has a hyphen.

When Mrs. Lee first applied for a drivers’ license The California Department of Motor Vehicles (DMV) did not give her the option of using the hyphen, and their online validation against the SSA system (without the hyphen) seems to have prevented its correct creation at the beginning.

?

Figure 1. Communication between systems The CA Department of Motor Vehicles requires that names syntactically match between the driver's license and the person’s US Social Security Administration’s back-end system, named Numident. Alternatively, they must provide another official form of identification.

Because finding a long-term solution was not going to happen in a timely manner, the work around provided by the notary was to have two witnesses who have known Mrs. Lee for an extended period of time (I think it was at least two years) to sign, in person, saying that they testify that she was indeed Mrs. “Lee-Smith”. In this case a neighbor family (father and son) came over to Mrs. Lee’s house, met the notary and signed their testimony.

When the lady asked both the DMV and the SSA about this situation and how to get her drivers’ license updated, the SSA provided the official statement shown below.?

From a data quality perspective, given the definition of Accuracy, and the Underlying Concept of?Match to Agreed Source?outlined above, the SSA system is the system of record and most official source of truth and the DMV is a secondary official system. So what is the accurate spelling in the scenario above? Is it “Lee-Smith” or “Lee Smith”?

The answer to this depends on data governance. Which of the representations is the official one (the one acceptable to state DMVs)? That isn’t clear because I have friends whose last name on their drivers’ license does include a hyphen and the SSA analyst that Mrs. Lee spoke to, said that if she brings her physical SSA card with the hyphen included, he thinks the DMV will accept it and change her name on the license.?

Mrs. Lee brought the SSA card to the CA DMV but they would not accept that as an official form of identification. Primarily because it doesn’t syntactically match the back-end comparison that they do with the SSA system (Numident). The DMV advised Mrs. Lee to either get the SSA system to make the change (which we confirmed that it can not be physically changed in Numident), or to provide an alternative form of identification (see list here on the?DMV website). The only two relevant forms of ID acceptable to the DMV are the “Valid Permanent Resident Card” or “Foreign Passport”. It turns out that her foreign passport is from Japan (where they do not allow hyphens in the names), so that is not a viable form of identification.?

The next step (which is where we leave off) will be for Mrs. Lee to request that the US Citizenship and Immigration Services (USCIS) change her name to include the hyphen, and then resubmit the name change to the CA DMV. This sounds like a long process, so stay tuned!

Before we jump to some solutions (yes, as data quality experts it’s our job to always provide options), let’s identify whether there are any other dimensions of data quality that might apply to this situation. The last applicable Dimension is?Consistency, and specifically I mean?Format Consistency as defined below.

Format Consistency-?This measures the conformity of format of the same data in different places.

In this scenario, we lack Format Consistency when the SSA presents the name on the Social Security Card with a hyphen but stores it differently in the Numident system, which is used for display on SSA retirement documentation and the online website. Below are a few solutions to solve or to mitigate the problem.?

Note that I have ranked them in terms of short-term vs long-term solution and by effort (which usually translates into cost). Remember that even though you may personally (because us data quality folks are typically a bit preferential to the most pure solution) want to advocate a more perfect solution, your employer typically has the final say.

I know the solutions above are very brief and lack background input from the SSA and DMV system owners, but you get the idea. So, what’s the key take-away?

Take-away:

1. The take-away is that it costs much more to fix data quality issues, than to ensure it’s correct the first time (or second time). Therefore, we need to design quality into the systems we make. We can’t do this without knowing how to describe quality and how to measure it.?All business analysts should be taught the dimensions of data quality in school and in the workplace. This ensures that the business requirements gathering process uses the same data quality vocabulary and best practices.
2. Official formats (e.g. the printed version on the Social Security card) should be required of State DMVs not the system stored version without the hyphen because now there is inconsistency, confusion and complexity which drives up cost and lost time.

The Last Word:

Data quality improvement is continuous, data quality departments should be given release hours dedicated to make incremental improvements over time that support a long-term business roadmap so that optimal business stakeholder needs can be met. Does your company have a DQ backlog? Do you categorize all of your existing defects with a primary dimension of data quality?

What do you think? Let’s discuss this more in the?Conformed Dimensions of Data Quality group on LinkedIn.

??

Here are some resources that may benefit your organization going forward:

1. Annual Report and Webinar on the use of the Dimensions of Data Quality
2. Dan Myers’ DQJumpstart class with hands-on exercises communicating data quality with the Conformed Dimensions of DQ