The short version
- Define-XML describes the submitted datasets: every dataset, variable, codelist, value-level rule, origin and derivation method.
- FDA expects a define.xml with each set of standardized datasets, and its technical checks look for one.
- A define generated from the same specifications the programs use is accurate by construction. A define written after the data is a second, competing description.
What is in it
Define-XML is a CDISC standard for describing tabular datasets in a machine-readable way, displayed in a browser through a stylesheet [1]. For each dataset it lists the structure, keys and purpose. For each variable it gives the label, type, length, controlled terminology, origin and, where the value is derived, the method. Value-level metadata describes variables whose meaning depends on another value, such as the result of a lab test that depends on the test code. Comments explain anything that the structure cannot.
Version 2.1 strengthened two things that reviewers care about: a more precise description of where each value came from, through the origin type and source, and a place to declare the standards and terminology versions the study uses [1].
Why the agency cares
The define is the reviewer's dictionary. When a reviewer opens a dataset and sees a variable they do not recognize, they look it up in the define. When a derived value looks odd, they read the method. FDA's Technical Conformance Guide describes the data definition file as arguably the most important part of an electronic dataset submission for review, and the Data Standards Catalog lists the Define-XML versions that are supported [2, 3]. FDA's technical checks for study data also expect a define.xml with the tabulation and analysis datasets.
The four origins that matter most
| Origin | Meaning | What the reviewer needs |
|---|---|---|
| Collected | Captured on the CRF or in an external data transfer | The CRF page or the source, through the annotated CRF |
| Derived | Calculated from other data | The method, in words or pseudocode a reviewer can follow |
| Assigned | Set by the sponsor, for example by a coding dictionary or a decision | Who assigned it and on what basis |
| Predecessor | Copied from another dataset, typically in ADaM from SDTM | The source dataset and variable |
The SDTMIG gives the conventions behind many of these, such as which variables are expected or permissible in each domain [4].
The common failure
The define is generated at the end, from the data, by someone who did not write the specifications. It describes what the data contain, not what they were meant to contain, so it cannot reveal a mismatch between the two. Methods are copied from programs and unreadable, or missing. Codelists list every value in the terminology rather than the values used.
The better pattern is one specification, written first, from which both the programs and the define are produced. Differences between the define and the data then become checks that fail early: a codelist value the data do not use, a variable in the data the define does not describe, a derived variable with no method.
A synthetic example
When the fictional ZEPHYR-101 team generates a draft define from its specifications at the first SDTM transfer, the comparison with the data finds 23 variables with no method, 4 codelists whose values do not match the data and one dataset with keys that are not unique. All 28 are closed before the dry run. None of them would have broken a program.
Do this today
- Generate a draft define.xml from your current specifications and compare it with the latest data transfer.
- List every derived variable without a method a reviewer could follow, and assign each one.
- Check that the standards and terminology versions declared in the define match those used to build the data.
Check yourself
One question
Show the answer
Answer 2. A derived value is only reviewable if the define says how it was derived, either as a method or with a clear comment. A missing method is not normally a rejection, but it turns into a review question that the define should have answered.
Apply it
Turn it into a plan
The brief says what to check. The Navigator and the Handbook turn it into dated, owned actions for your milestone, in your browser, with no study data.
Sources
References
- CDISC. Define-XML version 2.1. www.cdisc.org ↗
- U.S. Food and Drug Administration. Study Data Technical Conformance Guide: Technical Specifications Document. www.fda.gov ↗
- U.S. Food and Drug Administration. Data Standards Catalog. www.fda.gov ↗
- CDISC. Study Data Tabulation Model Implementation Guide (SDTMIG) version 3.4. www.cdisc.org ↗
Standards and guidance change. Confirm the version in force for your study, sponsor and region before relying on any reference. Examples are synthetic and illustrative. This brief is generalized professional guidance, not regulatory advice.
Next brief · Tuesday 10:00 ET · Lock Room