CDISC Controlled Terminology Explained

Introduction

Clinical-trial data often begin as free text. Investigators, sites, laboratories, and other systems may describe the same concept in slightly different ways. One site may record a sex value as Male, another as M, and another as MALE. A laboratory system may use a local code that has no obvious relationship to the terminology expected in a standardized submission.

CDISC Controlled Terminology provides standardized terms and codes that can be used consistently across clinical-trial datasets. Instead of allowing every study, site, or programmer to invent its own vocabulary, controlled terminology establishes an agreed set of values for defined concepts.

This matters because standardization is not merely cosmetic. Controlled values affect data integration, validation, traceability, metadata, reviewer interpretation, and the ability to compare information across studies.

What Is CDISC Controlled Terminology?

CDISC Controlled Terminology is a collection of standardized terminology used with CDISC models and standards. The terminology organizes concepts into codelists, with individual permissible or expected terms represented by standardized values and associated metadata.

A codelist can be thought of as a vocabulary for one defined concept. For example, a variable representing a yes/no response should not require every programmer to decide independently whether the values should be Y/N, YES/NO, or 1/0. The applicable controlled terminology establishes the standardized representation.

Why Controlled Terminology Matters

Without controlled terminology, two datasets can describe the same clinical reality using different values. That creates unnecessary work for programmers and reviewers and makes automated validation harder.

Controlled Terminology Is Not the Same as a Data Model

A common beginner mistake is to treat CDISC Controlled Terminology as if it defines the entire structure of an SDTM or ADaM dataset. It does not.

SDTM defines domains, variables, structures, and rules for representing collected clinical-trial data. ADaM defines analysis-data structures and principles. Controlled Terminology supplies standardized values for concepts where terminology is specified.

Codelists: The Core Building Block

A codelist groups related terms. The codelist provides the vocabulary, while each term represents one standardized concept within that vocabulary.

Consider a simplified illustrative codelist for a binary question:

The example is intentionally simplified. In an actual submission, programmers should use the applicable official CDISC terminology package rather than inventing values based on examples from a tutorial.

Submission Value Versus Preferred Term

Controlled terminology metadata commonly distinguishes the value intended for submission from the human-readable name or preferred term. These are related but are not interchangeable concepts.

For example, a controlled term may have a short standardized submission representation while its preferred term is a more descriptive phrase. The dataset generally carries the value required by the applicable standard, while metadata allows users to understand what that value means.

Extensible Versus Non-Extensible Terminology

One of the most important concepts for programmers is extensibility. Not every codelist has the same rules for adding sponsor-defined terms.

An extensible codelist can permit additional values when the standard terminology does not contain an appropriate concept, subject to the applicable CDISC implementation and submission requirements.

A non-extensible codelist is closed for such additions. If a required concept is missing, the programmer cannot simply invent a new value and assume it is acceptable.

Why Extensibility Matters

Clinical trials frequently contain concepts that are study-specific. A controlled vocabulary may therefore need to support sponsor additions in some contexts while remaining tightly controlled in others.

The practical programming question is:

CDISC Controlled Terminology Packages

Controlled terminology is maintained and distributed in terminology packages. A study should identify the terminology version used for its submission rather than allowing programmers to pull values from arbitrary spreadsheets or old projects.

Terminology can change over time. New terms can be added, definitions can be revised, and package releases can supersede earlier releases. Consequently, version control is part of terminology control.

Where the Terminology Comes From

CDISC Controlled Terminology is closely associated with CDISC standards and terminology governance, with terminology content distributed through CDISC terminology resources and the National Cancer Institute's Enterprise Vocabulary Services infrastructure.

For production work, use the official terminology package applicable to the study rather than copying values from a secondary website, an old program, or another sponsor's submission.

How Controlled Terminology Appears in SDTM

SDTM variables can use controlled terminology for many different clinical concepts. Examples include categories such as sex, race, yes/no indicators, relationship terms, routes, units, and other domain-specific concepts, depending on the applicable SDTM implementation guide and terminology.

Consider a simplified source-to-SDTM mapping:

Source value                 Standardized value
------------------------------------------------
"Male"                       "M"
"MALE"                       "M"
"m"                          "M"
"Female"                     "F"
"FEMALE"                     "F"
"f"                          "F"

The important point is not the specific example values. The important point is that source normalization occurs before or during standardized-domain creation, and the final value must conform to the applicable controlled terminology.

Controlled Terminology and SUPPQUAL

Supplemental Qualifier datasets can contain sponsor-defined variables and values. This does not mean every value in a SUPPQUAL record is automatically exempt from terminology requirements. If a variable has a defined controlled terminology, the applicable terminology still needs to be considered.

Likewise, the fact that a source value is free text does not automatically justify placing arbitrary free text into a standardized variable. The programmer must understand the variable's intended semantics.

Controlled Terminology and ADaM

ADaM datasets also use standardized values where the applicable ADaM implementation and study metadata call for them. Analysis variables may contain response categories, treatment-related categories, population flags, parameter codes, and other controlled values.

However, an ADaM variable should not be assigned an SDTM codelist merely because the text values look similar. The terminology must be appropriate for the variable's actual meaning and standard context.

Controlled Terminology and Define-XML

Controlled terminology is also a metadata issue. A reviewer should be able to understand what a coded variable means and, where applicable, which terminology defines its permissible values.

Define-XML can identify the codelist associated with a variable and can provide links between dataset metadata and terminology definitions. This is one reason terminology management should not be treated as an isolated programming activity.

A Practical Source-to-Submission Workflow

Example: Building a Mapping Table

A dedicated mapping table is usually safer than embedding dozens of terminology conversions directly inside a production program.

SOURCE_VALUE     STANDARD_VALUE     STATUS
------------------------------------------------
"Male"           "M"                mapped
"MALE"           "M"                mapped
"Female"         "F"                mapped
"FEMALE"         "F"                mapped
"Unknown"        "UN"               review terminology
""               ""                 missing

This type of table creates an auditable bridge between the collected value and the submitted value. The actual standardized values must come from the applicable official terminology package.

SAS Implementation Pattern

For SAS programmers, controlled terminology mappings are often implemented through a lookup table, format, or controlled mapping dataset. A lookup dataset has an important advantage: the mapping can be reviewed independently of the transformation program.

proc sql;
  create table mapped as
  select a.*,
         b.standard_value
  from source as a
  left join ct_map as b
    on upcase(strip(a.source_value))
     = upcase(strip(b.source_value));
quit;

The production implementation should additionally check for unmapped values and unexpected duplicates in the mapping table.

proc sql;
  create table unmapped as
  select *
  from mapped
  where not missing(source_value)
    and missing(standard_value);
quit;

R Implementation Pattern

The same concept can be implemented in R with a controlled mapping table.

library(dplyr)

mapped <- source %>%
  mutate(source_value_std = toupper(trimws(source_value))) %>%
  left_join(
    ct_map,
    by = c("source_value_std" = "source_value")
  )

An explicit exception report can then identify values that were not mapped:

unmapped <- mapped %>%
  filter(!is.na(source_value_std),
         is.na(standard_value)) %>%
  distinct(source_value_std)

Do Not Use Labels as a Substitute for Controlled Terminology

In SAS, a format label can make a value display as a readable word, but the existence of a format does not prove that the underlying value is a valid CDISC submission value.

For example, a programmer could create a format that displays 1 as “Male.” That does not make 1 the correct CDISC submission value for a variable whose applicable terminology requires a different representation.

Case, Spacing, and Punctuation

Controlled terminology should be treated as exact data, not as approximate text. Differences in capitalization, spaces, punctuation, or abbreviations can matter depending on the standardized value.

The Most Dangerous Mapping Error: Semantic Misclassification

The hardest terminology problems are not spelling problems. They are meaning problems.

Suppose a source system contains a value that looks similar to a standardized term. If the source definition differs, mapping it solely because the words look alike can produce a clinically incorrect dataset.

Clinical programmers should therefore distinguish between:

• Text normalization: making equivalent strings easier to match.
• Terminology mapping: assigning a standardized concept to a source concept.
• Clinical interpretation: determining what the source concept actually means.

Only the first is safely automated in every circumstance. The latter two may require clinical or data-management review.

When Should You Use a Sponsor-Defined Value?

A sponsor-defined value should be considered only after confirming that the concept is genuinely absent from the applicable terminology and that the codelist permits extension.

A useful decision sequence is:

Terminology Version Control

One of the easiest ways to create a subtle submission problem is to use different terminology releases in different parts of the project.

For example, the SDTM programmer may use one release while Define-XML was generated from another. A validation program may then flag a value that the programmer believed was valid because the validator is using a different terminology version.

Controlled Terminology in Define-XML

A complete submission is more than a collection of SAS datasets. Metadata must explain what the datasets contain. When a variable uses controlled terminology, the metadata should identify the relevant terminology in a way consistent with the Define-XML implementation.

In practical terms, the programmer or metadata specialist should be able to answer:

• What variable uses controlled terminology?
• What codelist defines its values?
• Which terminology version applies?
• Are the submitted values consistent with that codelist?
• Are sponsor extensions clearly distinguished and documented where applicable?

Controlled Terminology and Validation

Terminology validation can be viewed at several levels.

A Practical QC Checklist

Common Mistakes

1. Hard-coding values from memory. A programmer may remember a value from another study that is not appropriate for the current variable or terminology release.
2. Using a secondary terminology list. Old project spreadsheets can contain obsolete or sponsor-specific values.
3. Ignoring extensibility. The programmer adds values without checking whether the codelist is extensible.
4. Forcing a near-match. A similar phrase is mapped despite having a different clinical meaning.
5. Confusing preferred terms with submission values. The readable term is placed in the dataset when the standardized submission value is required.
6. Mixing terminology versions. Different datasets or metadata artifacts use different releases.
7. Failing to document mappings. A final value cannot be traced back to the original source concept.
8. Assuming all variables have controlled terminology. Controlled terminology applies where defined; it is not a requirement to replace every free-text value with a code.
9. Ignoring sponsor extensions. A sponsor-defined term may require explicit documentation and metadata treatment.
10. Using a label instead of a standardized value. Display text does not make an underlying code CDISC-compliant.

Terminology Mapping Versus Derivation

These concepts are related but should be kept distinct.

How to Design a Reusable Controlled-Terminology Framework

Large studies benefit from treating terminology as a reusable data asset rather than embedding mappings independently in every domain program.

A practical architecture contains:

• A versioned copy of the approved terminology package.
• A project mapping layer for source-to-standard conversions.
• An exception table for values requiring review.
• Automated checks for unmapped values and duplicate mappings.
• Metadata links between variables and their codelists.
• Documentation describing sponsor extensions and special cases.

This approach reduces duplicated programming and makes terminology changes easier to manage.

Example: End-to-End Terminology QC

Suppose a source system contains 1,250 records for a categorical variable. Before the final SDTM dataset is released, the programmer can create a frequency table of the source values, join the approved mapping, and compare the resulting standardized values with the applicable terminology.

Step 1  Source frequency table
Step 2  Normalize source strings
Step 3  Apply approved mapping
Step 4  Report unmapped values
Step 5  Review ambiguous concepts
Step 6  Create standardized dataset
Step 7  Compare final values to CT
Step 8  Verify metadata / Define-XML
Step 9  Run standards validation
Step 10 Archive mapping and QC evidence

The objective is not simply to make a program run. The objective is to make the transformation repeatable, reviewable, traceable, and consistent with the approved terminology basis.

What If a Source Value Has No Exact Match?

Do not automatically choose the closest-looking term. First determine what the source value actually means.

A useful escalation path is:

What Controlled Terminology Does Not Solve

Controlled terminology standardizes vocabulary, but it does not solve every data-standardization problem.

• It does not determine whether a source record was entered correctly.
• It does not determine the correct SDTM domain by itself.
• It does not replace clinical review of ambiguous source data.
• It does not replace SDTM or ADaM structural rules.
• It does not determine statistical derivations.
• It does not replace Define-XML metadata.
• It does not eliminate the need for submission validation.

Controlled Terminology in the Broader CDISC Workflow

Practical Terminology Checklist for Clinical Programmers

The Most Important Concept

The central idea is simple: controlled terminology creates a shared vocabulary for standardized clinical data.

But using that vocabulary correctly requires more than copying a code into a dataset. The programmer must understand the variable context, identify the correct codelist, use the correct terminology version, distinguish submission values from human-readable terms, respect extensibility rules, preserve clinical meaning, and maintain traceability.

When terminology is managed systematically, the same mapping can support SDTM programming, ADaM development, Define-XML metadata, validation, and regulatory review.

References

CDISC. Controlled Terminology. CDISC standards and terminology resources.
CDISC. Study Data Tabulation Model (SDTM). Applicable SDTM implementation guides and controlled terminology guidance.
CDISC. Analysis Data Model (ADaM). Applicable ADaM implementation guidance and terminology usage.
CDISC. Define-XML. Dataset and metadata exchange standard for describing clinical-trial submission data.
National Cancer Institute. Enterprise Vocabulary Services (EVS). Terminology services and terminology resources used in the clinical-research standards ecosystem.