Capture exports your study as SDTM datasets in SAS XPT format together with a Define-XML file. Every eCRF carries its SDTM domain and every field its SDTM variable, so the export comes out of the study build instead of a separate mapping project.
Free sandbox · No credit card · 21 CFR Part 11 aligned
| SDTM domain | SDTM class | |
|---|---|---|
| Demographics eCRF | DM | Special-purpose |
| Vital signs eCRF | VS | Findings |
| ECG eCRF | EG | Findings |
| Laboratory eCRF | LB | Findings |
| Medical history eCRF | MH | Events |
| Adverse events eCRF | AE | Events |
| Concomitant medications eCRF | CM | Interventions |
What you need to know
The standard
SDTM, the Study Data Tabulation Model from CDISC, is a standard way of organising the raw clinical data a study collects into a fixed set of datasets called domains. Each domain has a two-letter code, a defined set of variables with fixed names and meanings, and a rule for what one record represents. DM holds one record per subject. AE holds one record per adverse event. VS holds one record per vital sign measurement.
A normal EDC export is built around the form: one row per submission, one column per question. That layout, usually called wide, is excellent for data review and quick analysis. SDTM is built around the observation. A vital signs form with systolic pressure, diastolic pressure, pulse and temperature becomes four records for each visit in the VS domain, each with a test code, a test name, the result as collected, a standardised result, units and a visit. This is the "tall" layout programmers know from SAS and R.
Moving from wide to tall is mechanical once you know the mapping, but writing and checking that mapping for every form is where SDTM projects lose weeks. The mapping is also easier to get right when the person who designed the form makes it. That is why Capture stores the domain on the form and the variable on the field: the information is captured once, at build time, and reused by the export.
| VSTESTCD | VSORRES | VSORRESU | |
|---|---|---|---|
| Subject 001-0042, Week 4 | SYSBP | 128 | mmHg |
| Subject 001-0042, Week 4 | DIABP | 82 | mmHg |
| Subject 001-0042, Week 4 | PULSE | 68 | beats/min |
| Subject 001-0042, Week 4 | TEMP | 36.7 | C |
How it works in Capture
You design forms in the visual builder, or start from a template, and the SDTM domain comes with the template. When the study is ready, the SDTM export produces the datasets and the Define-XML that describes them. Nothing has to be re-keyed or re-mapped in a spreadsheet.
Domains
7
Format
SAS XPT
Metadata
Define-XML
Reading an SDTM dataset
These are general SDTM conventions. In a findings domain such as VS the two-letter domain code replaces the double dash.
| Variable | Meaning | Example |
|---|---|---|
| STUDYID, DOMAIN | Study identifier and the domain code | DEMO-01, VS |
| USUBJID | Unique subject identifier across the whole submission | DEMO-01-001-0042 |
| --SEQ | Sequence number that makes each record unique within a subject | VSSEQ = 3 |
| --TESTCD, --TEST | Short code and long name of the measurement | SYSBP, Systolic Blood Pressure |
| --ORRES, --ORRESU | Result as originally collected, with its original unit | 128, mmHg |
| --STRESC, --STRESN, --STRESU | Standardised result as character and numeric, with the standard unit | 128, 128, mmHg |
| VISITNUM, VISIT | Planned visit number and name | 4, Week 4 |
| --DTC | Date and time in ISO 8601, partial dates allowed | 2026-09-30T09:15 |
Always check the SDTM Implementation Guide version your sponsor or regulator specifies, since variables and controlled terminology change between versions.
Start from the vital signs or adverse events template in the free sandbox, enter sample data and look at the export. No credit card, no time limit.
Why teams ask for it
In the United States, FDA requires study data in CDISC standards for studies that started after 17 December 2016 in new drug, biologic and generic applications, and after 17 December 2017 for commercial INDs. SDTM covers the tabulated data, ADaM the analysis datasets, and Define-XML the metadata, as set out in FDA's Study Data Technical Conformance Guide. Other regulators, including Japan's PMDA and China's NMPA, have their own data standards requirements, so read the current guidance for your target agency.
If you run an academic or investigator-led study with no marketing application in view, SDTM may not be required of you at all. It still has value: standardised domains make it easy to combine studies, share data with collaborators and bring in a programmer who has never seen your protocol. For sponsors preparing for a pivotal Phase 3 submission, the point is timing. Deciding the domain and variable for each field while forms are built costs minutes. Reverse-engineering them from a locked database costs weeks of programming and review.
SDTM datasets are the tabulation layer. ADaM analysis datasets, with derived endpoints and analysis flags, are built from SDTM by your statistical programmers according to the statistical analysis plan, in SAS or R, and are outside what this export produces. The page for biostatisticians and SAS programmers covers the rest of what they get from the platform.
Workflow
Start from the library forms, which already carry their SDTM domain, or draft forms with the AI study builder and review them. Nothing is saved from AI drafting without human review.
When forms move from draft to approved, have your data manager or statistician confirm the SDTM domain and variable on each field. Approved forms are locked for live use, so the mapping stays stable.
In the free sandbox, enter sample subjects and export. Open the XPT files in your own SAS or R environment, as shown on the export to R, SAS, SPSS and Stata page.
Run your SDTM validator against the datasets and Define-XML, as you would for any submission package, and agree any sponsor-specific conventions in the data management plan.
Use the date-range filter for interim snapshots, and freeze or lock data before the final export. Every export is recorded in the export log.
Three ways to get SDTM
A neutral comparison of approaches, not of any one vendor.
| Spreadsheet export, mapped at the end | Separate mapping or conversion service | SDTM export built into the EDC | |
|---|---|---|---|
| Who maps | Your programmers, after database lock | A service team, from your exports and specs | Whoever builds the form, as part of the build |
| When mapping happens | Late, under timeline pressure | After data are collected | While forms are designed |
| Effect of a form amendment | Re-do mapping by hand | Re-brief and re-run the service | Mapping lives on the form and moves with it |
| Handover to statisticians | Several files, several conventions | XPT files and a define file from outside the EDC | XPT files and Define-XML from the same system as the data |
Beyond SDTM
You will not stop using the wide export when you adopt SDTM. Data managers reviewing a visit want to see the whole form on one row, and a medical monitor wants decoded labels rather than controlled-terminology codes. Capture provides CSV and Excel exports in wide format, with an automatic data dictionary and both raw and decoded files, filterable by date range and by site. See clinical data management for review, freeze and lock before export.
Adverse events deserve a note of their own. AE is one of the domains that regulators read first, and the quality of the data behind it, minimum dataset, seriousness criteria, causality and outcome, depends on how the form was built. The adverse event reporting software page shows how Capture enforces that at entry, which is what makes the AE domain clean when it is exported.
Yes. Capture exports SDTM datasets as SAS XPT files together with a Define-XML file. Each eCRF carries its SDTM domain and each field its SDTM variable, so the export is produced from the study build.
The template library forms carry their domains: DM for demographics, VS for vital signs, EG for ECG, PE for physical exam, LB for laboratory, MH for medical history, AE for adverse events and CM for concomitant medications.
Define-XML is the CDISC metadata file that describes every dataset, variable, code list and origin in a submission package. Regulators and reviewers use it to understand the datasets, so it is exported alongside the SAS XPT files.
No. ADaM analysis datasets contain derived endpoints and analysis flags written to your statistical analysis plan, and your statistical programmers build them from SDTM. Capture provides the SDTM tabulation datasets and the other data exports statisticians need.
Yes. CSV and Excel exports in wide format come with an automatic data dictionary, raw and decoded files, and filters by date range and site. SDTM and the wide exports are different shapes of the same data.
It is required by FDA for standardized study data in marketing applications for studies that started after December 2016, and for commercial INDs from December 2017. Investigator-led and academic studies with no marketing application are often not required to use it, though many do. Check the guidance for your regulator.
Yes. The free sandbox includes every feature with no time limit and no credit card, so you can build forms, enter sample subjects and inspect the exports. You pay only once you go live with real participants.
Keep exploring
EDC for biostatisticians and SAS programmers
What statisticians get from the platform.
Export EDC data to R, SAS, SPSS and Stata
Read the CSV and XPT files in your tool.
Clinical data management software
Queries, freeze, lock and export.
CRF builder for clinical trials
Where domains and variables are set.
Adverse event eCRF template
The AE form behind the AE domain.
Build the forms, enter sample data and export SDTM datasets with Define-XML in the free sandbox. No credit card, no time limit.