REDCap: What it is, and Why I Avoid Using it if I Can

*I may be compensated when you click on my links, but you will not be charged.

REDCap is a software that was built by academics for academics – it is basically “SurveyMonkey for researchers”. If you are familiar with survey software, you’ll probably agree that SurveyMonkey, Qualtrics, and most of the other popular survey applications work pretty well. So you might have that expectation of REDCap.

Unfortunately, there are some fundamental design problems with REDCap that make me want to avoid using it at all costs for research. These design issues have to do with a logical flaw in their design philosophy. SurveyMonkey and other survey software evolved to become very restrictive of what you could do when building the survey “front-end”. If you choose a date field, for example, it will usually link it to a real calendar for the purpose of validation.

By contrast, REDCap doesn’t have a lot of these restrictions, and it is likely because it was built by academics for academics. Academics rarely build databases, so they may have felt they were building in some sort of “academic freedom” by allowing whoever is building the forms to make such choices about the data. Here are a few “features” make it super easy to mess up a REDCap project:

• REDCap automatically produces a “field label” paired with a “variable name”, and the two cannot be divorced! These two items (controls?) are supposed to be married, in that the variable name is what it is called in the back-end, and the field label is what it should be called in the front-end. But if you are making some sort of fancy front-end and you erase the official field label paired with the variable name, you suddenly don’t really know what variable that is. You don’t really have a record of it anywhere in the system.
• REDCap has weird field types that allow you to be unreasonably “loosey goosey” with validation. For example, you can create a text field, and designate it as “date” or “time” or “numeric”, etc. This just leaves too many accidents waiting to happen, because you have to really lock down these fields with logical validation rules that probably no one has planned or developed, and program them in.
• REDCap will automatically generate back-end field names for you that have nothing to do with the content of the field. Nothing is more fun than trying to figure out what var1, var2, and var3 are, right?
• REDCap has a weird way of dealing with primary and foreign keys. REDCap runs on this concept called Record ID – which assumes that you are doing a study about people, and each one gets a Record ID. That way, if you do a longitudinal study where you fill out multiple follow-up forms on the same person, you just keep entering the same Record ID to link them. Of course, anyone who does research knows that your longitudinal databases usually have a much more complicated structure. We tend to keep the labs in one table, and neuropsychological test results in another table, for example. Linking all those together requires more than just one primary key for the individual. This is the method by which longitudinal data gets totally messed up in REDCap.

I encourage anyone curious about REDCap to watch this tutorial video below. You will see the instructor does not plan out any of these forms – he’s just entering field labels and variable names on the fly. That’s a great way to mess up a database!

Is it Possible to Avoid Using REDCap Altogether?

Yes and no. The answer is “yes” if you are working on a project that either has no human research obligations (e.g., the data are not about people). It is also “yes” if you are doing human research that will be reviewed by an IRB that is NOT associated with an institution that uses REDCap. So, for example, if you are a professor at a business college that probably doesn’t have REDCap but has an IRB, you probably can find a way to use SurveyMonkey or Qualtrics for your project.

But if the IRB you have to use is at an institution like Harvard or the Veterans Administration that have a REDCap system, the IRB will insist you use REDCap for your project. So if your project has to go through an IRB, and that IRB is at an institution that uses REDCap, then the answer is “no”, it is not possible to avoid using REDCap.

What are Best Practices for Using REDCap?

In summary, the best practices for using REDCap are as follows.

• Before you sit down to program REDCap, make sure you have developed extensive survey documentation. You should have already decided the variable names and labels, along with validation rules, and written them down somewhere before planning to program REDCap.
• If you encounter a “REDCap mess”, take steps to make the necessary documentation to clean it up. This documentation includes a manually-developed data dictionary, and annotated screen shots of the REDCap front-end.

If you want to learn more about doing both of these, please read my extensive blog post here.

Want to kick your health analytics career up a notch? Then click here to sign up for a 30-minute market research Zoom meeting with me, where I will explain a new, exclusive group mentoring program for health data professionals, and get your feedback.

Monika M. Wahi, MPH, CPH is a LinkedIn Learning author of data science courses, a book on how to design and build SAS data warehouses, and the co-author of many peer-reviewed publications. Sign up for her weekly e-newsletter, and follow her blog and YouTube channel for learning resources!