How to Use the REDCap Data Dictionary Prompt to Convert a Paper Case Report Form

Most REDCap projects start as a paper or Word case report form. Someone then has to rebuild every question in the Online Designer, one field at a time, and it is easy to end up with inconsistent variable names, missing validation, and skip logic that nobody tested. REDCap has a faster route: the data dictionary, a CSV file that defines every field and can be uploaded in one step. The REDCap Data Dictionary CSV from a Paper Case Report Form (Field Types, Validation, Branching Logic) prompt writes that CSV from your CRF text, along with a build checklist.

Why the data dictionary is worth learning

The data dictionary is the whole instrument in a spreadsheet. Each row is a field, and the columns cover the variable name, form, section header, field type, label, choices, validation, identifier flag, branching logic, required flag, and field annotation for action tags. Because it is a single file, it is easy to review, version, and compare. A study coordinator can read it in one pass and spot a wrong code or a missing identifier flag faster than by clicking through forms.

The format is strict, though. The header row has a fixed order, cells with commas must be quoted, choices follow a code, label | code, label pattern, and branching logic uses REDCap's own syntax. The prompt handles all of that.

What the prompt produces

1. A variable naming plan using lowercase letters, numbers, and underscores, starting with a letter, with record_id first and a short prefix per instrument.
2. The data dictionary CSV with the standard REDCap header row in order and every field from your CRF.
3. Field type notes explaining each choice: text with validation such as date_ymd, integer, or number, versus notes; radio versus dropdown versus checkbox; yesno; calc; and descriptive fields.
4. Branching logic translated from every skip instruction, including the checkbox form, written like [field(code)] = '1'.
5. A build checklist covering the upload on the Data Dictionary page, the change report, fake test records, and settings that live outside the dictionary, such as events and repeating instruments.
6. Questions for the investigator where the CRF is ambiguous.

How to fill the inputs

Paste CrfText section by section, with the question wording, answer options, and skip instructions exactly as written. The prompt only uses questions and options from the CRF, so anything you leave out will not appear. Instruments names the forms the study wants. StudyDesign says whether the project is longitudinal, uses repeating instruments, or collects survey responses, because those settings are configured outside the dictionary.

Identifiers lists every field your data plan treats as identifying, such as names, dates of birth, record numbers, or initials. Each one gets flagged so de-identified exports can drop it. CodingConventions sets the codes the team already uses, for example yes as 1, no as 0, and unknown as 99, and the date format.

Walking through the example

The sample CRF has an eligibility section and a baseline section with weight, height, smoking status, a symptom checklist, and a dyspnoea grade. The output makes several choices worth copying:

• Smoking status is a radio field, not yesno, because the CRF includes Unknown, which the team codes as 99.
• The symptom checklist is a checkbox field. Each option becomes its own 0 or 1 column in exports, and an action tag stops coordinators from ticking None together with a symptom.
• The dyspnoea grade only shows when breathlessness is ticked, using checkbox branching syntax.
• The consent date is validated as year-month-day with a maximum of today, so future dates are blocked.
• Consent date and initials are flagged as identifiers, and the checklist includes a test export to confirm they drop out.
• No BMI field is added, because it is not on the CRF. The prompt lists it as a question instead.

Mistakes to avoid

• Adding fields the CRF does not contain. It changes the study instrument without anyone deciding to. The prompt asks instead.
• Inconsistent codes across forms. If yes is 1 on one form and 2 on another, analysis becomes guesswork.
• Skipping the change report. REDCap shows what the upload will add or change before you commit. Read it.
• Testing with real data. Enter a few fake records that exercise each branch, then delete or keep them in development only.
• Forgetting identifier flags. An unflagged identifier stays in a de-identified export.

Who it is for

This prompt fits clinical research coordinators, data managers, and graduate researchers building a REDCap project from an existing form. It does not replace your institution's REDCap support or the study's data management plan, but it gets you to a reviewable dictionary file quickly.

Related PromptDig links

• Prompt: REDCap Data Dictionary CSV from a Paper Case Report Form (Field Types, Validation, Branching Logic)
• More research prompts: Browse more prompts
• Have a research data prompt to contribute? Share a prompt