Controlled Terminology

Applications can share the same trial definition and still interpret a value differently. A field might display “Yes” while an exchanged dataset uses “Y”. A test name might have both a readable description and a shorter submission value.

Controlled Terminology provides defined terms and permitted values for particular data items. CDISC develops this terminology with the National Cancer Institute’s Enterprise Vocabulary Services. It helps different applications interpret coded information consistently.

A shared vocabulary across the lifecycle

CDISC standards support different parts of clinical research. Terminology contributes to each part rather than appearing as one final conversion step.

%%{init: {"flowchart": {"nodeSpacing": 20, "rankSpacing": 20, "padding": 8}}}%%
flowchart TB
    subgraph Lifecycle["CDISC standards model"]
        direction LR
        Planning["Planning<br/>Protocol and<br/>trial design"] --> Collection["Data collection<br/>CDASH · LAB"]
        Collection --> Tabulation["Data tabulation<br/>SDTM · SEND"]
        Tabulation --> Analysis["Data analysis<br/>ADaM"]
    end
    Lifecycle --- Terminology["Controlled Terminology<br/>and Glossary"]

The arrows show the progression of work. Moving between these representations involves specifications and mappings.

CDASH supports consistent collection definitions. SDTM organizes clinical observations for tabulation. ADaM supports analysis datasets and traceability. The wider standards family also includes LAB for laboratory data exchange and SEND for nonclinical tabulation.

The glossary defines the language used to describe the work. Controlled Terminology provides applicable codelists and values within the standards.

Codelists give values their context

A codelist identifies a set of terms for a particular purpose. Each term has a definition and an identity. A displayed label and a submission value can express that same term in different ways.

For example, the No Yes Response codelist includes Y for Yes. The field needs the appropriate codelist binding so a receiving application knows what that value means.

The codelist, term and terminology release matter together. Similar labels in different lists do not establish that the terms can be exchanged. Where representations differ, an explicit mapping preserves the relationship.

Return to the assessment

For our baseline and Week 12 assessment, the trial team decides what must be measured. The assessment definition describes the score and its response scale. Relevant terminology can supply standardized terms for associated categories, qualifiers or units.

These responsibilities fit together. The trial design establishes what is needed and when. The measurement definition explains the assessment. Terminology supplies agreed values where a codelist applies.

A Biomedical Concept brings measurement meaning and its properties together. That is a broader role than providing an answer list, and it becomes important on the next page.

Exchange the data and describe its structure

The lifecycle also needs exchange formats. ODM and Define-XML serve different purposes within that exchange.

flowchart TD
    Exchange["Data archive and exchange"] --> ODM["Operational Data Model<br/>ODM"]
    Exchange --> Define["Define-XML"]

ODM exchanges clinical data with associated metadata and audit information. Define-XML describes tabular datasets, including variables and controlled terms. The format carries information; its models, mappings and terminology make the content interpretable.

We now have protocol structure, a connected trial model, repositories and shared values. 360i brings these foundations together around collection and analysis specifications.