The short version
- CDISC publishes Controlled Terminology quarterly. Terms are added, definitions refined and occasionally values deprecated.
- A study that does not pin its terminology version picks up whatever was current when each dataset was built.
- The signal is small: a codelist value that looks different in two datasets. The cost arrives when studies are pooled or a reviewer compares data with the define.xml.
The failure
CDISC Controlled Terminology is the set of codelists behind SDTM and ADaM values such as units, test codes, routes and dispositions. It is published on a quarterly release cycle [1]. That cadence is good for the standard and a hazard for long studies. A study that runs for three years without deciding which version it uses will be mapped, over time, against many.
Nothing breaks. Programs run, tables produce numbers, validation rules may not fire, because each value was valid in some version. The problem is that the values no longer agree with each other or with what the define.xml declares.
Where it surfaces
In the define.xml. Define-XML lets a study declare the standards and terminology versions it uses, and each codelist in the define should match the values in the data [2]. If the define says one version and the data contain values from another, a reviewer sees a contradiction in the very document meant to explain the data.
In pooled analyses. An integrated summary of safety pools several studies. If one study codes a value one way and another uses a newer term for the same idea, the pooled table splits a category in two, or a program silently drops records that do not match its format.
In a regulatory check. FDA's Data Standards Catalog lists the standards and terminologies it supports and requires [3], and the Technical Conformance Guide asks sponsors to describe the standards and versions they use, starting with the study data standardization plan [4]. A version that was never chosen cannot be described.
The early signal
Ask one question at study start and at every database transfer: which terminology version is this study mapped to, and where is that written? If the answer is "the latest", the study is drifting. Other signals include a codelist in the define.xml with values the data do not use, or data values the codelist does not contain, and validation reports that change between transfers although the data did not.
The fix
- Pin a version in the study's data standards plan and in the specifications. Record it in TS and in define.xml.
- Change it deliberately. Moving to a newer version is a change with an impact analysis: which codelists and values differ, which datasets and outputs they touch, and who signs it off.
- For pooled data, inventory differences between the versions the studies used. Most changes will not touch the values in use. For those that do, define a mapping, apply it in the integrated datasets and document it in the reviewer's guide.
- Check at every transfer that data values, define codelists and the declared version agree.
A synthetic example
The fictional ZEPHYR program pools three studies for an integrated safety summary. An inventory of the three terminology versions used finds 214 codelist changes between them, but only 6 touch values that appear in the data, and only 2 change a grouping used in the safety tables. The team maps those 2, documents the mapping and moves on in a day, instead of re-mapping three studies.
Do this today
- Find where your study's terminology version is written. If it is nowhere, add it to the specifications this week.
- Compare the version declared in define.xml with the version used to build the datasets.
- For any planned pooling, list the terminology version each study used.
Check yourself
One question
Show the answer
Answer 2. Most codelist changes between versions do not touch the values a given study uses. An inventory of real differences shows which ones change counts or groupings, so the team can decide on a mapping for those and document it, instead of re-mapping everything or hoping it does not matter.
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. CDISC Controlled Terminology. Published quarterly. www.cdisc.org ↗
- CDISC. Define-XML version 2.1. www.cdisc.org ↗
- U.S. Food and Drug Administration. Data Standards Catalog. www.fda.gov ↗
- U.S. Food and Drug Administration. Study Data Technical Conformance Guide: Technical Specifications Document. www.fda.gov ↗
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 · Saturday 10:00 ET · Weekend Deep Read