Making Changes: Label Mismatches and How to Avoid Them

When you are making changes to radio button, drop-down, or checkbox fields in REDCap, it is important to be aware of label mismatches. Label mismatches can inadvertently happen when a field’s existing choices are changed. This can have disastrous effects on your data’s integrity. Read on to learn more!

Labels vs. Values: A Quick Primer

I decided that I want to collect data on people’s favorite fruit, so I created a multiple-choice field with 5 different options – apples, bananas, grapes, oranges, and pineapples.

Each choice has a number followed by a comma next to the choice. The number is the choice’s value. The text next to the number is called the label.

Values and labels have an important relationship to one another. Values are the number that is stored in REDCap’s backend database. Labels are what assign meaning to these numbers.

For example, assume that I selected Apples as my favorite fruit while completing the survey. The value for Apples is 1, so REDCap stores 1 in the backend database.

After I began data collection, I decided I want to add a sixth option, Pears to my list of fruits. Let’s look at two different approaches to making this change in REDCap.

The Incorrect Way – DO NOT Do This!

Often, we want our choices to appear in a specific order to survey respondents. In this scenario, I decided I wanted my choices displayed in alphabetical order.

I changed the label of value 5 from Pineapples to Pears.

Then, I assigned a new value of 6 to Pineapples.

Wait! While this approach may seem harmless, this change will have a negative impact on my dataset. Here’s why:

Before drafting this change, a total of six survey respondents selected Pineapples as their favorite fruit. The assigned value for Pineapples is 5. The value 5 is stored in the backend database for each of the six respondents.

Changing the label for 5 from Pineapples to Pears changes the meaning of 5. However, the stored values in the backend database DID NOT change. This means that 5 is STILL stored for all six respondents that selected Pineapple.

BUT – here’s the big problem: 5 does not mean they picked Pineapples anymore. 5 means they picked Pears! Now, it appears that the six respondents picked Pears, when they had actually picked Pineapples. I have introduced an error in my data!

The Correct Way – Do THIS Instead!

The best way to avoid label mismatches is by treating the relationship between values and choices as “set in stone.” Do not swap, move, or make other changes to existing choices in your project.

Instead, any new choices should be added in with new values. Do not worry – you can still order your choices as you wish. The value of a choice has no effect on its ordering.

Because I wanted Pears to come before Pineapples, I assigned Pears a new value, 6.

Then, I placed 6, Pears above 5, Pineapples in the choices box.

This will ensure that my data does not become “mixed up” like in the previous example. My choices will also appear in their desired order.