Capture generates the data dictionary and codebook from the forms you built, so every export arrives with the names, types, choices and codes needed to read it. Raw and decoded files, OIDs and SDTM domains included.
Free sandbox · No credit card · 21 CFR Part 11 aligned
| Type | Choices / unit | Domain | |
|---|---|---|---|
| SYSBP · Systolic blood pressure | Number | mmHg | VS |
| AESEV · Severity | Single choice | 1 Mild · 2 Moderate · 3 Severe | AE |
| SEX · Sex at birth | Single choice | F · M | DM |
| BMI · Body mass index | Calculated | kg/m2 | VS |
| CMSTDAT · Start date | Date | ISO 8601 | CM |
What to know first
The problem
A data dictionary is the document that says what each variable in the dataset means: its name, label, type, allowed values, units and where it came from. A codebook is the same idea aimed at the analyst, usually adding the decoding of numeric codes into words. In practice the two terms overlap, and a statistician who receives an export without either has to reverse-engineer the study from column headings such as Q14_b.
The usual failure is not that nobody writes one. It is that somebody writes one at database design, the protocol is amended twice, a choice list gains a value, a unit changes from mg/dL to mmol/L, and the spreadsheet is never touched again. At analysis the dictionary describes a study that no longer exists. Inspectors and reviewers who ask for it get a document nobody trusts.
Generating the dictionary from the same objects that define the forms removes the second copy. The only source of truth is the form; the dictionary is a view of it. That is the design Capture follows, and it is why this page treats the dictionary as part of the export rather than as a separate deliverable. For the wider data management picture, see clinical data management software and the data management plan template.
How it works
You define each question once in the visual builder: its type, choices, unit and rules. When you export, the dictionary and codebook are produced from those same definitions and delivered with the data.
Format
CSV / Excel
Files
Raw + decoded
What a dictionary holds
General practice for any study dataset. In Capture these attributes are properties of the form and field you built.
| Attribute | Why the analyst needs it | Where it comes from in the build |
|---|---|---|
| Variable name and label | Reading the dataset without the CRF in hand | The question you wrote and its code |
| Type | Importing dates, numbers and text correctly | Number, date, single choice, text and the other question types |
| Choices and codes | Turning 1, 2, 3 into Mild, Moderate, Severe | The choice list, shown in the raw and decoded files |
| Unit and precision | Avoiding mixed-unit analysis | Unit and decimal places set on the question |
| Derivation | Knowing a value was computed, not entered | Calculated fields such as BMI, eGFR or QTc, shown read-only at entry |
| Form and visit | Placing the value in the protocol schedule | The form and visit the field sits on |
| OID and SDTM domain | Linking to standards and submission datasets | Carried by every eCRF template |
Which attributes appear in each exported file is confirmed by exporting a test study in the free sandbox.
Build two forms in the free sandbox, enter sample data and download the export. No credit card and no time limit; you pay only once you go live with real participants.
Staying correct
Forms in Capture move through a draft to approved lifecycle, and approved forms are locked for live use. That matters for the dictionary: a variable cannot quietly change meaning in the middle of a study, because changing it is an amendment, not an edit. When an amendment is made, the next export reflects it, and the amendment history sits alongside the data in the same audit trail. See CRF builder for clinical trials.
Plan the dictionary review as a fixed step before database lock. A practical order is: export the codebook from the test data, read it against the protocol and the statistical analysis plan, resolve every variable the analyst could misread, then freeze it. The database lock and unlock workflow page covers what follows. Teams exporting for statistical software will also find exporting EDC data to R, SAS and SPSS useful.
If you are migrating from a spreadsheet or another system, write down the mapping from your old column names to the new variable names and keep it with the archived export. Capture does not claim an import tool on this page, so treat the mapping as documentation for the analysis, not as an automated step.
Test data entered in sandbox
Codebook exported
Raw and decoded files
Read against protocol and SAP
Names, units, choices
Fix ambiguous labels
Amend draft forms only
Approve and go live
Approved forms are locked
Review checklist
Useful for Capture and for any other system you are evaluating.
Count columns in the data file and rows in the dictionary; they should match.
Look for a decoded file or a value-label table, not only numeric codes.
No numeric variable should leave its unit to be guessed; check labs and vitals first.
Analysts should be able to tell entered from calculated values.
Amend a draft form and re-export; the dictionary should change with it.
Filter by site and date range and confirm the dictionary comes with the filtered file.
Next steps
For submission-style datasets, export SAS XPT files with Define-XML from the same build.
Read more QualityRange and value rules documented in the build make the dictionary self-explanatory.
Read more RoleThe day-to-day view of queries, listings and exports.
Read moreYes. The data dictionary or codebook is produced automatically with the CSV and Excel exports, built from the forms in your study.
The terms overlap. A data dictionary describes variables (name, type, allowed values, units). A codebook usually adds the decoding of numeric codes into labels for the analyst. Capture delivers raw and decoded files so both uses are covered.
CSV and Excel in wide format with one row per submission, with date-range and by-site filtering. SDTM datasets are available as SAS XPT files with Define-XML.
Every eCRF template carries an OID and an SDTM domain, for example DM, VS, EG, PE, LB, MH, AE and CM.
The dictionary is generated from the forms, so it follows the approved build. Amendments are deliberate: forms move from draft to approved and approved forms are locked for live use.
This page does not claim an import tool. Build the forms in the visual builder, or let the AI draft them from a file for your review, and keep your old mapping as documentation.
Yes. Capture is suitable for Phase 1, 2 and 3 studies, and the export works the same way at any phase.
Open the free sandbox, build a form, enter sample data and export. It has every feature, no credit card and no time limit.
Keep exploring
CDISC SDTM export software
SAS XPT datasets with Define-XML.
Export EDC data to R, SAS and SPSS
Getting data into statistical software.
Clinical data management software
The data management workflow.
Data management plan template
Where to document the dictionary review.
CRF builder for clinical trials
How the forms behind the dictionary are built.
Edit checks software
Validation rules in the build.
Free sandbox, every feature, no credit card. Export it and read it as your statistician would.