REDCap Statistical Analysis: From Export to Publication-Ready Results

REDCap is used by the REDCap Consortium's more than 8,300 institutional partners across over 160 countries, with more than 4.4 million end users.¹ It collects data. It does not analyse it. The gap between a REDCap export and a finished Results section has more decisions in it than most trainees expect: which export format, which field type maps to which statistical variable, what to do with missing values, and how to handle non-normal distributions in small clinical samples.

How to analyze REDCap data, step by step

Both self-service routes end in the same place: a clean, typed dataset in a tool that can run the tests. The classic route goes through a CSV export; the direct route skips the file entirely and pulls records through the REDCap API.

Path 1: export a CSV, then analyze it in a statistical tool

1. In your REDCap project, open Data Exports, Reports, and Stats in the left-hand menu and pick the All data report, or a saved report limited to the fields your question needs.
2. Press Export Data and choose CSV / Microsoft Excel (raw data). Raw, not labels; the next section explains why this one choice matters more than any other.
3. Apply REDCap's de-identification options on the export screen so identifying fields never leave the system, then download the file.
4. Load the CSV into your statistical tool (SPSS, R, or StatsPlease) and map each field to its statistical variable type using the table further down this page.

Three things routinely surprise people in a REDCap CSV:

• Labels instead of raw codes. A labels export puts text (Yes, No, Male, Female) where statistical software expects numeric codes, forcing manual recoding of every variable.
• Checkbox fields explode into multiple columns. A single checkbox field exports as one column per choice, named field___1, field___2, and so on, each coded 0 or 1. That is correct behavior, not corruption: each choice is its own binary variable.
• Missing-data codes. If the project uses REDCap's Missing Data Codes feature, values such as NA or -99 appear in the export as those literal codes. Your software will treat them as real categories or real numbers unless you recode them to blank before analysis.

Path 2: connect StatsPlease directly to REDCap

StatsPlease can pull records, metadata, and field types straight from a REDCap project, so there is no file to export, clean, or upload.

1. In REDCap, get a project token from the API page (API → Generate Token). Your account needs API export rights for this; no admin role is required.
2. In StatsPlease, choose Import from REDCap, enter your API URL and API Token, and press Connect. The token is sent to REDCap over HTTPS, held in memory only while the import runs, and never stored.
3. A field picker appears showing every field with its detected type. Analyzable fields are pre-selected; uncheck any you do not need. Field types that cannot be analyzed statistically (notes, file uploads, descriptive text) are shown but cannot be selected.
4. Press Run Analysis. Despite the name, this step imports and loads the selected fields; it does not run a statistical test by itself.
5. Open the Analysis tab, set your Outcome and Group variables, and press the preset that matches your design (for a two-group comparison, Group Comparison). Pressing the preset runs the analysis.

The field-type mapping happens automatically on import, read from each field's actual REDCap validation setting: radio, dropdown, checkbox, and yes/no fields become categorical; text fields with number validation become continuous; text fields with date validation become datetime; and notes, file, and descriptive fields are excluded. Checkbox fields are expanded into their per-choice columns for you. One deliberate guard: an export with repeating instruments or multiple longitudinal events is rejected with an explanation rather than silently flattened, because more than one row per patient would inflate the sample size and invalidate every test downstream.

Export raw data, not labels

Open the Data Export Tool in REDCap and choose the CSV option in raw data format. This keeps the underlying numeric codes (0, 1, 2) that statistical software needs. Keep column headers as field names. If your project uses multiple events or visits, export with event names included so you can separate time points later.

Before the file leaves REDCap, use the built-in de-identification options to strip any identifying fields. A de-identified raw CSV is the only format you need for statistical analysis.

Matching REDCap field types to statistical variable types

The REDCap field type determines what kind of statistical variable you have, which determines how you summarise it and which test applies. This translation step is where most trainees get stuck, and it is more specific than it first looks: not every text field becomes a continuous variable.

The unvalidated text row is the one that catches people out: a free-text field with no validation rule attached does not automatically behave like a number, even if every value entered happens to look numeric. StatsPlease's REDCap import reads the field's actual validation setting to decide, rather than guessing from the values themselves.

Which test for which comparison

Two decisions drive test selection: the type of your outcome variable, and whether continuous data are normally distributed. Normality is not an assumption you state; it is a question you answer with a test.

For categorical data, the choice between chi-square and Fisher's exact follows expected cell counts: use Fisher's exact when any expected cell count falls below 5.² StatsPlease checks this automatically on every table.

Testing normality in small clinical samples

Clinical REDCap projects often have fewer than 50 patients per group. At this size you cannot assume a normal distribution; you have to test for it. Run a Shapiro-Wilk test on every continuous outcome before choosing between a parametric and non-parametric test. When sample size is very small, under 15 per group, the safer default is non-parametric regardless: Shapiro-Wilk has limited power to detect non-normality with few observations.

Missing data in REDCap projects

REDCap projects almost always have missing values. Before running any test, look at the pattern of missingness in your exported data. The distinction that matters statistically is between data Missing Completely At Random (MCAR) and Missing At Random (MAR): MCAR means a value's absence has nothing to do with any other variable, a patient simply missed a visit; MAR means missingness is related to another recorded variable (sicker patients missing more lab draws) but not to the missing value itself. Most clinical REDCap data is MAR rather than MCAR. For publication, report the number of missing values per variable and state how you handled them.

A real result: urine copper and hepatomegaly in a real cohort

Consider a REDCap project recording urine copper (a continuous, number-validated text field) and hepatomegaly (a Yes/No field) in patients with primary biliary cirrhosis. The question is whether urine copper differs between patients with and without hepatomegaly.

Example data: Mayo Clinic primary biliary cirrhosis cohort (Fleming and Harrington, 1991; field definitions per Therneau and Grambsch, 2000); see references. 310 of 418 patients had both fields recorded. Computed with scipy, not generated.

This is also the step where a chat window fails you quietly. Paste the same two columns into ChatGPT and ask it to compare the groups, and a language model hands back a plausible-looking U and P value it generated rather than arithmetic it performed on your 310 patients. The result above is computed with scipy, deterministically, so re-running it in R or SPSS returns the identical numbers.

Frequently asked questions

Should I export REDCap data in raw or labels format for statistical analysis?

Raw format. Labels export sends text (Yes/No, Male/Female) instead of the numeric codes (1/0, 1/2) statistical software needs, which forces manual recoding of every variable before a single test can run.

Does a REDCap text field always map to a continuous statistical variable?

No. Only a text field with number, integer, or float validation maps to continuous. A plain text field with no validation is treated as categorical, and notes, file, and descriptive fields are excluded from analysis entirely.

Can I analyze REDCap data without exporting it?

Yes. A tool with a REDCap API connection can pull records and field types directly, with no CSV in between. In StatsPlease: enter your REDCap API URL and token, press Connect, choose fields in the picker, and press Run Analysis to import them. The analysis itself still runs through the same preset selection as a CSV upload.

Why does my checkbox field become multiple columns?

Because a participant can tick several choices at once, REDCap exports each checkbox choice as its own column, named field___1, field___2, and so on. Each column is a separate binary variable (checked or unchecked), and that is how it should be analyzed. StatsPlease's REDCap import performs this expansion automatically and pins each choice column as categorical.

Is it safe to give a tool my REDCap API token?

Treat the token like a password: it grants whatever rights your account holds in that one project. Check how a tool handles it before connecting. StatsPlease sends the token to REDCap over HTTPS, holds it in memory only while the import runs, and never stores it. You can also regenerate the token in REDCap at any time, which invalidates the old one.

Do I need REDCap admin rights to use the API?

No. You need API export rights on your own account, granted through the project's User Rights page, and a project token from the API page. A REDCap administrator does have to enable the API for the project, and some institutions route token requests through administrator approval, but ordinary project members with export rights can use the API.

References

1. REDCap Consortium. Project statistics. https://projectredcap.org/. Accessed July 2026.
2. Cochran WG. Some methods for strengthening the common χ² tests. Biometrics. 1954;10(4):417-451. https://doi.org/10.2307/3001616
3. Fleming TR, Harrington DP. Counting Processes and Survival Analysis. New York: John Wiley and Sons; 1991.
4. Therneau TM, Grambsch PM. Modeling Survival Data: Extending the Cox Model. New York: Springer; 2000. https://doi.org/10.1007/978-1-4757-3294-8