Tips & Best Practices

Guiding principles

If you are collecting data using REDCap at SBM, you have a role in data stewardship — using generally accepted practices to take care of your organization's data. All research data collected belong to the University; PIs are considered the principal data stewards for their research data. For more, see the SBU policy on Research Data Ownership, Retention, and Access.

Data stewards have a responsibility to:

1. Safeguard data security — keep project user rights updated; sign DUAs before sharing with external parties.
2. Respect participant privacy — handle data responsibly, in alignment with patient consent, stated wishes, and the HIPAA Privacy Rule.
3. Maintain data quality — use REDCap to ensure your data are accurate (correct and reflecting reality), timely (current and up to date), complete (empty fields accounted for; missing data documented and remediated; irrelevant fields hidden by branching logic or action tags), consistent (“master data” kept in one location; the same data collected only once), valid (validation enforced in text fields, or multiple-choice used), and unique (each record represents one defined instance — a participant, an encounter).

Building your project

Date fields

• Use a consistent date format. If you use date_mdy (e.g., 12-25-2018), use it in all date fields unless you have a specific reason not to.
• Label each date field descriptively — “Scale Assessment Date” or “Date of interview (XYZ Scale)” rather than “Today's Date” — so there's no confusion about whether the date reflects the interview, the self-report, or merely when the form was accessed.
• Auto-fill dates with action tags such as @NOW or @TODAY plus @READONLY. In survey mode the submission time is already recorded in redcap_survey_completion_time, so a standalone “survey completed” field usually isn't needed.

Age fields

• Age should be an integer-only field — otherwise mark it as an identifier (PHI). Decimals in an age field are considered a surrogate for date of birth, a HIPAA identifier. If ages stay below 90, validating as integer keeps the field exempt.
• Computing age in a Calc field? Wrap datediff in rounddown — use rounddown(datediff([date_of_birth],[procedure_date],'y'), 0) — and use static date fields as parameters, never 'today' (its value only updates when someone opens the form).
• Name the timepoint — “Age at Baseline Interview” or “Age at Scan 1,” not just “Patient Age.”

Checkbox fields (“check all that apply”)

An empty checkbox can mean a skipped question or “none applied.” To tell them apart: add a “None of these” option coded '0', make it mutually exclusive with @NONEOFTHEABOVE='0', and mark the field Required. Then a blank response almost certainly means missing data.

Sequence of project development

1. Start with data elements (fields, instruments) and project structure (events, arms, repeatable instruments).
2. Next set up user rights & roles, Data Access Groups, and optional workflow features: survey settings, calendar, custom record labels, randomization, Automated Survey Invitations, alerts.
3. Finally add branching logic, required fields, identifier flags (18 HIPAA elements), calc fields, data quality rules, and reports/dashboards — then test thoroughly with test records entered as you would in Production.

Surveys

Before deploying a survey, consider: Are the surveys anonymous? Should responses from different surveys be linked? Do you have contacts and emails in advance? How important is uniqueness of responses? How many respondent groups are there?

Choosing a distribution model

Multiple public surveys in one project

REDCap allows only one true Public Survey per project (always the first instrument — this is expected behavior, not a configuration error). The workaround is a “dummy” public survey: create a short placeholder survey with intro text and no data collection, make it the first instrument, enable auto-continue, assign it to the first event of each arm, and place the real surveys after it — one arm per respondent group. Participants click one public link and are routed seamlessly to the correct survey.

Priming, invitations, and deliverability

• Start identifiable survey projects with participant data. Put names/emails in a “Survey Management” first instrument and designate the email field for communications — priming reduces participant fatigue and improves response rates and data quality.
• Automated Survey Invitations apply only to records created after the ASI exists — they are not retroactive.
• Look and feel: select the built-in SBM themes and upload the official SBM logo.
• Avoid the spam folder: skip attachments; brand your emails; avoid excess HTML, spam-trigger words (“free,” “offer,” “incredible”), ALL-CAPS subject lines, bright red/green fonts, and phrases like “this isn't spam.” Be specific — “assessment,” “study,” or “feedback” beats “survey.”

Before collecting data

• Test. Enter at least five test cases and walk the project through its entire lifecycle — distribution, data entry, user changes, quality monitoring, reporting, analysis. It is always easier to change structure before meaningful data exists.
• Move to Production. Production mode protects your data from breaking changes to instruments that already hold data — see the Move to Production guide.
• Requirements. Mark all 18 HIPAA PHI elements as “identifiers” and restrict Data Export rights accordingly; obtain institutional approvals and add your IRB number before real data collection. Under the software agreement, REDCap can capture non-SBU external data only in IRB-classified multi-site projects where SBU is the data coordinating center (DCC).

Making production changes

Changes to a live project apply retroactively to existing records. Two rules of thumb: retire it, don't delete it — and create a new one, don't reword it.

Multiple-choice options

• Never change option codes once data collection has begun — reorder options instead; raw values must stay bound to their original labels.
• Retire obsolete options with @HIDECHOICE (e.g., @HIDECHOICE='10,17') rather than deleting them — deletion strips the label and effectively corrupts past data points; @HIDECHOICE hides the option on future forms while preserving it on records where it was selected.

Field labels and wording

If there is any chance earlier respondents would have answered differently under new wording, retire the old field (@READONLY / @HIDDEN) and add a new one — mismatched labels and responses reduce confidence in your conclusions. Merge the two fields later, during analysis.

Deleting and adding fields

• Retiring (recommended pattern): add @READONLY plus branching logic [event_name_arm_1][old_field] <> '' so the field shows only on records that already hold a value.
• Adding: new fields appear as “missing data” on old records. Either add a Field Note documenting when it was added (“Added by HP 11/24/2023”), or use date-based branching such as datediff([form_date], '2022-01-01', 'd', true) > 0 so it displays only on records created after its introduction.
• Document every addition and retirement.

Changing field types

• Text → multiple choice: create the MC field as a new field and retire the text field; backfill via reports or the data import tool, keeping the old field for auditing with a note like “replaced with multiple choice field 5/2024 — do not use.”
• Radio/dropdown → checkbox: update all dependent branching logic — checkbox syntax differs: [request_type(20)] = '1' vs [request_type] = 20.
• Checkbox → radio: only the first selection survives — convert only after weighing that data deletion.

Moving or copying data between fields, events, or arms

REDCap is a system of record: keep source data where it was originally collected and adapt your analysis to it. “Migrating” data leaves the logging record behind, muddies the audit trail, and hamstrings investigations. Collect new data in the new location and merge during analysis instead.

After data collection

Move your project to Analysis/Cleanup status (Other Functionality tab) when data collection is done.

Other tips & tricks

• Design for both entry and analysis — talk to your coordinators and statistician; when the two conflict, prioritize ease of data entry. Request a project consultation with your REDCap administrator before starting collection.
• Re-display values without duplicating fields — use piping ([participant_id]), calc-style action tags (@CALCTEXT, @CALCDATE, @DEFAULT), or a Custom Record Label / Secondary Unique Identifier (Project Setup › Additional Customizations).
• Minimize free-response text. Prefer multiple choice; validate text fields so exports type correctly in stats packages; set min/max on number fields; break compound fields apart (“Street, City, State, Zip” instead of one “Address”).
• Field alignment: few short choices → horizontal radio; more/longer → vertical radio; more than 7 → dropdown.
• Action tags add quality-of-life features: @WORDLIMIT/@CHARLIMIT, @NONEOFTHEABOVE/@MAXCHECKED, @HIDDEN variants, @READONLY variants, @HIDEBUTTON (great for birthdates), @CALCTEXT/@CALCDATE, @PLACEHOLDER, and prefills (@NOW, @TODAY, @USERNAME, @DEFAULT, @SETVALUE).
• Descriptive fields: suffix names with _display or _descriptive so display-only fields aren't mistaken for data.
• Code choices numerically (1, Monday | 2, Tuesday — not mon/tue); keep coding consistent across fields; give missing-data codes standout values (77/88/99). Check the Medical Ontologies, NIH CDE Field Bank, and Shared Instrument Library before building standard lists from scratch.
• Organize instruments around the data-entry flow: keep instruments short, group fields by who enters them (“Physical Exam [Cl]”, “MRI Notes [Co]”), and order forms to match how data actually arrives.
• Branching logic lives in the child field. For many fields sharing complex logic, wrap it once in a calc field — if(<logic>,1,0) — and reference that.
• Calc fields: REDCap is not a statistical tool — calculate in REDCap only if you need the value during collection. Prefer [var1] + [var2] over sum(): the + operator stays blank until every component is filled, so incomplete scores can't masquerade as legitimate ones.
• Field names: short but clear; they cannot be changed after collection begins without touching every pipe, calc, and branch. Prefix with instrument initials (pe_assess_date), zero-pad numbers (qids_01_slp), and describe the item (stroke_01a_conlvl).
• Repeated measures: longitudinal mode for regular/finite repetition; repeatable instruments for irregular/unbounded; extra field copies only for minimal repeats. Don't mix schemes, and keep to a single REDCap arm unless groups truly need different event schedules — branching logic handles treatment groups with less complexity.
• Survey mode is for participants; data entry mode is for staff. Staff entries via survey mode weaken the audit trail. Use SOPs (and a completion-status banner via branching logic) to keep each interface with its audience, and consider a staff-only “mode of data entry” field — it helps when investigating missing data. Public survey links are for when emails aren't known in advance; with an email list, use the participant list (identifiers optionally off) instead.

See also

• UC Denver REDCap Best Practices (portions of this guide were adapted from it)
• REDCap FAQ & Learning Resources
• Guides from other institutions: UT Southwestern, Kaiser Permanente, UChicago, UC Davis, Wake Forest Health, CHOP