SDTM 3.1.1 Implementation Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 183

Download
Open PDF In Browser	View PDF

CDISC SDTM Implementation Guide (Version 3.1.1)

Study Data Tabulation Model
Implementation Guide:
Human Clinical Trials
Prepared by the
CDISC Submission Data Standards Team

Notes to Readers
•

This is the implementation guide for Version 1.1 of the CDISC Study Data Tabulation Model, posted for
comment.

•

This Implementation Guide comprises version 3.1.1 of the CDISC Submission Data Standards and Domain
Models.

•

See CDISC notes and assumptions regarding use of --OCCUR variable in CM, SU, AE, MH domains in Section 6.

Revision History
Date
2004-07-14

Version
3.1

2005-08-26

3.1.1 Final

Summary of Changes
Released version reflecting all changes and
corrections identified during comment periods.
Released version reflecting all changes and
corrections identified during comment period.

Note: Please see Appendix 10.7 for Representations and Warranties; Limitations of Liability, and Disclaimers.

CDISC, © 2005. All rights reserved
FINAL

Page 1
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

CONTENTS
1
1.1
1.2
1.3
1.4
1.5

INTRODUCTION ..................................................................................................................................................5
PURPOSE.....................................................................................................................................................5
ORGANIZATION OF THIS DOCUMENT...........................................................................................................6
RELATIONSHIP TO PRIOR CDISC DOCUMENTS .......................................................................................6
HOW TO READ THIS IMPLEMENTATION GUIDE ...........................................................................................8
SUBMITTING COMMENTS .......................................................................................................................8

FUNDAMENTALS OF THE SDTM........................................................................................................................9
2.1
OBSERVATIONS AND VARIABLES ...........................................................................................................9
2.2
DATASETS AND DOMAINS .........................................................................................................................10
2.3
SPECIAL-PURPOSE DOMAINS
........................................................................................................... 11
2.4
THE GENERAL DOMAIN CLASSES .......................................................................................................... 11
2.5
THE CDISC STANDARD DOMAIN MODELS...............................................................................................12
2.6
CREATING A NEW DOMAIN .......................................................................................................................13
2.6.1
How to Include Variables in New Domains (Steps 4 through 7).....................................................15

SUBMITTING DATA IN STANDARD FORMAT .....................................................................................................16
3.1
STANDARD METADATA FOR DATASET CONTENTS AND ATTRIBUTES..........................................................16
3.2
USING THE CDISC DOMAIN MODELS IN REGULATORY SUBMISSIONS ......................................................17
3.2.1
CDISC Submission Dataset Definition Metadata ...........................................................................17
3.2.2
CDISC Submission Value-Level Metadata .....................................................................................19
3.2.3
Conformance...................................................................................................................................20

ASSUMPTIONS FOR DOMAIN MODELS ............................................................................................................21
4.1
GENERAL ASSUMPTIONS FOR ALL DOMAINS ............................................................................................21
4.1.1
General Dataset Assumptions .........................................................................................................21
4.1.2
General Variable Assumptions ........................................................................................................22
4.1.3
Coding and Controlled Terminology Assumptions .........................................................................23
4.1.4
Actual and Relative Time Assumptions ..........................................................................................25
4.1.5
Other Assumptions..........................................................................................................................31

MODELS FOR SPECIAL PURPOSE DOMAINS ....................................................................................................35
5.1.1
Demographics Domain Model — DM............................................................................................35
5.1.1.1 Assumptions for Demographics (DM) domain model ....................................................................37
5.1.2
Comments Domain Model — CO...................................................................................................38
5.1.2.1 Assumptions for Comments (CO) domain model...........................................................................39

DOMAIN MODELS BASED ON THE GENERAL CLASSES ...................................................................................40
6.1
INTERVENTIONS ........................................................................................................................................40
6.1.1
Concomitant Medications — CM ...................................................................................................40
6.1.1.1 Assumptions for Concomitant Medications (CM) domain model ..................................................43
6.1.2
Exposure — EX ..............................................................................................................................45
6.1.2.1 Assumptions for Exposure (EX) domain model .............................................................................47
6.1.3
Substance Use - SU.........................................................................................................................49
6.1.3.1 Assumptions for Substance Use (SU) domain model .....................................................................52
6.2
EVENTS ....................................................................................................................................................53
6.2.1
Adverse Events — AE ....................................................................................................................53
6.2.1.1 Assumptions for Adverse Events (AE) domain model....................................................................56
6.2.2
Disposition — DS ...........................................................................................................................59
6.2.2.1 Assumptions for Disposition (DS) domain model ..........................................................................60
6.2.3
Medical History — MH ..................................................................................................................62
6.2.3.1 Assumptions for Medical History (MH) domain model .................................................................64

Page 2
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3
FINDINGS ..................................................................................................................................................66
6.3.1
ECG Test Results — EG .................................................................................................................66
6.3.1.1 Assumptions for ECG (EG) domain model ....................................................................................69
6.3.2
Inclusion/Exclusion Exceptions — IE ............................................................................................70
6.3.2.1 Assumptions for Inclusion/Exclusion Exceptions (IE) domain model ...........................................71
6.3.3
Laboratory Test Results — LB........................................................................................................72
6.3.3.1 Assumptions for Laboratory Test Results (LB) domain model.......................................................75
6.3.4
Physical Examinations — PE..........................................................................................................76
6.3.4.1 Assumptions for Physical Examinations (PE) domain model.........................................................78
6.3.5
Questionnaires — QS......................................................................................................................79
6.3.5.1 Assumptions for Questionnaire (QS) domain model ......................................................................81
6.3.6
Subject Characteristics — SC .........................................................................................................82
6.3.6.1 Assumptions for Subject Characteristics (SC) domain model ........................................................83
6.3.7
Vital Signs — VS............................................................................................................................84
7

TRIAL DESIGN DATASETS ................................................................................................................................87
7.1
INTRODUCTION ...................................................................................................................................87
7.2
PLANNED ELEMENTS, ARMS, AND VISITS
..........................................................................................88
7.2.1
Trial Elements .................................................................................................................................88
7.2.2
Trial Arms .......................................................................................................................................89
7.2.3
Trial Visits.......................................................................................................................................90
7.3
SUBJECT ELEMENTS AND VISITS
......................................................................................................91
7.3.1
Subject Elements.............................................................................................................................91
7.3.2
Subject Visits...................................................................................................................................92
7.4
TRIAL ARMS .............................................................................................................................................93
7.4.1
Identifying Trial Arms.....................................................................................................................93
7.4.2
Developing the Trial Arms Table ....................................................................................................94
7.4.3
Distinguishing between Branches and Transitions........................................................................101
7.4.4
Trial Epoch Concept .....................................................................................................................101
7.4.5
Rules concept ................................................................................................................................106
7.4.6
Recap of Trial Arms Variables ......................................................................................................106
7.4.7
Truncated Arms.............................................................................................................................107
7.5
TRIAL ELEMENTS ...................................................................................................................................107
7.5.1
Identifying Trial Elements ............................................................................................................109
7.5.2
Developing the Trial Elements Table ............................................................................................ 110
7.5.3
Recap of Trial Elements Variables ................................................................................................ 112
7.5.4
Distinguishing Elements from Epochs.......................................................................................... 112
7.6
TRIAL VISITS .......................................................................................................................................... 113
7.6.1
Identifying Trial Visits .................................................................................................................. 113
7.6.2
Developing the Trial Visits Table.................................................................................................. 113
7.6.3
Recap of Trial Visits Variables ...................................................................................................... 114
7.7
SUBJECT ELEMENTS ............................................................................................................................... 115
7.7.1
Identifying Subject Elements ........................................................................................................ 115
7.7.2
Unplanned Elements ..................................................................................................................... 115
7.7.3
Deriving SE End Date/Times ........................................................................................................ 115
7.7.4
Recap of Subject Elements Variables............................................................................................ 116
7.7.5
Using Subject Elements Data to Place Subject Data within an Element or Epoch ....................... 116
7.8
SUBJECT VISITS ...................................................................................................................................... 116
7.8.1
Identifying Subject Visits.............................................................................................................. 116
7.8.2
Recap of Subject Visits Variables.................................................................................................. 117
7.9
TRIAL INCLUSION/EXCLUSION CRITERIA................................................................................................ 117
7.10
TRIAL SUMMARY INFORMATION ......................................................................................................... 118
7.11
HOW TO MODEL THE DESIGN OF A CLINICAL TRIAL ................................................................................. 119

REPRESENTING DATA RELATIONSHIPS ....................................................................................................................120
8.1
RELATING GROUPS OF RECORDS WITHIN A DOMAIN
.....................................................................121
8.1.1
--GRPID Example.........................................................................................................................121

CDISC, © 2005. All rights reserved
FINAL

Page 3
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.2
8.2.1
8.2.2
8.3
8.3.1
8.4
8.4.1
8.4.2
8.4.3
8.5
8.5.1
8.6

RELATING PEER RECORDS IN SEPARATE DATASETS ................................................................122
RELREC Dataset ..........................................................................................................................123
RELREC Dataset Examples..........................................................................................................123
RELATING DATASETS .......................................................................................................................124
RELREC Dataset Relationship Example ......................................................................................124
RELATING NON-STANDARD VARIABLE VALUES TO A PARENT DOMAIN .............................125
SUPPQUAL Dataset .....................................................................................................................126
Submitting Supplemental Qualifiers in Separate Datasets............................................................127
SUPPQUAL Examples .................................................................................................................127
RELATING COMMENTS TO A PARENT DOMAIN ..........................................................................128
COMMENTS Example.................................................................................................................128
HOW TO DETERMINE WHERE DATA BELONG IN THE SDTM...................................................................129

IMPLEMENTATION EXAMPLES ......................................................................................................................131
9.1
DEMOGRAPHICS EXAMPLE ............................................................................................................131
9.2
INTERVENTIONS EXAMPLES..........................................................................................................131
9.2.1
CM Example: Intermittent Use of Concomitant Medications......................................................131
9.2.2
EX Examples: ...............................................................................................................................133
9.2.3
SU Example: .................................................................................................................................135
9.3
EVENTS EXAMPLES ..........................................................................................................................139
9.3.1
AE Example ..................................................................................................................................139
9.3.2
DS Examples.................................................................................................................................140
9.3.3 MH Example: ............................................................................................................................................143
9.4
FINDINGS EXAMPLES.......................................................................................................................144
9.4.1
EG Examples ................................................................................................................................144
9.4.2
IE Example....................................................................................................................................147
9.4.3
LB Examples.................................................................................................................................148
9.4.4
PE Example...................................................................................................................................151
9.4.5
QS Examples.................................................................................................................................153
9.4.6
SC Example ..................................................................................................................................155
9.4.7
VS Example ..................................................................................................................................156
9.5
TRIAL DESIGN EXAMPLES...............................................................................................................158
9.5.1
Defining Epochs - a How-to Example Using the Example Crossover Study................................158
9.5.2
Trial Summary Example ...............................................................................................................162

APPENDICES ...................................................................................................................................................163
10.1
CDISC SDS TEAM .................................................................................................................................163
10.2
GLOSSARY OF TERMS ............................................................................................................................164
10.3
STANDARDIZED AND RESERVED CODES
.......................................................................................165
10.3.1
Reserved Domain Codes...............................................................................................................165
10.3.2
Electrocardiogram Test Codes (for measured or calculated parameters) ......................................167
10.3.3
Vital Signs Test Codes ..................................................................................................................167
10.3.4
Supplemental Qualifiers Name Codes ..........................................................................................168
10.3.5
Trial Summary Codes ...................................................................................................................169
10.4
CDISC VARIABLE-NAMING FRAGMENTS ...............................................................................................171
10.5
LESSONS LEARNED FROM THE PILOT ......................................................................................................173
10.6
REVISION HISTORY
.........................................................................................................................175
10.7
REPRESENTATIONS AND WARRANTIES; LIMITATIONS OF LIABILITY, AND DISCLAIMERS ..........183

Page 4
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

1 Introduction
1.1

PURPOSE

This document describes the CDISC Version 3.1.1 (V3.1.1) Submission Data Standards (SDS), which have been
prepared by the Submissions Data Standards team of the Clinical Data Interchange Standards Consortium (CDISC).
Like its predecessors, V3.1.1 is intended to guide the organization, structure, and format of standard clinical trial
tabulation datasets submitted to a regulatory authority such as the US Food and Drug Administration (FDA). V3.1.1
supersedes all prior versions of the CDISC Submission Data Standards.
This document should be used in close concert with the CDISC Study Data Tabulation Model (SDTM) available at
http://www.cdisc.org/models/sds/v3.1/index.html and describes how to implement the SDTM for use with data tabulations
submitted for human clinical trials. Version 1.1 of the SDTM, which should be read before this Implementation
Guide (SDTMIG), describes a general conceptual model for representing clinical study data that is submitted to
regulatory authorities. SDTMIG V3.1.1 provides specific domain models, assumptions, business rules, and
examples for preparing standard datasets that are based on the SDTM.
Tabulation datasets, which are electronic listings of individual observations for a subject that comprise the essential
data collected in a clinical trial, are one of four types of data currently submitted to the FDA along with patient
profiles, listings, and analysis files. By submitting tabulations that conform to the standard structure, sponsors may
benefit by no longer having to submit separate patient profiles or listings with a product marketing application.
V3.1.1 is not currently intended to fully meet the needs supported by analysis datasets, which will continue to be
submitted separately in addition to the tabulations. Since July 2004, the FDA has referenced use of the SDTM in the
Study Data Specifications for the Electronic Common Technical Document, available at
http://www.fda.gov/cder/regulatory/ersr/Studydata-v1.1.pdf.
The availability of standard submission data will provide many benefits to regulatory reviewers. Reviewers can be
trained in the principles of standardized datasets and the use of standard software tools, and thus be able to work
with the data more effectively with less preparation time. Another benefit of the standardized datasets is to support
the FDA’s efforts to develop a repository for all submitted trial data and a suite of standard review tools to access,
manipulate, and view the tabulations. Use of these data standards is also expected to benefit industry by
streamlining the flow of data from collection through submissions, and facilitating data interchange between
partners and providers. Note that the SDTM represents an interchange standard, rather than a presentation format -it is assumed that tabulation data will be transformed by software tools to better support viewing and analysis.
This document is intended for companies and individuals involved in the collection, preparation, and analysis of
clinical data that will be submitted to regulatory authorities. Audiences are also advised to read the CDISC
Submission Metadata Model available at http://www.cdisc.org/pdf/SubmissionMetadataModelV2.pdf for additional
historical background on how to provide metadata descriptions for submission data. The primary goal of the
Metadata Model is to provide regulatory reviewers with a clear understanding of the datasets provided in a
submission by communicating clear descriptions of the structure, purpose, attributes, and contents of each dataset
and dataset variable. Guidance, specifications, and regulations for the application of this model will be provided
separately by regulatory authorities. Audiences are advised to refer to these guidance documents for the most
current recommendations for the submission of clinical data.

CDISC, © 2005. All rights reserved
FINAL

Page 5
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

1.2

ORGANIZATION OF THIS DOCUMENT

This document is organized into the following sections:
•

Section 1, INTRODUCTION, provides an overall introduction to the V3.1.1 models and describes changes
from prior versions.

•

Section 2, FUNDAMENTALS OF THE SDTM, recaps the basic concepts of the SDTM, and describes how this
implementation guide should be used in concert with the SDTM.

•

Section 3, SUBMITTING DATA IN STANDARD FORMAT, explains how to describe metadata for regulatory
submissions, and how to assess conformance with the standards.

•

Section 4, ASSUMPTIONS FOR DOMAIN MODELS, describes basic concepts, business rules, and
assumptions that should be taken into consideration before applying the domain models.

•

Section 5, MODELS FOR SPECIAL PURPOSE DOMAINS, describes the Demographics and Comments
special-purpose domains.

•

Section 6, DOMAIN MODELS BASED ON THE GENERAL CLASSES, provides specific annotated metadata
models based on the three general observation classes. These include the revised V3.1 models for the ten
common domains previously modeled by CDISC in Version 2.0; the domains for Inclusion/Exclusion
Exceptions, Subject Characteristics, and Substance Use introduced in Version 3.0; and the Questionnaires
domain introduced with V 3.1.

•

Section 7, TRIAL DESIGN DATASETS, describes implementation issues related to the use of the Trial Design
Model described in the SDTM.

•

Section 8, REPRESENTING DATA RELATIONSHIPS, describes how to represent relationships between
separate domains, datasets, and/or records.

•

Section 9, IMPLEMENTATION EXAMPLES, provides specific examples based on actual clinical-trial data.
Several of these examples were prepared as a result of the V3 Pilot Project conducted in the Summer of 2003.

•

Section 10, APPENDICES, provides additional background material and describes other supplemental material
relevant to implementation.

1.3

RELATIONSHIP TO PRIOR CDISC DOCUMENTS

As stated above, this document, Version 3.1.1, together with the SDTM, represents the most recent version of the
CDISC Submission Data Domain Models, previously known as V3.1. Since all updates to Version 3.1 are intended
to be backward compatible with version 3.1, the term “V3.x” is used to refer to Version 3.1 and all subsequent
versions.
The most significant changes since V3.1 in this version include:
•

The implementation guide has been expanded with new variables for consistency with Version 1.1 of the
SDTM

•

Sponsors may now include any valid variable from the same SDTM general class in a domain model.
Previously, domain models were restricted to only those qualifier variables specified in the Implementation
Guide

•

A new Trial Summary (TS) dataset has been added to the Trial Design Model to describe summary
characteristics of the study

Page 6
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

•

A preferred alternative means of submitting supplemental qualifiers in separate datasets per domain has
been defined in Section 8.

•

Substantial clarifications in Section 8

•

A new section on warranties and disclaimers has been added as Appendix 10.7

•

Numerous corrections have been applied to the text, assumptions, domain models and examples
throughout.

A detailed list of changes between versions is provided in Appendix 10.6.
Note that V3.1.1 continues to represent most data in a vertical structure. Standard horizontal listings of data, such as
those described in the V2 horizontal representations of ECGs and Vitals by visit, will be produced by FDA standard
review tools. A complete list of changes from V3.1 is included in the V3.1.1 Change Log (see Section 10.6.3).
V3.1 was the first fully implementation-ready version of the CDISC Submission Data Standards that was directly
referenced by the FDA for use on clinical studies involving human drug products. However, future improvements
and enhancements such as V3.1.1 will continue to be made as sponsors develop more experience submitting data in
this format. Therefore, CDISC will be preparing regular updates to the implementation guide to provide corrections,
clarifications, additional domain models, examples, business rules, and conventions for using the standard domain
models. CDISC will produce further documentation on controlled terminology as separate publications beginning in
2005, so sponsors are encouraged to check the CDISC website (www.cdisc.org/standards/) frequently for additional
information.

CDISC, © 2005. All rights reserved
FINAL

Page 7
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

1.4

HOW TO READ THIS IMPLEMENTATION GUIDE

The SDS V3.1.1 Implementation Guide (SDTMIG) is best read online, so the reader can benefit from the many
hyperlinks included to both internal and external references. The following guidelines may be helpful in reading
this document:
1.

First read the SDTM to gain a general understanding of the conceptual model for the Submission Data
Standards.

Next, read Sections 1-3 of this document to review the key concepts for preparing domains and submitting
data to regulatory authorities. Refer to the Glossary in Section 10.2 as necessary.

Read the General Assumptions for all Domains in Section 4.

Review Sections 5 and 6, referring back to Assumptions as directed (hyperlinks are provided).

Review the Implementation examples for each domain in Section 9 to gain an understanding of how to
apply the domain models for specific types of data.

Read Section 7 to understand the fundamentals of the Trial Design Model and consider how to apply the
concepts for typical protocols. Since the Trial Design model includes many new concepts, readers may
choose to defer this step until after they have mastered the essentials of creating standardized domains.
New extensions to the trial design model will be published separately on the CDISC web site.

Review Section 8 to learn the advanced concepts of how to express relationships between datasets, records
and additional variables not specifically defined in the models.

Finally, review the additional appendices as appropriate.

1.5

SUBMITTING COMMENTS

Comments on this document can be submitted through the CDISC Discussion Board.

Page 8
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

2 Fundamentals of the SDTM
2.1

OBSERVATIONS AND VARIABLES

The V3.x submission data standards are based on the SDTM Version 1.1 document, which provides a
general framework for organizing information collected during clinical trials that is to be submitted to the
FDA. The SDTM is built around the concept of observations collected about subjects who participated in a
clinical study. Each observation can be described by a series of variables, corresponding to a row in a
dataset or table. Each variable can be classified according to its Role. A Role determines the type of
information conveyed by the variable about each distinct observation and how it can be used. Variables
can be classified into four major roles:
•

Identifier variables, which identify the study, subject of the observation, the domain, and the sequence
number of the record

•

Topic variables, which specify the focus of the observation (such as the name of a lab test)

•

Timing variables, which describe the timing of the observation (such as start date and end date)

•

Qualifier variables, which include additional illustrative text, or numeric values that describe the
results or additional traits of the observation (such as units or descriptive adjectives).

A fifth type of variable role, Rule, was introduced with V3.1 to express an algorithm or executable method
to define start, end, or looping conditions in the Trial Design model.
The set of Qualifier variables can be further categorized into five sub-classes:
•

Grouping Qualifiers are used to group together a collection of observations within the same domain.
Examples include --CAT and --SCAT.

•

Result Qualifiers describe the specific results associated with the topic variable for a finding. It is the
answer to the question raised by the topic variable. Examples include --ORRES, --STRESC, and
--STRESN. Many of the values in the DM domain are also classified as Result Qualifiers.

•

Synonym Qualifiers specify an alternative name for a particular variable in an observation. Examples
include --MODIFY and --DECOD, which are equivalent terms for a --TRT or --TERM topic variable,
--TEST and --LOINC which are equivalent terms for a --TESTCD.

•

Record Qualifiers define additional attributes of the observation record as a whole (rather than
describing a particular variable within a record). Examples include --REASND, AESLIFE, and all
other SAE flag variables in the AE domain; and --BLFL, --POS and --LOC, --SPEC, --LOT, --NAM.

•

Variable Qualifiers are used to further modify or describe a specific variable within an observation
and is only meaningful in the context of the variable they qualify. Examples include --ORRESU,
--ORNRHI, and --ORNRLO, all of which are variable qualifiers of --ORRES, and --DOSU and
--DOSFRM, all of which are variable qualifiers of --DOSE.

For example, in the observation, 'Subject 101 had mild nausea starting on Study Day 6,' the Topic variable
value is the term for the adverse event, 'NAUSEA'. The Identifier variable is the subject identifier, '101'.
The Timing variable is the study day of the start of the event, which captures the information, 'starting on
Study Day 6', while an example of a Record Qualifier is the severity, the value for which is 'MILD'.
Additional Timing and Qualifier variables could be included to provide the necessary detail to adequately
describe an observation.
CDISC, © 2005. All rights reserved
FINAL

Page 9
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

2.2

DATASETS AND DOMAINS

Observations are normally collected for all subjects in a series of domains. A domain is defined as a
collection of logically-related observations with a topic-specific commonality about the subjects in the trial.
The logic of the relationship may relate to the scientific subject matter of the data, or to its role in the trial.
Typically, each domain is represented by a dataset, but it is possible to have information relevant to the
same topicality spread among multiple datasets (see Section 8.6). Each dataset is distinguished by a
unique, two-character DOMAIN code that should be used consistently throughout the submission. This
DOMAIN code is used in the dataset name, the value of the DOMAIN variable within that dataset, and as a
prefix for most variable names in the dataset.
The dataset structure for observations is a flat file representing a table with one or more rows and columns.
Normally, one dataset is submitted for each domain. Each row of the dataset represents a single
observation and each column represents one of the variables. Each dataset or table is accompanied by
metadata definitions that provide information about the variables used in the dataset. The metadata are
described in a data definition document named 'Define' that is submitted along with the data to regulatory
authorities. (See the Case Report Tabulation Data Definition Specification (define.xml), available on the
CDISC website, for information about an xml representation of the data definition document.) The CDISC
Submission Metadata Model uses seven distinct metadata attributes to be defined for each dataset variable
in the metadata definition document:
•

The Variable Name (limited to 8-characters for compatibility with the SAS Transport format)

•

A descriptive Variable Label, using up to 40 characters, which should be unique for each variable in
the dataset

•

The data Type (e.g., whether the variable value is a character or numeric)

•

The set of controlled terminology for the value or the presentation format of the variable
(Controlled Terms or Format)

•

The Origin or source of each variable

•

The Role of the variable, which determines how the variable is used in the dataset. For the V3.x
domain models, roles are used to represent the categories of variables as Identifier, Topic, Timing, or
the five types of Qualifiers. Since these roles are predefined for all domains that follow the general
classes, they do not need to be specified by sponsors in their Define data definition document. Actual
submission metadata may use additional role designations, and more than one role may be assigned per
variable to meet different needs.

•

Comments or other relevant information about the variable or its data.

Data stored in dataset variables include both raw (as originally collected) and derived values (e.g., converted
into standard units, or computed on the basis of multiple values, such as an average). In the SDTM only the
name, label, and type are listed with a set of CDISC guidelines that provide a general description for each
variable used by a general observation class. The Domain models included in Sections 5 and 6 of this document
provide additional information about Controlled Terms or Format and Origin, as well as notes on proper usage.
Comments are included as necessary according to the needs of individual studies.
The presence of an asterisk (*) in the 'Controlled Terms or Format' column indicates that a discrete set of
values (controlled terminology) is expected to be made available for this variable. This set of values may be
sponsor-defined in cases where standard vocabularies have not yet been defined (represented by a single *) or
from an external published source such as MedDRA (represented by **). The CDISC controlled terminology
group will be publishing additional guidance on use of controlled terminology separately in the future.

Page 10
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

2.3

SPECIAL-PURPOSE DOMAINS

The CDISC V3.x Submission Data Domain Models include special-purpose domains with a specific
structure and cannot be extended with any additional qualifier or timing variables other than those
specified. Two of these – Demographics and Comments -- are described in Section 5 of this document.
.Demographics includes a set of standard variables that describe each subject in a clinical study; Comments
describes a fixed structure for recording free-text comments on a subject, or comments related to records or
groups of records in other domains.
Additional fixed structure, non-extensible special-purpose domains are discussed in the Trial Design model
described in Section 7 and in Section 8, which discusses record relationships.

2.4

THE GENERAL DOMAIN CLASSES

Most observations collected during the study (other than those represented in special purpose domains)
should be divided among three general observation classes: Interventions, Events, or Findings:
•

The Interventions class captures investigational treatments, therapeutic treatments, and surgical
procedures that are intentionally administered to the subject (with some actual or expected
physiological effect) either as specified by the study protocol (e.g., “exposure”), coincident with the
study assessment period (e.g., “concomitant medications”), or other substances self-administered by
the subject (such as alcohol, tobacco, or caffeine)

•

The Events class captures occurrences or incidents independent of planned study evaluations occurring
during the trial (e.g., 'adverse events' or 'disposition') or prior to the trial (e.g., 'medical history').

•

The Findings class captures the observations resulting from planned evaluations to address specific
questions such as observations made during a physical examination, laboratory tests, ECG testing, and
sets of individual questions listed on questionnaires.

In most cases, the identification of the general class appropriate to a specific collection of data by topicality
is straightforward. Often the Findings general class is the best choice for general observational data
collected as measurements or responses to questions. In cases when the topicality may not be as clear, the
choice of class may be based more on the scientific intent of the protocol or analysis plan or the data
structure. Appendix 10.6 of this document proposes additional guidelines for choosing the appropriate
general class and proposes a modeling approach where a findings structure should be used to represent data
that may relate to interventions or events records.
All datasets based on any of the general observation classes share a set of common Identifier variables and
Timing variables, which are described in the SDTM. Three general rules apply when determining which
variables to include in a domain:
•
•
•

The same set of Identifier variables applies to all domains based on the general observation classes. An
optional identifier can be used wherever appropriate.
Any valid Timing variable is permissible for use in any submission dataset (such as to describe studies
with more precise time points such as a Pharmacokinetics trial), but it should be used consistently
where applicable for all domains.
Any additional Qualifier variables from the same general class may be added to a domain model.

Assumptions for use of the Domain are described in Section 4 of this document.

CDISC, © 2005. All rights reserved
FINAL

Page 11
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

2.5

THE CDISC STANDARD DOMAIN MODELS

The following standard domains with their respective DOMAIN codes have been defined or referenced by
CDISC in this document (domain models marked with an asterisk (*) are not included in this document and
will be posted separately for comment):
•

Special-Purpose Domains:
Demographics - DM

•

Comments - CO

•

Exposure - EX

Interventions:
•

Concomitant Medications - CM

•

Substance Use - SU
Events:

•

Adverse Events - AE

•

Disposition - DS

•

Medical History - MH

•

*Protocol Deviations - DV

Findings:
•

*Drug Accountability - DA

•

ECG Tests - EG

•

Inclusion/Exclusion Exceptions - IE

•

Laboratory Tests - LB

•

*Microbiology Specimens - MB

•

Questionnaires - QS

•

*Microbiology Susceptibility - MS

•

Physical Examinations - PE

•

*Pharmacokinetics Concentrations - PC

•

Subject Characteristics - SC

•

*Pharmacokinetics Parameters - PP

•

Vital Signs - VS

•

Trial Design Domains:
Trial Elements - TE

•

Trial Arms - TA

•

Trial Visits - TV

•

Subject Elements - SE

•

Subject Visits - SV

•

Trial Inclusion/Exclusion Criteria – TI

•

Trial Summary - TS

•

Special-Purpose Relationship Datasets (defined in Section 8):
Supplemental Qualifiers - SUPPQUAL

•

Relate Records - RELREC

Note, a sponsor would only submit the data domains that are actually collected. Decisions on what data to
collect should be based on the scientific objectives of the study. A list of standard domain codes for other
commonly used domains is provided in Appendix 10.3.1. In the future, additional domain models based on
the three general observation classes, and additional standard domain codes will be published by CDISC,
and sponsors are encouraged to check the CDISC web site periodically for updates.

Page 12
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
When preparing submissions based on the domain models, sponsors should not add any variables other
than additional relevant timing variables and qualifiers from the same general class to the V3.x models,
since non-standard variables could compromise the FDA’s abilities to populate the data repository and use
standard tools. A sponsor is free to drop certain variables from the domain model, and the corresponding
descriptions from the data definition document, but new variables (other than those that are from the same
general class) must not be added, and existing variables should not be renamed, or modified for novel
usage.
When evaluating how to represent data according to the V3.x model, sponsors should keep in mind that the
V3/V3.x paradigm is very different from that of previous versions. Data that historically would have been
modeled horizontally into one record is now often converted into multiple records in V3.x. If additional
variables remain that cannot be mapped to the variables defined for a standard domain model, Sponsors
should use the Supplemental Qualifiers dataset described in Section 8.4 of this document. Note that any
collected data in an analysis dataset must also appear in a tabulation dataset. If a sponsor wishes to propose
that new variables be added to the Version 3.x models, they should provide the rationale and description of
the added variable(s) to the CDISC SDS Team so the impact on V3.x models can be assessed. Specific
examples are also requested to illustrate the context for the new variables. This information can be provided
to the CDISC SDS Team by posting it on the CDISC Public Discussion Forum.

2.6

CREATING A NEW DOMAIN

This section describes the overall process of how to create a new CDISC SDTM domain. New domains
should only be created if a published standard domain does not already exist for the data being modeled.
When a new domain is created, one of the most important decisions is the choice of the proper general
class. Deciding on the number of separate domains to use within a general class should be made based on
the specific requirements of the study. See Section 9 of this document for specific examples of the
application of the CDISC SDTM for Interventions, Events and Findings general domain models. When
creating a new domain, sponsors should follow the predefined steps listed below:
1.

Ensure that there is a definite need to create a new domain. For example, the Findings vertical
structure can often accommodate many types of information that may have previously spanned
separate domains in a sponsor’s internal database. In V3.x, such information can often be
represented as separate records in the same submissions domain. Mechanisms for incorporating
new Qualifier variables not described in the general observation classes and for defining
relationships between separate datasets or records are described in Section 8 of this document.

Once the need for a new domain is determined, verify that there are no existing domain models by
reviewing the current models posted on the CDISC website.

Choose the general observation class (Interventions, Events, or Findings) that best fits the data as
follows:
a.

Identify the topic of the observation and determine which of the three general observation
classes it most closely resembles. If the new domain shares both the same topicality and
general observation class as an existing domain in the submission, the existing domain should
be used.

Look for other existing domain models that may serve as a relevant prototype
(most domains will follow the Findings model).

Determine if the chosen general observation class has most of the required and expected
qualifiers for the new domain.

Select the variables that apply to the new domain once you have selected the general
observation class.

Select and include the identifier variables (USUBJID, STUDYID, and --SEQ).

Include the topic variable from the identified general observation class
(e.g., --TESTCD for Findings).

CDISC, © 2005. All rights reserved
FINAL

Page 13
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
6.

Select and include the relevant Qualifier variables from the identified general observation class
(e.g., Findings) omitting any extraneous variables from the general model that do not apply.

Select and include the applicable timing variables from the SDTM.

Check with the CDISC website for a previously identified two-character domain identifier or
abbreviation. If one has not been assigned by CDISC, then the sponsor may select the unique twocharacter domain code to be used consistently throughout the submission.

Apply the two-character domain code to the appropriate variables in the domain.
a.

Replace all variable prefixes shown in the models with two hyphens '--' with the domain code.

10. Set the order of variables consistent with the order of the domain model most similar to the new
domain.
11. Adjust the labels of the variables only as appropriate to properly convey the meaning in the
context of the data being submitted in the newly-created domain. Use title case for all labels
(title case means to capitalize the first letter of every word except for articles, prepositions, and
conjunctions).
12. Compare for consistency with CDISC General Assumptions and other variables used in similar
domain examples to ensure new variables are not being created when appropriate standard
variables already exist.
13. Label the dataset within the metadata definition document as follows: ,
, CDISC SDTM Version ,
.
14. Submit a request to add specific new variables necessary to represent additional information in the
general observation classes through the CDISC Public Discussion Forum.
As noted in Step 8 of the above process, each domain is distinguished by a unique, two-character DOMAIN
code that should be used consistently throughout the submission. The two-character identifier should be
controlled for consistency so that the FDA tools for receiving data can recognize it. The DOMAIN code
should also be included in the name of the corresponding dataset files (e.g., ae.xpt) and also used as a prefix
for variables to distinguish them in the event that merges are performed between datasets using SAS.
CDISC will maintain a separate list of standard domain codes on the CDISC website and sponsors may
post additional suggested codes to add to this list through the CDISC Public Discussion Forum.

Page 14
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

2.6.1

How to Include Variables in New Domains (Steps 4 through 7)

Superset of CDISC SDS Variables

Variables for Special Purpose
Domains (Fixed & Study Design
Domains)

Variables for General Domain
Classes

Identifier
Variables

Timing Variables

Topic & Qualifier
Variables

Interventions
Specific
Variables

Events Specific
Variables

Demography &
Comment
Domain Variables

Study Design
Variables

Findings Specific
Variables

New Domain

As illustrated in the figure above, the CDISC SDTM has an inclusive superset or a predefined list of
variables. The SDTM variables are subdivided into two general variable classes: those for the 'general
observation classes' and those for the 'special domains' (those with fixed structures and the trial design
domains). For more information regarding these classifications, please see sections 2.3 and 2.4. From a
data modeling perspective, once it has been determined that a new domain is needed (i.e., there is no
published equivalent domain), the sponsor determines the domain's general observation class (either as an
Intervention, Event, or Finding) as described in steps 1, 2 and 3 above.
Next the sponsor must go through a process of selecting the variables to include in the new domain (Steps 4
through 7). All new domains will contain variables from the Identifier (e.g., subject of the observation, the
domain) and Timing (e.g., visit designators, start and end dates) variable classes. The 'Identifier Variables'
and 'Timing Variables' boxes being connected to the 'New Domain' box via a bolded solid black line
illustrate this. The new domain, however, can only inherit the Topic and Qualifier variables from the
specific general observation class that it was determined to fit. Therefore, if a new domain has been
classified as a Findings domain, it cannot contain Qualifier variables that were defined for the Intervention
or Events domain classes and vice versa. This principle is illustrated in the graphic by the 'Intervention',
'Events', and 'Findings' boxes being connected to the 'New Domain' box via dashed lines. In summary, all
new domains include Identifier and Timing variables. However, the choice of Topic and Qualifier variables
that can be included is dependent upon which general observation class the domain has been modeled as
'Interventions', 'Events', or 'Findings'.

CDISC, © 2005. All rights reserved
FINAL

Page 15
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

3 Submitting Data in
Standard Format
3.1

STANDARD METADATA FOR DATASET CONTENTS AND
ATTRIBUTES

The V3.x CDISC SDS domain models provide a standard depiction of some of the most commonly used
data domains, using the metadata attributes originally described in the CDISC Submission Metadata Model.
The descriptive metadata attributes that should be included in a submission dataset definition file as applied
in the domain models are:
•

The CDISC-standard variable name (standardized for all submissions, even though sponsors may
be using other variable names internally in their operational database)

•

The CDISC-standard variable label

•

Data type of the variable (character or numeric, to conform to the data types recognized by SAS)

•

Controlled terms and formats used by the sponsor (the CDISC domain models use a single asterisk
(*) or a double asterisk (**) to indicate when controlled terminology applies)

•

The origin or source of the data (e.g., CRF page, derived)

•

The role of the variable in the dataset corresponding to the role in the SDTM (Since these roles are
predefined for all standard domains that follow the general classes, they do not need to be
specified by sponsors in their Define data definition document.)

In addition to these metadata attributes, the CDISC domain models include two other columns to assist
sponsors in preparing their datasets — one column for notes relevant to the use of each variable, and one to
indicate how a variable is classified as a CDISC Core Variable. The concept of core variable is used both
as a measure of compliance and to provide general guidance to sponsors. CDISC Core Variables fall into
three categories:
•
•
•

A Required variable is any variable that is basic to the identification of a data record (i.e., essential
key variables and a topic variable) or is necessary to make the record meaningful. Required
variables should always be included in the dataset and cannot be null for any record.
An Expected variable is any variable necessary to make a record useful in the context of a specific
domain. Columns for Expected variables are assumed to be present in each submitted dataset even
if some values are null.
A Permissible variable should be used in a domain as appropriate when collected or derived. All
Timing variables (including those not explicitly included in a domain model) and any Qualifier
variable specified in a domain model are permissible for use in that domain. Null values are
allowed, but the Sponsor can decide whether a Permissible variable should be included as a
column when all values for that variable are null.

The Core Variable column provides guidance on which variables are normally required, expected or
permissible to include in an actual dataset based on a model (see Section 4.1.1.5). However, any decisions
regarding the specific content that is to be included for any submission should always be discussed in
advance with the regulatory agency.
Page 16
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
The domain models illustrate how to apply the SDTM when creating a specific domain dataset. In
particular, these models illustrate the selection of a subset of the variables offered in one of the general
observation classes along with applicable timing variables. The models also show how a standard variable
from a general observation class should be adjusted to meet the specific content needs of a particular
domain, including making the label more meaningful, specifying controlled terminology, and creating
domain-specific notes and examples. Thus the domain models demonstrate not only how to apply the
model for the most common domains, but also gives insight on how to apply general model concepts to
other domains not yet defined by CDISC.

3.2

USING THE CDISC DOMAIN MODELS IN REGULATORY
SUBMISSIONS

New users will find the V3.x CDISC domain models useful as a template for preparing submission files;
however, users should be aware that the set of descriptive attributes shown in the models is not precisely
the same as that required in the dataset definition document that must accompany a submission.
The specific differences are as follows:
•

The column reserved for sponsor comments in the data definition document is not included in the
CDISC domain models, since this needs to be created and populated by the sponsor for each dataset to
explain any sponsor-specific rules and definitions

•

The CDISC Notes column should not be submitted to the agency

•

The CDISC Core column should not be submitted to the agency

•

The CDISC References column should not be submitted to the agency.

The last three columns in the models that are not to be submitted are shaded so they can easily be
distinguished. In addition to the variable notes, the CDISC models include a set of general assumptions
applicable to all domains that describe many of the critical concepts behind the models (see Section 4).
A set of specific assumptions applicable only to a particular domain is listed after the data definitions for
that domain model. In summary, the main body of the Define data definition document submitted by a
sponsor should display for each data domain the 'Variable Name', 'Variable Label', 'Type', 'Controlled
Terms or Formats', 'Origin' and 'Comments' (‘Role’ is optional for standard domains).
The dataset definition document that accompanies a submission should also describe each dataset that is included
in the submission and describe the logical key structure of each dataset. While most studies will include DM and
a set of safety domains based on the three general observation classes (typically including EX, CM, AE, DS,
MH, IE, LB, and VS), the actual choice of which data to submit will depend on the protocol and the needs of the
regulatory reviewer. Dataset definition metadata should include dataset filenames, descriptions, locations,
structures, purpose, keys, and comments as described in the CDISC Submission Metadata Model and shown
below in Section 3.2.1. Note that key variables should refer to the natural keys that determine the order of
records within the dataset. The physical key structure that uniquely identifies each record in an SDTM dataset
based on a general class is actually based on the STUDYID, USUBJID and --SEQ variable in each domain.

3.2.1

CDISC Submission Dataset Definition Metadata
Key
Variables

Dataset

Description

Location

Structure

Purpose

Demographics

dm.xpt

One record per subject

Tabulation

STUDYID,
USUBJID

Comments

co.xpt

One record per comment per
subject

Tabulation

STUDYID,
USUBJID,
COSEQ

Concomitant
Medications

cm.xpt

One record per medication
intervention episode per subject

Tabulation

STUDYID,
USUBJID,
CMTRT,
CMSTDTC

CDISC, © 2005. All rights reserved
FINAL

Page 17
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Key
Variables

Dataset

Description

Location

Structure

Purpose

Exposure

ex.xpt

One record per constant dosing
interval per subject

Tabulation

STUDYID,
USUBJID,
EXTRT,
EXSTDTC

Substance Use

su.xpt

One record per substance type per
visit per subject

Tabulation

Adverse Events

ae.xpt

One record per adverse event per
subject

Tabulation

Disposition

ds.xpt

One record per disposition status
or protocol milestone per subject

Tabulation

STUDYID,
USUBJID,
VISITNUM,
SUTRT
STUDYID,
USUBJID,
AETERM,
AESTDTC
STUDYID,
USUBJID,
DSSTDTC

Medical History

mh.xpt

One record per medical history
event per subject

Tabulation

ECG

eg.xpt

One record per ECG observation
per time point per visit per subject

Tabulation

Inclusion/
Exclusion
Exceptions

ie.xpt

One record per
Inclusion/Exclusion criteria
exception per subject

Tabulation

STUDYID,
USUBJID,
IETESTCD

Laboratory
Tests

lb.xpt

One record per lab test per time
point per visit per subject

Tabulation

STUDYID,
USUBJID,
LBTESTCD
VISITNUM,
TPTNUM

Physical Exam

pe.xpt

One record per body system per
visit per subject

Tabulation

STUDYID,
USUBJID,
VISITNUM,
PETESTCD,

Questionnaires

qs.xpt

One record per question per time
point per visit per subject

Tabulation

STUDYID,
USUBJID,
QSTESTCD,
VISITNUM,
TPTNUM,
QSSEQ

Subject
Characteristics

sc.xpt

One record per characteristic per
subject

Tabulation

STUDYID,
USUBJID,
SCTESTCD

Vital Signs

vs.xpt

One record per vital sign
measurement per time point per
visit per subject

Tabulation

STUDYID,
USUBJID,
VSTESTCD,
VISITNUM,
TPTNUM

DV*

Protocol
Deviations

dv.xpt

One record per protocol deviation
per subject

Tabulation

STUDYID,
USUBJID,
DVSEQ

MB*

Microbiology

mb.xpt

One record per specimen test or
susceptibility test

Tabulation

STUDYID,
USUBJID,
MBTESTCD,
MBSEQ

Page 18
August 26, 2005

STUDYID,
USUBJID,
MHTERM
STUDYID,
USUBJID,
EGTESTCD,
VISITNUM,T
PTNUM,
EGSEQ

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
Key
Variables

Dataset

Description

Location

Structure

Purpose

MS*

Microbiology
Susceptibility

ms.xpt

One record per susceptibility
observations.

Tabulation

STUDYID,
USUBJID,
MSTESTCD,
MSSEQ

DA*

Drug
Accountability

da.xpt

One record per accountability
observation

Tabulation

STUDYID,
USUBJID,
DATESTCD,
DADTC,
DASEQ

PC*

PK
Concentrations

pc.xpt

One record per concentration per
analyte

Tabulation

STUDYID,
USUBJID,
PCTESTCD,
VISITNUM,
TPTNUM

PP*

PK Parameters

pp.xpt

One record per PK parameter per
analyte

Tabulation

STUDYID,
USUBJID,
PPTESTCD,
VISITNUM

Trial Elements

te.xpt

One record per element

Tabulation

STUDYID,
ETCD

Trial Arms

ta.xpt

One record per planned element
per arm

Tabulation

STUDYID,
ARMCD,
ETCD

Trial Visits

tv.xpt

One record per planned visit per
arm

Tabulation

STUDYID,
VISITNUM,
ARMCD

Subject
Elements

se.xpt

One record per actual element per
subject

Tabulation

STUDYID,
USUBJID,
ETCD

Subject Visits

sv.xpt

One record per subject per actual
visit

Tabulation

STUDYID,
USUBJID,
VISITNUM

Trial Inclusion/
Exclusion Criteria

ti.xpt

One record per I/E criterion

Tabulation

STUDYID,
IETESTCD

Trial Summary

ts.xpt

One record per trial summary
parameter.

Tabulation

STUDYID,
TSPARMCD,
TSSEQ

RELREC

Related Records

relrec.xpt

One record per relationship

Tabulation

STUDYID,
RDOMAIN,
USUBJID,
IDVAR,
IDVARVAL,
RELID

SUPPQUAL

Supplemental
Qualifiers

suppqual.xpt

One record per qualifier value

Tabulation

STUDYID,
RDOMAIN,
USUBJID,
IDVAR,
IDVARVAL,
QNAM

*Domain models to be published separately for comment

3.2.2

CDISC Submission Value-Level Metadata

In general, the CDISC Version 3.x data models are more closely related to normalized relational data
models in a vertical structure. This structure requires every row to have a primary key since each row of a
CDISC, © 2005. All rights reserved
FINAL

Page 19
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
dataset represents a single observation and each column represents one of the variables contained within the
dataset.
Since the V3.x data structures are essentially static, much of the information that may have been
communicated in columns in a more horizontal structure will now involve adding new records instead.
The model also includes variables that contain values that can be used to convert the dataset from the
'vertical' format to a 'horizontal' representation (or more 'denormalized'). Therefore, for some domains
there is a need to provide record-level metadata (referred to as value-level or hierarchical metadata).
For example, the Vital Signs data domain could contain subject records related to diastolic and systolic
blood pressure, height, weight, and body mass index (BMI). If these data were submitted in compliance
with the CDISC standards, it would be provided in the more normalized structure of one row per vital signs
measurement. This means that there could be five records per subject (one for each parameter), and the
parameter names would be stored in the Test Code/Name variables, and the parameter value in a result
variable. Since the unique Test Code/Names have different attributes (i.e., different origins, roles, and
definitions) there is a need to provide metadata for this information.
The hierarchical metadata could be provided as a separate section of the Define data definition document.
The table should be similar in structure to the CDISC Submission Metadata Model described previously.
This information, which historically has been submitted as a pdf document named 'Define.pdf' may also be
submitted in an XML format. For details on the CDISC specification for submitting the Define data
definition document in XML, see http://www.cdisc.org/models/sds/v3.1/index.html.

3.2.3

Conformance

Conformance with the CDISC Domain Models is indicated by:
•

Following the complete metadata structure for data domains and variables

•

Following CDISC domain models wherever applicable

•

Including all collected and relevant derived data in one of the standard domains, special-purpose
datasets or general-observation-class structures

•

Including all Required and Expected variables as columns in a domain

•

Using CDISC-specified standard domain names and prefixes

•

Using CDISC-specified standard variable names

•

Using CDISC-specified variable labels for all standard domains (as described in the SDTMIG)

•

Using CDISC-specified data types for all variables

•

Following CDISC-specified controlled terminology and format guidelines for variables, when
provided

•

Ensuring that each record in a dataset includes a set of keys and a topic variable

•

Conforming to all business rules described in the CDISC notes and general and domain-specific
assumptions.

When creating new domains, sponsors should always review the CDISC-standard labels from comparable
domains and adjust only if necessary to properly convey the meaning of the submitted data. Sponsors
should also supply the correct origins, roles (optional for standard domains), and appropriate comments,
plus any additional controlled terminology or format information required for the FDA reviewer to properly
interpret the data. Since most regulatory submissions involve data that has been collected over many years,
CDISC recognizes that full conformance with the SDS model may not be immediately achievable, but will
improve over time.

Page 20
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

4 Assumptions for Domain
Models
4.1

GENERAL ASSUMPTIONS FOR ALL DOMAINS

4.1.1

General Dataset Assumptions

4.1.1.1

Review the Study Data Tabulation Model as well as this Implementation Guide before
attempting to apply any of the individual domain models. The CDISC Submission Metadata
Model may also be reviewed for additional background information on how to represent
metadata for general datasets. See the Case Report Tabulation Data Definition Specification
(define.xml), available on the CDISC website, for information about an xml representation of
the data definition document.

4.1.1.2

Additional analysis variables should be added to analysis datasets if required by regulatory
reviewers or if necessary to accommodate the scientific requirements of the submission. These
should be named consistently with other variables in the model, described clearly, and presented
in a format that is consistent across a submission. Specific assumptions regarding data types
should also be applied. However, no new variables should be added to any tabulation dataset
except through the Supplemental Qualifiers mechanism described in Section 8.

4.1.1.3

Additional Timing variables from the general observation classes can be added as needed to a
standard domain model based on the three general observation classes.

4.1.1.4

The order of variables in the Define data definition document should reflect the order of data in
the dataset. The current order of variables in the CDISC domain models has been chosen to
facilitate the review of the models and application of the models. Sponsors may thus wish to
reorder timing and qualifier variables in order to place more emphasis on the most important
variables, but are encouraged to apply a consistent variable ordering scheme for all domains in a
submission wherever possible.

4.1.1.5

CDISC Core variables: In V3.0, CDISC identified all Core variables in domain models
(identified by a 'Y' in the 'Core' column). In V3.x, three categories of variables are specified in
the 'Core' column:
•

A Required variable is any variable that is basic to the identification and meaning of
a data record (i.e., essential key Identifiers and a Topic variable). Values cannot be
null.

•

An Expected variable is any variable necessary to make a record meaningful in the
context of a specific domain. In most cases, some but not all values for expected
variables may be null in a domain if unknown or not done. But when an expected
variable has not been collected, a null column should still be included and a comment
should be included in the define data definition document to state it was not collected.

•

A Permissible variable may be used as appropriate, when collected or derived.

CDISC, © 2005. All rights reserved
FINAL

Page 21
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
All timing variables are considered permissible.
Any qualifier variables from the same general class are permissible for that
domain.
Required and expected variables must be included in the dataset. Required variables cannot be
null, but the expected variables may contain some null values. In studies where limited data
collection has been agreed upon in advance with the agency, some expected variables might be
submitted with all null values. Normally the sponsor should only include those variables
designated as permissible that were collected or derived; however, the sponsor can choose
whether permissible variables that are always null should be included.
o
o

4.1.1.6

4.1.2
4.1.2.1

Additional guidance on dataset naming will be provided in future versions of the CDISC
SDTMIG.

General Variable Assumptions
Data variable names should be limited to 8 characters, and cannot start with a number, nor should
they contain characters other than letters, numbers, or underscores. This is a SAS V5 Transport file
limitation, and since use of SAS V5 is specified in the current guidance this limitation will be in
effect until the use of other formats (such as XML) becomes acceptable to regulatory authorities.
Data variable descriptive names (labels), up to 40 characters, should be provided as data variable
labels. This is a correction to the 32 characters noted as a limitation in the FDA guidance
document, Providing Regulatory Submissions in Electronic Format – NDAs (IT-3, January 1999).
Use of variable names (other than domain prefixes), formats, decodes, terminology, and data
types for the same type of data should be consistent within and across studies within a
submission. In general, sponsors should use the CDISC-standard labels in all standard domains.

4.1.2.2

In order to minimize the risk of difficulty when merging/joining domains for reporting purposes,
the two-character Domain Identifier is used as a prefix in most variable names.
The rule for applying the prefix is as follows: All variable names should be prefixed with the
Domain Identifier in which they reside except:
a.
b.
c.
d.

Required Identifiers (STUDYID, DOMAIN, USUBJID)
Commonly used Merge Keys (VISIT, VISITNUM, VISITDY, and many of the
variables in trial design such as ELEMENT and ARM)
All Demography domain (DM) variables with the exception of the DM-specific Timing
variables DMDTC, and DMDY
All variables in RELREC and SUPPQUAL.

Required Identifiers are not prefixed because they are usually used as keys when
merging/joining observations. The --SEQ and the optional Identifiers --GRPID and --REFID are
prefixed because they are only used as keys when relating observations in special cases.
4.1.2.3

'Subject' should be used where applicable to generically refer to both 'patients' and 'healthy
volunteers.' The term 'Subject' should be used consistently in all labels and comments.

4.1.2.4

It is recommended that textual data be submitted in upper case text. Exceptions may include
long text data (such as comment text), values of --TEST in Findings datasets (which may be
more readable in mixed case if used as labels in transposed views) and certain controlled

Page 22
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
terminology (such as MedDRA terms) that are already in mixed case. The Sponsor’s Define
data definition document may indicate as a general note or assumption whether case sensitivity
applies to text data for any or all variables in the dataset. If case sensitivity differs across
variables, it should be documented at the variable level in the Define document.
4.1.2.5

If a special convention is used for missing values (or values that were not collected for certain
records in a Tabulation), it should be described in the Define data definition document and
should be used consistently in all datasets.

4.1.2.6

Sponsors may assign categories (--CAT variable) and subcategories (--SCAT variable) within
domains. The categories and subcategories will provide additional context for the Topic
variable and should be used consistently across all records in the domain. For example, a lab
record with LBTEST = 'SODIUM' might have LBCAT = 'CHEMISTRY' and
LBSCAT = 'ELECTROLYTES'. The values for these variables may be collected on the CRF or
derived. --CAT and --SCAT values should not be redundant with the domain or dictionary
classification provided by --DECOD and --BODSYS. That is, they should provide a different
means of defining or classifying records. For example, a sponsor may be interested in
identifying all adverse events that the investigator feels might represent an infection, and thus
will collect that categorization on the CRF. This categorization might differ from the
categorization derived from the adverse-event coding dictionary.
The intended relationship among the records grouped using --GRPID (see Section 8.1 for
details) may appear to duplicate a relationship already identified by other variables such as
VISIT, --CAT, --SCAT, or --CLAS. These latter variables have meaning across subjects,
whereas the values of --GRPID apply to a specific domain and subject, and are intended solely
to facilitate grouping a set of records for a subject. For example, in the Laboratory Test Results
dataset, LBTEST values of HEMATOCRIT, HEMOGLOBIN, and RBC might be assigned a
value of HEMATOLOGY for LBCAT. LBCAT would be populated for all records falling into
that category across all subjects. However, for one subject, the investigator commented on these
specific records noting that the subject had a long history of anemia. For this subject, the three
hematology records would be assigned a common LBGRPID value. That value would be used
in the COMMENTS special-purpose domain to link the comment to the appropriate lab records.

4.1.2.7

4.1.3

Sponsors sometimes collect free text information on the CRF. When the CRF includes a list of
values including "Other, Specify", then the free text value should be placed in a SUPPQUAL
dataset as described in Section 8.4. For example, when a description of "Other Medically
Important Serious Adverse Events" category is collected on a CRF then the free text description
should be stored in the SUPPQUAL dataset.

Coding and Controlled Terminology Assumptions

4.1.3.1 The Submission Data Standards Team has defined two types of Controlled Terminology (CT). The
first consists of CT that has been published externally (e.g., MedDRA, LOINC or maintained by
CDISC in Appendix 10.4). The second consists of CT that is defined by a sponsor, and is used
consistently throughout a submission (e.g., a standard code list). Two asterisks (**) within the
Controlled Terms or Format column indicate the respective variable should be populated with
values from an external source. A single asterisk (*) within the Controlled Terms or Format column
indicates the respective variable should be populated with a value from a sponsor-controlled list.
The values that appear in the Controlled Terms or Format column are expected to be used in
submissions. CDISC will be providing future guidance on the use of controlled terminology in
separate documents available through the CDISC website. If applicable, additional information is
provided within this column for common alpha-codes, decodes, and references.
CDISC, © 2005. All rights reserved
FINAL

Page 23
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

4.1.3.2 It is recommended that controlled terminology be submitted in upper case text other than the two
exceptions noted below. Some sponsors may choose to submit controlled terminology in mixed
case text to enhance the appearance of reports. As noted in item 4.1.2.4 above, case sensitivity
should be described in the Define document.
a.
b.

If the external reference for the controlled terminology is not in upper case then the data
should conform to the case prescribed in the external reference (e.g., MedDRA and LOINC).
Units, which are considered symbols rather than abbreviated text (e.g., mg/dL).

4.1.3.3 The controlled terminology should be displayed for each applicable variable within the
'Controlled Terms or Format' column of the Define data definition document. Variables with
numerous controlled terms may be placed within an appendix section of Define.
4.1.3.4 Controlled terminology or text should be used instead of, or in addition to, arbitrary number
codes in order to reduce ambiguity for submission reviewers. For example, for concomitant
medications, the verbatim term and/or dictionary term should be presented, rather than numeric
codes. Separate coded values may be submitted as supplemental qualifiers or included in the
define data definition document and may be necessary in analysis datasets.
4.1.3.5 Controlled terminology for domain topic variables should be stored as follows:
•

•

For safety events such as AEs and Medical History, fill --DECOD with the dictionary’s
preferred term and fill --BODSYS with the preferred body system name. If a dictionary is
multi-axial, the value in --BODSYS should represent the primary path. When using
MedDRA, for example, --DECOD should contain the PT (Preferred Term), and
--BODSYS should contain the primary SOC (System Organ Class).
For concomitant medications, fill --DECOD with the drug's generic name, and fill --CLAS
with the drug class only if the dictionary used codes drugs to a single class. When using
WHODRUG, for example, --CLAS would not be filled since a drug may have multiple classes.

In either case, no other intermediate levels or relationships should be stored in the dataset. By
knowing the dictionary and version used, the reviewer will be able to obtain intermediate levels
in a hierarchy (as in MedDRA), or a drug’s ATC codes (as in WHO Drug). The sponsor may be
required to submit the dictionary if it is not already available to the reviewer.
4.1.3.6

The topic variable for many of the general domain models is often stored as verbatim text. For
an Event domain, the topic variable is --TERM. For an Interventions domain, the topic variable
is --TRT. For a Findings domain, the topic variable, --TESTCD, should use Controlled
Terminology (e.g., SYSBP for systolic blood pressure). If a CDISC-standard controlled
terminology exists it should be used, otherwise the sponsor should define its own controlled list
of terms. If the verbatim term is modified to facilitate coding, the modified text is stored in
--MODIFY. In most cases (other than PE), the dictionary coded text is derived into --DECOD.
Since the PEORRES variable is modified instead of the topic variable for PE, the dictionaryderived text would be placed in PESTRESC. The items used in each of the defined domains
are:
AE:
DS:
CM:
MH:
PE:

Page 24
August 26, 2005

AETERM/AEMODIFY/AEDECOD
DSTERM/DSDECOD
CMTRT/CMMODIFY/CMDECOD
MHTERM/MHMODIFY/MHDECOD
PEORRES/PEMODIFY/PESTRESC
CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

4.1.3.7

Variables where the response is 'Yes' or 'No' ('Y'/'N') should normally be populated for both 'Y'
and 'N' responses. This eliminates confusion regarding whether a blank response indicates 'N' or
is a missing value. However, some variables are collected or derived in a manner that allows
only one response, such as when a single check box indicates 'Yes'. In situations such as these,
where it is unambiguous to only populate the response of interest, it is permissible to only
populate one value ('Y' or 'N') and leave the alternate value blank. An example of when it would
be acceptable to use only a value of 'Y' would be for Baseline Flag (BLFL) variables, where 'N'
is not necessary to indicate that a value is not a baseline value.
Note: Permissible values for variables with controlled terms of 'Y' or 'N' may be extended to
include 'U' if it is the sponsor’s practice to explicitly collect or derive values indicating
'Unknown' for that variable.

4.1.4
4.1.4.1

Actual and Relative Time Assumptions
Date/Time formats for --DTC Variables: The CDISC SDS V2 models included date variables and
some separate time variables. In Version 3.0, to address the FDA’s request to provide a uniform
date/time representation, all date and time variables were replaced with a single date/time variable
ending in 'DTM'. These date and time values were stored as SAS date/times, which in SAS are
stored as the number of seconds since midnight on January 1, 1960. A SAS format was required to
display the date/times in human readable form. This was changed in version 3.1. Dates and time of
day are now stored according to the international standard ISO 8601
(ISO, URL: http://www.iso.ch/iso/en/ISOOnline.openerpage).
The SDTMIG template uses ISO 8601 for calendar dates and times of day, which are expressed
as follows:
YYYY-MM-DDThh:mm:ss
where:
[YYYY] = four-digit year
[MM] = two-digit representation of the month (01-12, 01=January, etc.)
[DD] = two-digit day of the month (01 through 31)
[T] = (time designator) indicates time information follows
[hh] = two digits of hour (00 through 23) (am/pm is NOT allowed)
[mm] = two digits of minute (00 through 59)
[ss] = two digits of second (00 through 59)
Other characters defined for use within the ISO 8601 standard are:
[-] (hyphen): to separate the time elements "year" and "month",
"month" and "day"
[:] (colon): to separate the time elements "hour" and "minute",
and "minute" and "second"
[/] (solidus): to separate components in the representation of time intervals
[P] (duration designator): precedes the components that represent the duration
Key aspects of the IS0 8601 standard are as follows:
•

ISO 8601 represents dates as a text string using the notation YYYY-MM-DD.

•

ISO 8601 represents times as a text string using the notation hh:mm:ss.

CDISC, © 2005. All rights reserved
FINAL

Page 25
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
•

ISO 8601 does not require dashes to separate date parts nor colons to separate time parts;
however, these are required for the SDTM and V3.x SDTMIG to improve readability.

•

When a date is stored with a time in the same variable (as a date-time), the date is
written in front of the time and the time is preceded with 'T' using the notation
YYYY-MM-DDT hh:mm:ss (e.g. 2001-12-26T00:00:01).

Implementation of the ISO standard means that nominal date/time variables are no longer
numeric data types but will now have to be character/text data types. The SDS fragment
employed for date/time variables is --DTC, where '--' is the two letter domain code [with or
without the ‘ST’ or ‘EN’ strings indicating start or stop dates].
4.1.4.2

Date/Time Precision. In V3.0, a separate date/time precision variable ending in 'DTP' was
paired with each date/time variable to address the FDA desire to easily detect any value that was
partially or fully imputed. This has been eliminated in V3.x. According to ISO 8601, precision
(also referred to by ISO 8601 as "completeness" or "representations with reduced accuracy"), is
specified by the number of parts present in the date, time, or date-time value. Whatever is
unknown is not included so if the date is completely missing then the date value should be null.
For example, if month is unknown, then only year is included in the value string. If day is
unknown, only year and month are included in the value string. If seconds are unknown, all
parts of the date-time string are included except the last two numbers representing seconds. If
day is known but month is unknown then neither day nor month is included in the date
representation. Furthermore, one-digit numbers are always padded with a leading zero. Hence,
the use of a separate precision variable, as defined in Version 3.0, is no longer required.
The table below provides examples of ISO 8601 representation complete date and truncated
date/time values using ISO 8601 "appropriate right truncations" of incomplete datetime
representations.

1
2
3
4
5
6

Date and Time as
Originally Recorded
December 15, 2003 13:14:17
December 15, 2003 13:14
December 15, 2003 13
December 15, 2003
December, 2003
2003

Interval of Uncertainty
Complete date and time
Unknown seconds
Unknown minutes
Unknown time
Unknown day
Unknown month

Nominal Date/Time (--DTC)
2003-12-15T13:14:17
2003-12-15T13:14
2003-12-15T13
2003-12-15
2003-12
2003

This date and date/time model provides for nonstandard intervals of uncertainty, such as those
commonly seen in Medical History. To represent these intervals while applying the ISO8601
standard, it is recommended that the sponsor concatenate the date/time values (using the most
complete representation of the date/time known) that describe the beginning and the end of the
intervals of uncertainty and separate them with a solidus as shown in the table below:
Interval of Uncertainty

Nominal Date/Time (--DTC)

Between 10:00 and 10:30 on the
Morning of December 15, 2003

2003-12-15T10:00/2003-12-15T10:30

After the first of this year (2003) until "now"
(February 15, 2003, noon)

2003-01-01/2003-02-15T12:00

Between the first and the tenth of December, 2003

2003-12-01/2003-12-10

Sometime in the first half of 2003

2003-01-01/2003-06-30

Page 26
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
Other uncertainty intervals may be represented by the omission of components of the date when
these components are unknown. Examples of this method of omitted component representation
are represented in the table below:
Date and Time as
Originally Recorded

Interval of Uncertainty

Nominal Date/Time
(--DTC)

December 15, 2003 13:15:17

Complete date and time

2003-12-15T13:15:17

December 15, 2003 __:15

Unknown hour with known minutes

2003-12-15T15T-:15

December 15, 2003 13:__:17

Unknown minutes with known date,
hours and seconds

2003-12-15T13:-:17

The 15th of some month in 2003

Unknown month and time with
known year and day

2003---15

December 15, but can't
remember the year

Unknown year with known month
and day

--12-15

Using a character-based data type to implement the ISO 8601 date/time standard will ensure that the
date/time information will be machine and human readable without the need for further manipulation,
and will be platform and software independent.
NOTE FOR BACKWARD COMPATIBILITY WITH SDS V. 3.0:
Because the --DT fragment was used in the SDS Version 2 standards, and the DTM fragment was
used to represent numeric based date/time values in Version 3, the “DTC” fragment has been used to
identify character-based date/time information in Version 3.1. This will allow sponsors to continue to
use the --DT and --DTM fragments for variables used in operational databases or analysis files.
The SAS format IS8601DT can be used to display SAS date/time information in the ISO 8601
format. Examples are shown below:
Date and time as
SAS Numeric
Formatted SAS
originally recorded
Date/Time (--DTM)1
Date/Time2
1 29June, 1956 11:32:09 -110636871
1956-06-29T11:32:09
2 29June, 1956 11:32:00 -110636880
1956-06-29T11:32:00
3 29June, 1956 11:00:00 -110638800
1956-06-29T11:00:00
4 29June, 1956 00:00:00 -110678400
1956-06-29T00:00:00
3
5 June1956
Not calculated
Not calculated3
1
DTM = input(DTC, datetime18.)
2
format of --DTM IS8601DT
3
SAS requires a full, valid date. Apply a standard convention to impute days.
4.1.4.3 Duration is frequently used during a review; however, the duration timing variable (--DUR) should
generally be used in a domain if it was collected in lieu of a start date/time (--STDTC) and end
date/time (--ENDTC). If both --STDTC and --ENDTC are collected, durations can be calculated by the
difference in these two values, and need not be in the submission dataset.
In V3.0, there were separate duration (--DUR) and duration unit (--DURU) variables. In V3.x, the
--DURU variable is eliminated, as both duration and duration units can be provided in the single
--DUR variable according to ISO 8601. The values provided in --DUR should follow one of the
following ISO 8601 formats:
PnYnMnDTnHnMnS
or
PnW
The letter "P" precedes other values in the duration format. The 'n' preceding each letter represents the
number of Years, Months, Days, Hours, Minutes, Seconds, or Weeks. As with the date/time format,
CDISC, © 2005. All rights reserved
FINAL

Page 27
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
'T' is used to separate the date and time components. Note, weeks cannot be mixed with days in
representations
When duration is being measured after an event, the correct usage when you know the start
date/time from which the duration is measured is:
YYYY-MM-DDThh:mm:ss/PnYnMnDTnHnMnS
For duration measured prior to an event (like 2 hours before last dose) the syntax is:
PnYnMnDTnHnMnS/YYYY-MM-DDThh:mm:ss
Note only the hyphen delimited extended format conforming to "Format with time-unit
designators" (ISO 5.5.4.2.1 - second edition 2000-12-15) is considered valid for SDTM use.
Usage Notes:
o

There should be no spaces in the representation.

The 'T' designator must always precede Time components, but is not necessary if
no time components are included.

Missing components can be omitted.

The table below provides some examples of ISO 8601 compliant durations:
Duration as originally recorded
2 Years
10 weeks
3 Months 14 days
3 Days
6 Months 17 Days 3 Hours
14 Days 7 Hours 57 Minutes
42 Minutes 18 Seconds
2 hours before a reference time point in RFTDTC

4.1.4.4

--DUR Value
P2Y
P10W
P3M14D
P3D
P6M17DT3H
P14DT7H57M
PT42M18S
-PT2H

The Study Day variable (--DY) describes the relative day of the observation starting with the
reference date as Day 1. It is determined by comparing the date portion of any DTC variable to
the date portion of the Subject Reference Date (RFSTDTC from the Demography domain). It is
considered a descriptive representation of a relative date within the study.
The subject reference date is designated as Study Day 1. The Study Day value is incremented by 1 for
each date following RFSTDTC. Dates prior to RFSTDTC are decremented by 1, with the date preceding
RFSTDTC designated as Study Day -1 (there is no Study Day 0). This algorithm for determining Study
Day is consistent with how people typically describe sequential days relative to a fixed reference point,
but creates problems if used for mathematical calculations because it does not allow for a Day 0. As such,
Study Day is not suited for use in subsequent numerical computations, such as calculating duration. The
raw date values should be used rather than Study Day in those calculations.
All Study Day values are integers. Thus, to calculate Study Day:
--DY = (date portion of --DTC) - (date portion of RFSTDTC) + 1 if --DTC is on or after RFSTDTC
--DY = (date portion of --DTC) - (date portion of RFSTDTC) if --DTC precedes RFSTDTC
The algorithm for this calculation should be consistent across all domains.

4.1.4.5 Clinical encounters are described by the CDISC Visit variables. VISITNUM indicates the
clinical encounter number, a numeric version of VISIT used for sorting. VISITDY indicates the
planned study day of VISIT. A text description of the visit (VISIT) is recommended for
intelligibility and consistency with the protocol and CRF.
Page 28
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

VISITNUM is required when data are collected more than once per subject or at a discrete time
point (e.g., Labs, ECG, Vital Signs or other domains with multiple assessment points).
VISITNUM is not included in Subject Characteristics because the data in this domain is
collected only once per subject. It is permissible in Disposition if more than one disposition
event is collected per subject. VISITNUM is not required in Adverse Events, Concomitant
Medication, or Medical History.
VISIT and VISITDY are permissible, but not required when VISITNUM is used. The following
table shows an example of how the visit identifiers might be used:
USUBJID
001
001
001

VISIT
Week 1
Week 2
Week 2
Unscheduled

VISITNUM
2
3

VISITDY
7
14

--DY
7
13

3.1

(Null)

4.1.4.6

The calculation of study days within subdivisions of time in a clinical trial may be based on one or
more sponsor-defined reference dates not adequately represented by RFSTDTC. The Sponsor’s
Define data definition document should reflect the reference dates used to calculate such study days.
CDISC will define an appropriate model for representing such sponsor-defined dates in a future
version of this document.

4.1.4.7

The CDISC V2/V3 domain models included the timing variables --ONGO and --PRIOR, but the
meaning of these variables was found to differ dramatically among different sponsors, and even
across different trials for the same sponsor. For example, AEONGO often meant an event was
ongoing as of the end of a study, while MHONGO meant a condition was ongoing at the beginning
of the study. The meaning of these variables was further confused because it was not always
apparent as to which time point to use to define the beginning or end of a study. To clarify this, V3.1
of the SDTMIG defined two new timing variables, --STRF, Start Relative to Reference Period, and -ENRF, End Relative to Reference Period.
--STRF identifies the start of an observation (Event, Intervention, or Finding) as being 'BEFORE',
'DURING', or 'AFTER' the sponsor-defined reference period. The sponsor-defined reference period is
a continuous period of time defined by a discrete starting point (RFSTDTC) and a discrete ending
point (RFENDTC). --STRF should be populated for observations with information such as check
boxes on the CRF (e.g., 'PRIOR', 'ONGOING', or 'CONTINUING') that indicates when they occur in
reference to the study timeline. --STRF should be set to ‘U’ if its value is unknown.
--ENRF identifies the end of the observation (Event, Intervention, or Finding) as being
'BEFORE', 'DURING', ‘DURING/AFTER' or 'AFTER' the sponsor-defined reference period.
The sponsor-defined reference period is a continuous period of time defined by a discrete
starting point (RFSTDTC) and a discrete ending point (RFENDTC). --ENRF should be
populated for observations with information such as check boxes on the CRF (e.g. 'PRIOR',
'ONGOING', or 'CONTINUING') that indicate when they occur in reference to the study
timeline. --ENRF should be set to ‘U’ if its value is unknown.
Figure 4.1.4.7 below illustrates how to populate these variables in a CM domain. For both
variables, sponsors should define the reference period in the study metadata.

CDISC, © 2005. All rights reserved
FINAL

Page 29
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Figure 4.1.4.7 Example of CMSTRF and CMENRF Variables

4.1.4.8

When the date and time of collection is reported in a domain based on the Findings general class, the
date should go into the --DTC field -- e.g., EGDTC (Date/Time of ECG). When an interval (start
and end) date/time is reported, the start date and time goes into --DTC and the end date and time
goes into --ENDTC. For example, in the LB domain the LBDTC date variable is used for all single
point collections or spot urine collections. For timed lab collections (e.g., 24 hour urine collections)
the LBDTC variable is used for the start date/time of the collection and LBENDTC for the end
date/time of the collection. This approach will allow the single point and interval collections to use
the same date/time variables consistently across all datasets for the findings general class. The
table below illustrates the proper use of these variables. Note --STDTC is not used for collection
dates, so is blank in the following table.
Date Collected
Interval Collected

--DTC
X
X

--STDTC

--ENDTC
X

4.1.4.9

Dates are generally used only as timing variables to describe the timing of an event, intervention or
collection activity, but there may be occasions when it may be preferable to model a date as a result in
a Findings dataset. Note that using a date as a result to a findings question is unusual and atypical, and
should be approached with caution, but this situation may occasionally occur when a) a group of
questions (each of which has a date response) is asked and analyzed together; or b) the event(s) and
intervention(s) in question are not medically significant (often the case when included in
questionnaires). Consider the following cases:
Calculated due date?
Date of last day on the job?
Date of birth of youngest child?
End date of last reporting period?

Page 30
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
One approach to modeling these data would be to place the text of the question in --TEST and the
response to the question, a date represented in ISO 8601 format, in --ORRES and --STRESC as long
as these date results do not contain the dates of medically significant events or interventions.
Again, use extreme caution when storing dates as the results of findings. Remember, in most cases, these
dates should be timing variables associated with a record in an Intervention or Events dataset.

4.1.5
4.1.5.1

Other Assumptions
Original and Standardized Results of Findings
The --ORRES variable contains the result of the measurement or finding as originally received or collected.
--ORRES is an expected variable, and should always be populated with two exceptions:
•
•

When --STAT = 'NOT DONE'
When a record is derived (e.g., to represent an average or sum of collected values), in
such a way as to make it impossible to meaningfully populate --ORRES.

Derived records are flagged with the --DRVFL variable. When the derived record comes from more than
one visit, the sponsor must define the value for VISITNUM, addressing the correct temporal sequence.
When --ORRES is populated, --STRESC must also be populated, regardless of whether the data values are
character or numeric.--STRESC is derived either by the conversion of values in --ORRES to values with
standard units, or by the assignment of the value of --ORRES (as in the PE Domain, where --STRESC could
contain a dictionary-derived term). A further step is necessary when --STRESC contains numeric values.
These are converted to numeric type and written to --STRESN. Because --STRESC may contain a mixture
of numeric and character values, --STRESN may contain null values, as shown in the flowchart below.
ORRES
(all original values)

STRESC
(derive or copy all results)

STRESN
(copy numeric results only)

When the original measurement or finding is a selection from a defined code list, the --ORRES
or --STRESC variables should contain results in decoded format, that is, the textual
interpretation of whichever code was selected from the code list.
Occasionally data that are intended to be numeric are collected with characters attached that cause the
character-to-numeric conversion to fail. For example, numeric cell counts in the source data may be
specified with a greater than (>) or less than (<) sign attached (e.g. >10,000 or <1). In order for these values
to be reported as numeric in --STRESN, and assuming this is desirable, the sponsor must apply a rule to
derive a numeric value for these strings and document this in the value-level metadata. For example the rule
may be to remove the character symbol or to compensate for the symbol in some other way, such as adding
to values using > or subtracting from values using <.
Tests Not Done
When an entire examination (Laboratory draw, ECG, Vital Signs or Physical Examination), or a group of
tests (hematology or urinalysis), or an individual test (glucose, PR interval, blood pressure, or hearing) is
not done, and this information is explicitly captured with a yes/no or done/not done question on the CRF,
a record could be created in the dataset to record this information. See the examples below.
If the data on the CRF is missing and yes/no or done/not done was not explicitly captured a
record should not be created to indicate that the data was not collected.
If a group of tests were not done
•
•
•
•
•

--TESTCD should be --ALL
--TEST should be
--CAT should be
--ORRES should be NULL
--STAT should be "NOT DONE"

CDISC, © 2005. All rights reserved
FINAL

Page 31
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

For example, if urinalysis is not done then
•
•
•
•
•

LBTESTCD should be "LBALL"
LBTEST should be "LAB"
LBCAT should be "URINALYSIS"
LBORRES should be NULL
LBSTAT should be "NOT DONE”.

Laboratory Examples:
• Numeric values that have been converted or copied (Rows 1 & 3).
• A character result that has been copied (Row 2).
• A result of 'TRACE' converted to a numeric value of 1 (Row 4).
• Value of 1+ converted to numeric 1 (Row 5).
• A result of 'BLQ' converted to a numeric value of zero (Row 6).
• Some original character results in LBORRES such as '<10,000', which are converted to
numeric results per sponsor-defined algorithms (Row 7).
• A result is missing because the observation was 'NOT DONE', as reflected in the
--STAT variable; neither LBORRES nor LBSTRESC are populated (Row 8).
• A result is derived from multiple records such as an average of baseline measurements
for a baseline value (Row 9).
• None of the scheduled tests were completed as planned (Row 10)
• A group of tests were not completed as planned (Row 11)
Row
1
2
3
4
5
6
7

LBTESTCD
GLUCOSE
UBAC
SGPT
URBC
UWBC
KETONE
WBC

8
9
10
11

HCT
MCHC
LBALL
LBALL

LBSTAT

LBCAT

LBORRES
6.0
MODERATE
12.1
TRACE
1+
BLQ
<10,000

LBORRESU
mg/dL
mg/L

LBSTRESC LBSTRESN LBSTRESU LBDRVFL
60.0
60.0
mg/L
MODERATE
12.1
12.1
mg/L
1
1
1
1
0
0
[sponsor[sponsordefined value] defined value]

NOT DONE
33.8

33.8

g/dL

NOT DONE
NOT DONE HEMATOLOGY

ECG Examples:
• Numeric and character values that have converted or copied (Rows 1, 2, and 3).
• A result is missing because the test was 'NOT DONE', as reflected in the EGSTAT
variable; neither EGORRES nor EGSTRESC are populated (Row 4).
• The overall interpretation is included as a new record (Row 5)
• The entire ECG was not done (Row 6)
Row
1
2
3
4
5

EGTESTCD
QRS
QT
RHYMRATE
PR
INTP

EGALL

Page 32
August 26, 2005

EGSTAT

EGORRES
362
221
ATRIAL FLUTTER

EGORRESU
SEC
MSEC

EGSTRESC
362
.221
ATRIAL FLUTTER

EGSTRESN
362
.221

EGSTRESU
SEC
SEC

NOT DONE
ABNORMAL,
CLINICALLY
SIGNIFICANT

ABNORMAL,
CLINICALLY
SIGNIFICANT

NOT DONE

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)
Vital Signs Examples:
• Numeric and character values that have converted or copied (Rows 1 and 2).
• A result is missing because the Vital Signs test was 'NOT DONE', as reflected in the
VSSTAT variable; neither VSORRES nor VSSTRESC are populated (Row 3).
• The result is derived by having multiple records for one measurement and the derived
value is recorded in a new row with the derived record flagged. (Rows 4, 5, and 6).
• The entire examination was not done (Row 7)
Row
1
2
3
4
5
6
7

VSTESTCD

HT
WT
HR
SYSBP
SYSBP
SYSBP
VSALL

VSSTAT

VSORRES

VSSTRESC

VSSTRESN

VSSTRESU

60
110

VSORRESU

IN
LB

152
50

cm
kg

96
100

mmHg
mmHg

96
100
98

mmHg
mmHg
mmHg

VSDRVFL

NOT DONE
Y

NOT DONE

Questionnaire Examples:
• Character values that have converted to standard scores (Row1).
• A result is derived from multiple records (Row 2)
• A result is missing because the observation was 'NOT DONE', as reflected in the
QSSTAT variable; neither QSORRES nor QSSTRESC are populated (Row 3).
• The entire questionnaire was not done (Row 4)
Row
1
2
3
4

QSTEST

HEALTH
HEALTH
PERCEPTIONS (0-100)
HEALTH
QSALL

QSSTAT

QSORRES

VERY GOOD

QSSTRESC

QSSTRESN

4.4

4.4
82

QSDRVFL

NOT DONE
NOT DONE

4.1.5.2 Multiple observations may be linked (associated with each other) using the RELREC dataset
described in Section 8 of this document. Comments should be stored in the Comments domain
(CO). Additional Qualifier variables that were not specified in the model should be included in
the Supplemental Qualifiers (SUPPQUAL) dataset.
4.1.5.3 CDISC realizes that some sponsors may have text strings longer than 200 characters for some variables.
Because of the current requirement for Version 5 SAS transport file format, it will not be possible to
store those long text strings using only one variable. Therefore, CDISC has defined a convention for
storing a long text string by using a combination of the standard domain dataset and the Supplemental
Qualifiers (SUPPQUAL) dataset. For a text string of more than 200 characters in length, the first 200
characters of text should be stored in the standard domain variable and each additional 200 characters of
text should be stored as a record in the SUPPQUAL dataset. In this dataset, the value for QNAM should
contain a sequential variable name, which is formed by appending a one-digit integer, beginning with 1,
to the original standard domain variable name. When splitting a text string into several records, the text
should be split between words to improve readability.
As an example, if a sponsor had text for Medical History Reported Term (MHTERM) for one subject of 500
characters in length, the sponsor would put the first 200 characters of text in the standard domain variable and
dataset (MHTERM in MH), the next 200 characters of text as a first supplemental record in the SUPPQUAL
dataset, and the final 100 characters of text as a second record in the SUPPQUAL dataset. Variable QNAM
would have the values MHTERM1 and MHTERM2 for the first and second records in SUPPQUAL,
respectively, for this one particular text string. Sponsors should place the text itself into variable QVAL and
the label of the original standard domain variable into variable QLABEL. In this case, IDVAR and
IDVARVAL should be used in SUPPQUAL to relate the associated supplemental text records to the first 200
characters of text in the standard domain.
CDISC, © 2005. All rights reserved
FINAL

Page 33
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
In cases where the standard domain variable name is already 8 characters in length, sponsors should replace
the last character with a digit when creating values for QNAM. As an example, for Other Action Taken in
Adverse Events (AEACNOTH), values for QNAM for the SUPPQUAL records would have the values
AEACNOT1, AEACNOT2, and so on.
Examples of how SUPPQUAL would be populated are presented below:
STUDYID RDOMAIN USUBJID

IDVAR IDVARVAL

QNAM

12345

99-123

MHSEQ

MHTERM1

12345

99-123

MHSEQ

MHTERM2

12345

99-123

AESEQ

AEACNOT1

QLABEL

QVAL

QORIG QEVAL

Reported Term
2nd 200
for Condition or chars of text
Procedure
Reported Term
last 200
for Condition or chars of text
Procedure
Other Action
Taken

last 200
chars of text

CRF
CRF

CRF

4.1.5.4 For the Interventions and Events observation classes, all data are assumed to be attributed to the
Principal Investigator, or derived from such data by the sponsor. The observations recorded in
the Findings class include the --EVAL qualifier because the observation may originate from more
than one source (e.g., an Investigator or Central Reviewer). The QEVAL variable can be used to
describe the evaluator for any data item in SUPPQUAL, but is not required when the data is
objective. For all observations that have a primary and supplemental evaluation, sponsors should
always put data from the primary evaluation into the standard domain dataset and data from the
supplemental evaluation into the Supplemental Qualifiers dataset (SUPPQUAL – see
Section 8.4). In SUPPQUAL, each variable for the evaluation should be represented as a record.
Within each record, the value for QNAM should be formed by appending a “1” to the
corresponding standard domain variable name. In cases where the standard domain variable
name is already 8 characters in length, sponsors should replace the last character with a “1”
(incremented for each additional attribution). The result of, response to, or value associated with
QNAM should be placed in variable QVAL. The label of the corresponding standard domain
variable should be placed in variable QLABEL. As an example, if an adjudication committee
evaluates an adverse event, data in SUPPQUAL for this evaluation would look as below.
(Note that QNAM takes on the value AERELNS1, as the corresponding standard domain variable
AERELNST is already 8 characters in length.) The adverse event data as determined by the
primary investigator would reside in the standard AE dataset.
STUDYID RDOMAIN USUBJID IDVAR IDVARVAL

QNAM

QLABEL

QVAL

QORIG

QEVAL

12345

99-123

AESEQ

AESEV1

Severity/
Intensity

MILD

CRF

ADJUDICATION
COMMITTEE

12345

99-123

AESEQ

AEREL1

Causality

POSSIBLY
RELATED

CRF

ADJUDICATION
COMMITTEE

12345

99-123

AESEQ

Possibly
related to
aspirin use.

CRF

ADJUDICATION
COMMITTEE

Page 34
August 26, 2005

AERELNS1 Relationship
to Non-Study
Treatment

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

5 Models for Special Purpose Domains
5.1.1

Demographics Domain Model — DM

dm.xpt, Demographics — Version 3.1.1, August 26, 2005. One record per subject, Tabulation
Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char **DM

CRF
Derived

USUBJID

Unique Subject Identifier

Char

Sponsor
Defined

SUBJID

Subject Identifier for the
Study
Subject Reference Start
Date/Time

Char

CRF

Char ISO 8601

Sponsor
Defined

RFENDTC

Subject Reference End
Date/Time

Char ISO 8601

Sponsor
Defined

SITEID

Study Site Identifier

Char

INVID

Investigator Identifier

Char *

CRF or
Derived
CRF or
Derived

INVNAM

Investigator Name

Char

BRTHDTC

Date/Time of Birth

Char ISO 8601

RFSTDTC

CDISC, © 2005. All rights reserved
FINAL

Role

CDISC Notes

Core

References
SDTM 2.2.4
SDTM 2.2.4

CRF or
Derived

Identifier Unique identifier for a study within the submission.
Req
Identifier Two-character abbreviation for the domain most relevant to the
Req
observation.
Identifier Unique subject identifier within the submission. This can be a
Req
unique number or a compound identifier formed by concatenating
STUDYID-SITEID-SUBJID. Since a subject may participate in
more than one study (as in a follow-on), the USUBJID may differ
from the SUBJID in some cases.
Topic
Subject identifier used within the study. Often the ID of the subject Req
as recorded on a CRF.
Timing
Reference Start Date/time for the subject in ISO 8601 character
Exp
format. Usually equivalent to date/time of first intake of drug.
Required for all randomized subjects; null for screen failures (if
screen failures are submitted).
Timing
Reference End Date/time for the subject in ISO 8601 character
Exp
format. Usually equivalent to the date/time when subject was
determined to have ended the trial, and often equivalent to date/time
of last intake of drug. Required for all randomized subjects; null
for screen failures (if screen failures are submitted).
Record
Unique identifier for a study site within a submission.
Req
Qualifier
Record
An identifier to describe the Investigator for the study. May be
Perm
Qualifier used in addition to the SITEID. Not needed if SITEID is equivalent
to INVID.
Synonym Name of the investigator for a site.
Perm
Qualifier

CRF or
Derived

Result
Date/time of birth of the subject.
Qualifier

SDTMIG
4.1.4.1

Perm

SDTM 2.2.4

SDTMIG
4.1.4.1
SDTMIG
4.1.4.1

Page 35
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

AGE

Age in AGEU at RFSTDTC Num

AGEU

Age Units

SEX

Controlled
Terms or
Format

Origin
CRF or
Derived

Role

CDISC Notes

Core

References

Result
Usually derived as (RFSTDTC -BRTHDTC), but BRTHDTC may Exp
Qualifier not be available in all cases (due to subject privacy concerns).
Variable
Qualifier

Exp

Sex

Char ** YEARS,
CRF or
MONTHS,
Derived
DAYS, HOURS,
WEEKS
Char **M, F, U
CRF

Result
M, F, U for Male, Female, Unknown
Qualifier

Req

RACE

Race

Char **

CRF

ETHNIC

Ethnicity

Char **

CRF

ARMCD

Planned Arm Code

Char *

CRF or
Derived

Result
Race of the subject. In cases of mixed race, primary race should be Exp
Qualifier listed. If additional race values are collected, they should be
represented as separate records in the Subject Characteristics
domain with TESTCD of ‘RACEOTH’. The variable itself is
required by FDA, but with ongoing discussions in Europe about the
permissibility of collecting this data, the variable may be optional in
future.
Result
Ethnicity of subject.
Perm
Qualifier
Result
Short version of ARM, used for sorting and programming
Req
Qualifier (Formerly TRTCD).

ARM

Description of Planned Arm Char *

CRF or
Derived

Synonym Name given to the arm the subject was assigned to (Formerly
Qualifier TRTGRP).

COUNTRY

Country

Char **ISO 3166 3char. code

CRF or
Derived

Result
Country of the investigational site in which the subject participated Req
Qualifier in the trial.

DMDTC

Date/Time of Collection

Char ISO 8601

CRF or
Derived

Timing

Use if collected.

Perm

SDTMIG
4.1.4.1

DMDY

Study Day of Collection

Num

Derived

Timing

1. Study day of collection of the demographic information,
measured as integer days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics.
This formula should be consistent across the submission.

Perm

SDTMIG
4.1.4.4

Req

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.

Page 36
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

5.1.1.1
Assumptions for Demographics (DM) domain model
1. Investigator (INVID) and/or site (SITEID) identification: Companies use different methods to distinguish sites and/or investigators. CDISC assumes that
site will always be present, with investigator used as necessary to group data. This should be done consistently for the submission and the meaning of
the variable made clear in the Define data definition document. Investigator name (INVNAM) may also be included as a support variable.
2.

Subject identification: It is presumed that every subject in a study will have a subject identifier (SUBJID) and that in some cases a subject may be
included in more than one study within a submission. To identify a subject uniquely across a submission, a unique identifier (USUBJID) should be
assigned and included in all datasets within the submission.

Recent ongoing discussions regarding subject privacy suggest that care must be taken with regard to the collection of variables like BRTHDTC. This
variable is included in the Demographics model as an example of a variable that might be included in a submission; however, sponsors should follow
regulatory guidelines and guidance as appropriate.

Arm/Treatment identification: Note that in Version 3.x the variables ARM and ARMCD have replaced TRTGRP and TRTCD for consistency with the
trial design, and to more clearly distinguish the planned arm from the actual treatment. When a sponsor is submitting trial design information, the
values of ARM and ARMCD should be identical to the values defined for that subject in the Subject Elements (SE) dataset. The assignment of values
should be consistent, if possible, within a submission.

Justification for using SEX vs. GENDER: Page 71 of 'Providing Regulatory Submissions in Electronic Format - NDAs' (IT-3, January, 1999), available
at http://www.fda.gov/cder/guidance/2353fnl.pdf specifically lists SEX as part of demographic data. Similarly, page 60 of 'Guidance for Industry,
Providing Regulatory Submissions to the Center for Biologics Evaluation in Electronic Format - Biologics Marketing Applications' (November, 1999),
available at http://www.fda.gov/cber/guidelines.htm specifically lists SEX as part of demographic data. SEX is used consistently in both documents
except for one instance where GENDER is used (page 30 for Table 6 which may have been from another writer). 'ICH E3: Structure and Content of
Clinical Study Reports' (November 30, 1999) only uses SEX (not GENDER).

Attributions used to classify study populations for review and analysis, such as the COMPLT, SAFETY, ITT and PPROT variables discussed in the V3
DM domain, should be placed in the ‘suppdm.xpt” SUPPQUAL dataset as described in Section 8.4.

When additional free text information is reported about subject's RACE using 'Other, Specify', sponsors should place the free text value in the Subject
Characteristics (SC) dataset with TESTCD of ‘RACEOTH’ as described in the CDISC note for RACE.

Data for screen failure subjects, if submitted, should be included in the Demographics dataset, with ARMCD = “SCRNFAIL" and
ARM = “Screen Failure” to distinguish screen failures from randomized subjects. Sponsors may include a record in the Disposition dataset indicating
when the screen dropout event occurred. See section "9.3.2 DS Examples" for examples of screen dropout records.

CDISC, © 2005. All rights reserved
FINAL

Page 37
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

5.1.2

Comments Domain Model — CO

The COMMENTS special-purpose domain is a fixed domain that provides a solution for submitting free-text comments related to data in one or more SDS
domains or collected on a separate CRF page dedicated to comments. Comments are generally not responses to specific questions; instead, comments usually
consist of voluntary, free-text, unsolicited observations. COMMENTS has a structure that is similar to the Supplemental Qualifiers (SUPPQUAL) specialpurpose dataset but it allows for one comment to span multiple variables (COVAL-COVALn) in order to accommodate comments longer than 200 characters.1
Comments may be related to a Subject or to specific parent records in an SDTM domain. The approach for relating comments is described in Section 8.5.
co.xpt -- Version 3.1.1. August 26, 2005. One record per comment per subject, Tabulation
Variable
Name

Variable Label

STUDYID Study Identifier
DOMAIN Domain Abbreviation
RDOMAIN Related Domain
Abbreviation

Controlled
Terms or
Format

Type
Char
Char
Char

USUBJID

Unique Subject Identifier Char

COSEQ

Sequence Number

Num

IDVAR

Identifying Variable

Char

**CO
**

IDVARVAL Identifying Variable Value Char

Origin

Role

CDISC Notes

Core

References

CRF
Derived
Derived

Identifier Unique identifier for a study within the submission.
Req
Identifier Two-character abbreviation for the domain most relevant to the observation. Req
Identifier Domain abbreviation of the parent record(s). Null for comments collected on a Exp
general comments or additional information CRF page.

SDTM 2.2.4
SDTM 2.2.4

Sponsor
Defined
CRF or
Derived

Identifier Unique subject identifier within the submission.

SDTM 2.2.4

Derived

Identifier Identifying variable in the dataset that identifies the related record(s).
Perm
Examples --SEQ, or --GRPID. Null for comments collected on separate CRFs.

Derived

Identifier Value of identifying variable of the parent record(s). Used only when
Perm
individual comments are related to domain records. Null for comments
collected on separate CRFs
Record
CRF page of parent record(s) to which the comment refers, or on which the
Perm
Qualifier comment was collected. COREF may be the page number, e.g. 650, or the page
name e.g. DEMOG, or a combination of information that uniquely identifies
the reference both e.g. 650-VITALS- VISIT 2.
Timing
Perm
Result
The text of the comment. COVAL cannot be null – a value is required for the Req
Qualifier record to be valid. The first 200 characters of the comment will be in COVAL,
then next 200 in COVAL1, and continuing as needed to COVALn.

COREF

Comment Reference

Char

CRF

CODTC
COVAL

Date/Time of Comment
Comment

Char
Char

ISO 8601

CRF
CRF

COEVAL

Evaluator

Char

CRF or
Derived

Req

Identifier Sequence Number given to ensure uniqueness within a domain. Can be used to Req
join related records

SDTMIG 4.1.4.1

Record
Used to describe the originator of the comment. Controlled terminology will Perm
Qualifier consist of values such as ADJUDICATION COMMITTEE, STATISTICIAN,
DATABASE ADMINISTRATOR, CLINICAL COORDINATOR, and
PRINCIPAL INVESTIGATOR.

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
1

Allowing for multiple variables per comment is an interim solution until the limitations posed by SAS® Version 5 transport files are eliminated.

Page 38
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

5.1.2.1

Assumptions for Comments (CO) domain model

The COMMENTS dataset accommodates two sources of comments: 1) those collected alongside other data on topical CRF pages such as Adverse
Events; and 2) those collected on a separate page specifically dedicated to comments. The value of the variable RDOMAIN for comments of the first
type should be the domain code of the parent record(s). The value of the variable RDOMAIN of the second type should be null. Assumptions for the use
of GRPID and SEQ as values for IDVAR are the same as for the Supplemental Qualifiers (SUPPQUAL) special purpose dataset described in Section 8,
except that when there is no parent record (i.e., for comments collected on a dedicated comments CRF) IDVAR and IDVARVAL should be NULL.
COMMENTS records without a parent record (i.e. those collected on a dedicated Comments CRF) should have CODTC filled if it is collected on the
CRF. COMMENTS records with a parent record inherit timing variables from the parent, thus CODTC is NULL in COMMENTS. The variable
COREF may be NULL unless it is used to identify the source of the comment.

Example of use of COMMENTS special-purpose dataset --Subject with four comments: One comment collected on each of the AE, EX, and VS pages,
and another collected on a separate Comments CRF
1) Columns 3 and 6 (RDOMAIN and IDVAR) represent information from the parent record, if applicable.
2) Row 4 contains general comments from the Comments CRF Page. There is no parent record for this comment, thus DOMAIN has the value CO
and RDOMAIN, IDVAR and IDVARVAL are NULL.
3) Row 1 contains a comment text > 400 characters; Rows 2 and 3 contains text between 200 and 400 characters, Row 4 contains 150 characters of
comment text.
ROW

STUDYID

DOMAIN

RDOMAIN

USUBJID

COSEQ

IDVAR

IDVARVAL

COREF

COVAL

COVAL1

COVAL2

COEVAL

1234

AB-99

AESEQ

650

First 200
characters

Next 200
characters

More
Text

PRINCIPAL
INVESTIGATOR

1234

AB-99

EXGRPID

320-355

First 200
characters

Next 200
characters

PRINCIPAL
INVESTIGATOR

1234

AB-99

VSGRPID

First 200
characters

More text

PRINCIPAL
INVESTIGATOR

1234

AB-99

CDISC, © 2005. All rights reserved
FINAL

800

Total 150
characters

PRINCIPAL
INVESTIGATOR

Page 39
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6 Domain Models Based on the General
Classes
6.1

INTERVENTIONS

6.1.1

Concomitant Medications — CM

cm.xpt, Concomitant Medications — Interventions, Version 3.1.1, August 26, 2005. One record per medication intervention episode per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

CMSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant to Req
the observation.

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a
dataset for a subject. Can be used to join related records.

Req

SDTM 2.2.4

CMGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single
domain to support relationships within the domain and
between domains.

Perm

SDTMIG 2.1;
SDTM 2.2.4

CMSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Optional sponsor-defined reference number. Perhaps pre- Perm
printed on the CRF as an explicit line identifier or defined
in the sponsor’s operational database. Example: line
number on a concomitant medication page.

Page 40
August 26, 2005

**CM

CDISC, © 2005. All rights reserved
FINAL

SDTM 2.2.4

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

CMTRT

Reported Name of Drug,
Med, or Therapy

Char

CRF

Topic

Verbatim medication name that is either pre-printed or
collected on a CRF.

CMMODIFY

Modified Reported Name

Char

CMDECOD

Standardized Medication
Name

Char

Sponsor
Defined
Derived

Synonym
Qualifier
Synonym
Qualifier

CMCAT

Category for Medication

Char

Sponsor
Defined

Grouping
Qualifier

CMSCAT

Subcategory for Medication Char

Sponsor
Defined

Grouping
Qualifier

If CMTRT is modified, then CMMODIFY will contain the Perm
modified text.
Standardized or dictionary-derived text description of
Perm
CMTRT or CMMODIFY. Equivalent to the generic
medication name in WHO Drug. The sponsor should
specify the dictionary name and version in the Sponsor
Comments column of the Define document. If an
intervention term does not have a decode value in the
dictionary then CMDECOD will be left blank.
Used to define a category of medications/treatments.
Perm
Examples: ANTI-CANCER MEDICATION, or GENERAL
CONMED.
A further categorization of medications/ treatment.
Perm
Examples: CHEMOTHERAPY, RADIOTHERAPY,
HORMONAL THERAPY, ALTERNATIVE THERAPY.

CMOCCUR

CM Occurrence

Char

**Y, N or
Null

CRF or
Sponsor
Defined

Record
Qualifier

Used when the use of specific medications is solicited To Perm
indicate whether a medication was taken or not. Values are
null for spontaneously reported medications.
Note: Use of this variable is under evaluation by the SDS
Team.

CMSTAT

Concomitant Medication
Status

Char

**NOT
DONE

CRF or
Sponsor
Defined

Record
Qualifier

The status indicates that the question was not asked.

CMREASND

Reason Medication Not
Collected

Char

CRF

Record
Qualifier

CMINDC

Indication

Char

CRF or
Derived

Record
Qualifier

Describes the reason concomitant medication was not
Perm
collected. Used in conjunction with CMSTAT when value
is NOT DONE.
Denotes why a medication was taken or administered.
Perm
Examples: NAUSEA, HYPERTENSION.

CMCLAS

Medication Class

Char

Derived

Variable
Qualifier

CDISC, © 2005. All rights reserved
FINAL

References

Req

SDTMIG
4.1.3.6
SDTMIG
4.1.3.5
SDTMIG
4.1.3.5

SDTMIG 2.1
SDTMIG 2.1

Perm

Use only when the dictionary used codes to a single class. If Perm
using a dictionary that allows links to multiple classes, then
omit CMCLAS from the dataset. For example, sponsors
who use WHO Drug, which allows links from a medication
to multiple ATC codes, would not include CMCLAS.

Page 41
August 26, 2005

SDTMIG
4.1.5.1.

SDTMIG
4.1.3.5

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

CMCLASCD

Medication Class Code

Char

CMDOSE

Dose per Administration

CMDOSTXT

Controlled
Terms or
Format

Role

CDISC Notes

Core

References

Derived

Variable
Qualifier

Use only when the dictionary used codes to a single class.

Perm

Num

CRF or
Sponsor
Defined

Record
Qualifier

Amount of CMTRT taken.

Perm

Dose Description

Char

CRF or
Derived

Record
Qualifier

Dosing amounts or a range of dosing information collected Perm
in text form. Example: 200-400.

CMDOSU

Dose Units

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Units for CMDOSE and CMDOSTOT. Examples: ng, mg, Perm
or mg/kg.

CMDOSFRM

Dose Form

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Dose form for CMTRT. Examples: TABLET, LOTION.

Perm

CMDOSFRQ

Dosing Frequency Per
Interval

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Usually expressed as the number of dosings given per a
specific interval. Examples: BID, QID.

Perm

CMDOSTOT

Total Daily Dose using
CMDOSU

Num

CRF or
Derived

Record
Qualifier

Total daily dose of CMTRT using the units in CMDOSU.

Perm

CMDOSRGM

Intended Dose Regimen

Char

CRF or
Derived

Variable
Qualifier

Text description of the (intended) schedule or regimen for
the Intervention. Examples: TWO WEEKS ON, TWO
WEEKS OFF.

Perm

CMROUTE

Route of Administration

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Route of administration for CMTRT. Examples: ORAL,
INTRAVENOUS.

Perm

CMSTDTC

Start Date/Time of
Medication

Char

ISO 8601

CRF

Timing

Perm

SDTMIG
4.1.4.1

CMENDTC

End Date/Time of Medication Char

ISO 8601

CRF

Timing

Perm

SDTMIG
4.1.4.1

CMSTDY

Study Day of Start of
Medication

Num

Derived

Timing

Study day of start of medication relative to the sponsordefined RFSTDTC.

Perm

SDTMIG
4.1.4.1

CMENDY

Study Day of End of
Medication

Num

Derived

Timing

Study day of end of medication relative to the sponsordefined RFSTDTC.

Perm

SDTMIG
4.1.4.1

Page 42
August 26, 2005

Origin

CDISC, © 2005. All rights reserved
FINAL

SDTMIG
4.1.3.5

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin
CRF

Role

CMDUR

Duration of Medication

Char

ISO 8601

Timing

CMSTRF

Start Relative to Reference
Period

Char

** BEFORE, Derived
DURING,
AFTER

Timing

CMENRF

End Relative to Reference
Period

Char

** BEFORE, Derived
DURING,
AFTER,
DURING/
AFTER, U

Timing

CDISC Notes

Core

Collected duration and unit of a treatment. Used only if
Perm
collected on the CRF and not derived from start and end
date/times.
Identifies the start of the medication with respect to the
Perm
sponsor-defined reference period. Sponsors should define
the reference period in the study metadata. CMSTRF
should be populated when a start date is not collected. If
information such as "PRIOR", "ONGOING", or
"CONTINUING" was collected, this information should be
translated into CMSTRF.
Identifies the end of the medication with respect to the
Perm
sponsor-defined reference period. Sponsors should define
the reference period in the study metadata. Medications
that are ongoing at the end of the reference period should
have a value of AFTER for this variable. CMENRF should
be populated when an end date is not collected. If
information such as "PRIOR", "ONGOING", or
"CONTINUING" was collected, this information should be
translated into CMENRF.

References

SDTMIG
4.1.4.7

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.1.1.1
Assumptions for Concomitant Medications (CM) domain model
1. CM Definition
a. CRF data that captures the Concomitant and Prior Medications/Therapies used by the subject. Examples are the Concomitant
Medications/Therapies given on an as needed basis and the usual and background medications/therapies given for a condition.
b. This domain should contain one record per each Concomitant Medication/Therapy intervention episode.
2.

Concomitant Medications Description and Coding
a. CMTRT captures the name of the Concomitant Medications/Therapy and it is the topic variable. It is a required variable and must have a value.
b. CMMODIFY should be included if the sponsor’s procedure permits modification of a verbatim term for coding. The modified term is listed in
CMMODIFY.
c. CMDECOD is the standardized medication/therapy term derived by the sponsor from the coding dictionary. It is expected that the reported term
(CMTRT) or the modified term (CMMODIFY) will be coded using a standard dictionary. The sponsor is expected to provide the dictionary name
and version used to map the terms in the metadata (using the Comments column in the Define document). If a sponsor chooses to use more than
one dictionary to code different types of data within the same dataset (e.g., drug and non-drug therapies), then the variables CMCAT or CMSCAT
can be used to categorize the data by type. The metadata will specify which dictionary is applied to each category.
d. CMCLAS is used only when the dictionary used codes to a single class. If using a dictionary that allows links to multiple classes, then omit
CMCLAS from the submission dataset.

CDISC, © 2005. All rights reserved
FINAL

Page 43
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Additional Categorization and Grouping
a. CMCAT and CMSCAT may be used as categorization variables to group data across subjects. Examples of CMCAT could include values such as
ANTI-CANCER MEDICATION, or GENERAL CONMED. CMSCAT may be used to further categorize the Concomitant Medications/Therapy
taken by the subject. Examples: CHEMOTHERAPY, RADIOTHERAPY, HORMONAL THERAPY or ALTERNATIVE THERAPY. Neither
CMCAT nor CMSCAT are expected variables in the submission dataset.
b. CMGRPID is used to link a block of related records at the subject level in a single domain to support relationships within the domain and between
domains.

Presence or Absence of Concomitant Medications
a. Information regarding Concomitant Medications/Therapy is generally collected in two different ways, either by recording free text or using a prespecified list of terms. In the latter case, the solicitation of information on specific concomitant medications may affect the frequency at which they
are reported; therefore, the fact that use of a specific medication was solicited may be of interest to reviewers. Consequently, the SDS Team is
proposing the addition of a new variable --PRESP to the SDTM to indicate that the use of those specific medications was solicited. Until then,
CMPRESP can be used as a supplemental qualifier.
b. CMOCCUR may be used when a CRF includes a pre-specified list of Concomitant Medications/Therapies to indicate whether or not a
medication/therapy was used. Proper use of this variable is under evaluation by the SDS Team.

ConMed Structure
a. The structure of the CM domain is one record per medication intervention episode per subject. It is the sponsor's responsibility to define an
intervention episode. This definition may vary based on the sponsor's requirements for review and analysis. The submission dataset structure may
differ from the structure at the time of collection. One common approach is to submit a new record when there is a change in the dosing regimen.
Another approach is to collapse all records for a medication to a summary level with either a dose range or the highest dose level. Other
approaches, including a visit-based record, may also be reasonable as long as they meet the sponsor's evaluation requirements.

Page 44
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.1.2

Exposure — EX

ex.xpt, Exposure — Interventions, Version 3.1.1 August 26, 2005. One record per constant dosing interval per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

EXSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant Req
to the observation.

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a
Req
dataset for a subject. Can be used to join related records.

SDTM 2.2.4

EXGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single Perm
domain to support relationships within the domain and
between domains.

SDTMIG 2.1;
SDTM 2.2.4

EXSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Sponsor-defined reference number. Perhaps pre-printed Perm
on the CRF as an explicit line identifier or defined in the
sponsor’s operational database. Example: Line number
on a CRF Page.

SDTM 2.2.4

EXTRT

Name of Actual Treatment

Char

CRF or
Topic
Randomization
File or Derived

Name of the intervention treatment — usually the
verbatim name of the investigational treatment given
during the dosing period for the observation.

Req

SDTMIG 4.1.3.6

EXCAT

Category for Treatment

Char

Sponsor
Defined

Grouping
Qualifier

Used to define a category of related records. Example:
COMPARATOR CLASS.

Perm

SDTMIG 2.1

EXSCAT

Subcategory for Treatment

Char

Sponsor
Defined

Grouping
Qualifier

A further categorization of treatment.

Perm

SDTMIG 2.1

EXDOSE

Dose per Administration

Num

CRF or
Sponsor
Defined

Record Qualifier Amount of EXTRT administered or given.

CDISC, © 2005. All rights reserved
FINAL

**EX

Exp

Page 45
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

EXDOSTXT

Dose Description

Char

EXDOSU

Dose Units

Char

EXDOSFRM

Dose Form

EXDOSFRQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

CRF or
Derived

Record Qualifier Dosing amounts or a range of dosing information
collected in text form. Example: 200-400.

CRF or
Sponsor
Defined

Variable
Qualifier

Units for EXDOSE and EXDOSTOT. Examples: ng, mg, Exp
or mg/kg.

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Dose form for EXTRT. Examples: TABLET, LOTION,. Req

Dosing Frequency Per
Interval

Char

CRF or
Sponsor
Defined

Variable
Qualifier

Usually expressed as the number of dosings given per a
specific interval. Examples: BID, QID.

EXDOSTOT

Total Daily Dose Using
EXDOSU

Num

CRF or
Derived

Record Qualifier Total daily dose of EXTRT using the units in EXDOSU. Perm

EXDOSRGM

Intended Dose Regimen

Char

CRF or
Derived

Variable
Qualifier

EXROUTE

Route of Administration

Char

CRF or
Sponsor
Defined

Variable
Qualifier

EXLOT

Lot Number

Char

CRF

Record Qualifier Lot Number of the EXTRT product.

EXLOC

Location of Dose
Administration

Char

CRF or
Sponsor
Defined

Record Qualifier Specifies anatomical location of administration Example: Perm
LEFT ARM for a topical application.

EXTRTV

Treatment Vehicle

Char

CRF or
Sponsor
Defined

Record Qualifier Describes vehicle used for treatment. Example:
SALINE.

EXADJ

Reason for Dose Adjustment Char

CRF or
Sponsor
Defined

TAETORD

Order of Element within Arm Num

Sponsor
Defined /
Protocol

Record Qualifier Describes reason or explanation of why a dose is adjusted Perm
– used only when an adjustment is represented in EX.
May be used for variations from protocol-specified doses,
or changes from expected doses.
Timing
Number that gives the order of the Element within the
Perm
arm.

Page 46
August 26, 2005

Perm

Text description of the (intended) schedule or regimen for Perm
the Intervention. Examples: two weeks on, two weeks
off.
Route of administration for EXTRT. Examples: ORAL, Perm
INTRAVENOUS.
Perm

Perm

CDISC, © 2005. All rights reserved
FINAL

References

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

EXSTDTC

Start Date/Time of Treatment Char

ISO 8601

CRF or
Derived

Timing

The time when the dose was administered.

Req

EXENDTC

End Date/Time of Treatment Char

ISO 8601

CRF or
Derived

Timing

May not be relevant for injections.

Perm SDTMIG 4.1.4.1

EXSTDY

Study Day of Start of
Treatment

Num

Derived

Timing

Study day of start of treatment relative to the sponsordefined RFSTDTC.

Perm SDTMIG 4.1.4.1

EXENDY

Study Day of End of
Treatment

Num

Derived

Timing

Study day of end of treatment relative to the sponsordefined RFSTDTC.

Perm SDTMIG 4.1.4.1

EXDUR

Duration of Treatment

Char

CRF

Timing

EXTPT

Planned Time Point Name

Char

CRF or
Derived

Timing

EXTPTNUM

Planned Time Point Number Num

Timing

EXELTM

Planned Elapsed Time from Char
Reference Pt

Sponsor
Defined
Sponsor
Defined

Collected duration and unit of a treatment. Used only if Perm
collected on the CRF and not derived from start and end
date/times.
1. Text Description of time when a dose should be given. Perm
2. This may be represented as an elapsed time relative to a
fixed reference point, such as time of last dose. See
EXTPTNUM and EXTPTREF. Examples: Start or 5 min
post.
Numerical version of EXTPT to aid in sorting.
Perm

Timing

Elapsed time (in ISO 8601) format relative to the planned Perm
fixed reference (EXTPTREF). This variable is useful
where there are repetitive measures. Not a clock time.

EXTPTREF

Time Point Reference

Sponsor
Defined

Timing

Name of the fixed reference point referred to by
EXELTM, EXTPTNUM, and EXTPT. Examples:
Previous Dose, Previous Meal.

•

6.1.2.1

ISO 8601

Char

SDTMIG 4.1.4.1

Perm

indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled
terminology.
Assumptions for Exposure (EX) domain model

1. EX Definition
a. The Exposure domain model records the details of a subject’s exposure to protocol-specified study treatment. Study treatment may be any intervention
that is prospectively defined as a test material within a study, and is typically but not always supplied to the subject. Examples include but are not limited
to placebo, active comparator, and investigational product. Treatments that are not protocol-specified should be recorded in the Concomitant Medication
(CM) domain.

CDISC, © 2005. All rights reserved
FINAL

Page 47
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

b. This domain should contain one record per constant dosing interval per subject. "Constant dosing interval" is sponsor-defined, and may include any
period of time that can be described in terms of a known treatment given at a consistent dose. e.g., for a study with once-a-week administration of a
standard dose for 6 weeks, exposure may be represented with a single record per subject, spanning the entire treatment phase. Or if the sponsor monitors
each treatment administration and deviations in treatment or dose occur, there could be up to six records (one for each weekly administration).
2. Categorization and Grouping
a. EXCAT and EXSCAT may be used when appropriate to categorize treatments into categories and subcategories. For example, if a study contains several
active comparator medications, EXCAT may be set to 'ACTIVE COMPARATOR.' Since such categorization may not apply to many studies, these
variables are permissible but not expected.

Page 48
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.1.3

Substance Use - SU

su.xpt, Substance Use — Interventions, Version 3.1.1, August 26, 2005. One record per substance type per visit per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

SUSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant to
the observation.

Req

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a dataset Req
for a subject. Can be used to join related records.

SDTM 2.2.4

SUGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single
domain to support relationships within the domain and
between domains.

Perm

SDTMIG 2.1;
SDTM 2.2.4

SUSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Sponsor-defined reference number. Perhaps pre-printed on the Perm
CRF as an explicit line identifier or defined in the sponsor’s
operational database. Example: Line number on a Tobacco &
Alcohol use CRF page.

SDTM 2.2.4

SUTRT

Reported Name of Substance

Char

CRF

Topic

Substance name. Examples: Cigarettes, Coffee.

Req

SDTMIG
4.1.3.6

SUMODIFY

Modified Substance Name

Char

Sponsor
Defined

Synonym
Qualifier

If SUTRT is modified, then the modified text is placed here.

Perm

SDTMIG
4.1.3.5

SUDECOD

Standardized Substance Name Char

Derived

Synonym
Qualifier

Standardized or dictionary-derived text description of SUTRT Perm
or SUMODIFY if the sponsor chooses to code the substance
use. The sponsor should specify the dictionary name and
version in the Sponsor Comments column of the Define
document. If an intervention term does not have a decode
value in the dictionary then SUDECOD will be null

SDTMIG
4.1.3.5

SUCAT

Category for Substance Use

Char

SUSCAT

Subcategory for Substance Use Char

Sponsor
Defined
Sponsor
Defined

Grouping
Qualifier
Grouping
Qualifier

Used to define a category of related records. Examples:
TOBACCO, ALCOHOL, or CAFFEINE.
A further categorization of substance use. Examples:
CIGARS, CIGARETTES, BEER, WINE

CDISC, © 2005. All rights reserved
FINAL

**SU

Perm

SDTMIG 2.1

Perm

SDTMIG 2.1

Page 49
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

SUOCCUR

SU Occurrence

Char

**Y, N or
Null

CRF or
Sponsor
Defined

Record
Qualifier

SUSTAT

Substance Use Status

Char

**NOT
DONE

CRF

SUREASND

Char

SUCLAS

Reason Substance Use Not
Collected
Substance Use Class

Char

Derived

SUCLASCD

Substance Use Class Code

Char

Derived

SUDOSE

Substance Use Consumption

Num

Record
Qualifier
Record
Qualifier
Variable
Qualifier
Variable
Qualifier
Record
Qualifier

SUDOSTXT

Char

SUDOSU

Substance Use Consumption
Text
Consumption Units

Char

SUDOSFRM

Dose Form

Char

SUDOSFRQ

Use Frequency Per Interval

Char

SUDOSTOT
SUROUTE

Total Daily Consumption using Num
SUDOSU
Route of Administration
Char

VISIT

Visit Name

Page 50
August 26, 2005

Char

CRF

CRF or
Sponsor
Defined
CRF or
Derived
CRF or
Sponsor
Defined
CRF or
Sponsor
Defined
CRF or
Sponsor
Defined
CRF or
Derived
CRF or
Sponsor
Defined
CRF or
Derived

CDISC Notes

Core

Used when the use of specific substances is solicited to
Perm
indicate whether a substance was taken or not. Values are null
for spontaneously reported substances.
Note: Use of this variable is under evaluation by the SDS
Team.
Used to indicate that the question was not asked.
Perm
Describes the reason substance use was not collected. Used in Perm
conjunction with SUSTAT when value is NOT DONE.
May be used when coding certain substance use cases such as Perm
alcoholism or drug abuse.
May apply when coding substance abuse use cases.
Perm
Amount of SUTRT consumed.

Perm

Record
Qualifier
Variable
Qualifier

Substance use consumption amounts or a range of
consumption information collected in text form.
Units for SUDOSE. Examples: OUNCES, CIGARETTE
EQUIVALENTS, or GRAMS.

Perm

Variable
Qualifier

Dose form for SUTRT. Examples: INJECTABLE, LIQUID, Perm
or POWDER.

Variable
Qualifier

Usually expressed as the number of uses consumed per a
specific interval. Examples: PER DAY, PER WEEK,
OCCASIONAL.
Total daily use of SUTRT using the units in SUDOSU.

Perm

Route of administration for SUTRT. Examples: ORAL,
INTRAVENOUS, INHALATION.

Perm

1. Protocol-defined description of clinical encounter.
2. May be used in addition to VISITNUM and/or VISITDY.

Perm

Record
Qualifier
Variable
Qualifier
Timing

References

SDTMIG
4.1.5.3
SDTMIG
4.1.3.5
SDTMIG
4.1.3.1

Perm

CDISC, © 2005. All rights reserved
FINAL

SDTMIG 7.8;
SDTMIG
4.1.4.5

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

VISITNUM

Visit Number

Num

CRF or
Derived

Timing

VISITDY

Planned Study Day of Visit

Num

CRF or
Derived

SUSTDTC

Start Date/Time of Substance
Use

Char

ISO 8601

SUENDTC

End Date/Time of Substance
Use

Char

ISO 8601

SUSTDY

CDISC Notes

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Core

References

Req

SDTMIG 7.8;
SDTMIG
4.1.4.5

Timing

Perm

SDTMIG 7.8;
SDTMIG
4.1.4.5

CRF or
Derived

Timing

Perm

SDTMIG
4.1.4.1

CRF or
Derived

Timing

Perm

SDTMIG
4.1.4.1

Study Day of Start of Substance Num
Use

Derived

Timing

Study day of start of substance use relative to the sponsordefined RFSTDTC.

Perm

SDTMIG
4.1.4.1

SUENDY

Study Day of End of Substance Num
Use

Derived

Timing

Study day of end of substance use relative to the sponsordefined RFSTDTC.

Perm

SDTMIG
4.1.4.1

SUDUR

Duration of Substance Use

Char

ISO 8601

CRF

Timing

Collected duration and unit of substance use. Used only if
collected on the CRF and not derived from start and end
date/times.

Perm

SUSTRF

Start Relative to Reference
Period

Char

** BEFORE, Derived
DURING,
AFTER

Timing

Identifies the start of the substance use period with respect to Perm
the sponsor-defined reference period. Sponsors should define
the reference period in the study metadata. SUSTRF should be
populated when a start date is not collected. If information
such as "PRIOR", "ONGOING", or "CONTINUING" was
collected, this information should be translated into SUSTRF.

SDTMIG
4.1.4.7

SUENRF

End Relative to Reference
Period

Char

** BEFORE, Derived
DURING,
AFTER,
DURING/
AFTER, U

Timing

Identifies the end of the substance use period with respect to Perm
the sponsor-defined reference period. Sponsors should define
the reference period in the study metadata. Use of substances
that is ongoing at the end of the reference period should have
a value of AFTER for this variable. SUENRF should be
populated when an end date is not collected. If information
such as "PRIOR", "ONGOING", or "CONTINUING" was
collected, this information should be translated into SUENRF.

SDTMIG
4.1.4.7

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.

CDISC, © 2005. All rights reserved
FINAL

Page 51
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.1.3.1
Assumptions for Substance Use (SU) domain model
1. The intent of the domain is to capture substance use information that may be used to assess the efficacy and/or safety of therapies that look to mitigate the
effects of chronic substance use, or that could be used as covariates to support the efficacy and/or safety analyses of other topic variables.
2.

SU Definition
a. This information may be independent of planned study evaluations or may be a key outcome (e.g., planned evaluation) of a clinical trial.
b. In many clinical trials detailed substance use information as represented by this domain may not be required (e.g., the only information collected may be
a response to the question ‘Have you ever smoked tobacco?’); in this case many of the qualifying variables would not be submitted.

Substance Use Description and Coding
a. SUTRT captures the verbatim term collected for the substance. It is the topic variable for the SU dataset. SUTRT is a required variable and must have a
value.
b. SUMODIFY is a permissible variable and should be included if the sponsor’s procedure permits modification of a verbatim substance use term for
coding. The modified term is listed in SUMODIFY. The variable may be populated as per the sponsor’s procedures; null values are permitted.
c. SUDECOD is the preferred term derived by the sponsor from the coding dictionary. It is a permissible variable; Null values are permitted. Where
deemed necessary by the sponsor the verbatim term (SUTRT) should be coded using a standard dictionary such as WHODRUG. The sponsor is
expected to provide the dictionary name and version used to map the terms in the metadata (using the Comments column in the Define document).
d. SUCLAS and SUCLASCD can be used to classify substances using a dictionary that codes to a single class. These variables would not be used if the
sponsor were to use WHODRUG to classify substances.

4. Additional Categorization and Grouping
a. SUCAT and SUSCAT should not be redundant with the domain code or dictionary classification provided by SUDECOD. That is, they should provide a
different means of defining or classifying SU records. For example, a sponsor may be interested in identifying all SU records that the investigator feels
might represent opium use and thus will collect that categorization on the CRF. This categorization might differ from the categorization derived from
the coding dictionary. It is not necessary to populate these variables.
b. SUGRPID may be used to link (or associate) different records together to form a block of related records at the subject level within SU. It should not be
used in place of SUCAT or SUSCAT, which are used to group data across subjects. It is not necessary to populate this variable.
5. Presence or Absence of Substance Use
a. If specific substances are solicited (i.e., a pre-specified list of terms is collected), SUOCCUR may be used to indicate whether or not each substance was
consumed. Use of this variable is under evaluation by the SDS Team.
b. For cases when it is important to know whether the occurrence of specific substances is solicited (i.e., a pre-specified list of terms is collected), the SDS
Team is proposing the addition of a new variable --PRESP to the SDTM. Until then, SUPRESP can be used as a supplemental qualifier.
6. Timing Variables
a. SUSTDTC and SUENDTC may be populated as required. Null values are permissible.
b. If substance use information is collected more than once within the CRF (indicating that the data are visit-based) or collected only once within the CRF
then VISITNUM is required. VISITDY and VISIT are always permissible.
7. Other Qualifier Variables
a. In those instances where detailed dosing information is collected, the variables SUDOSE, SUDOSTXT, SUDOSU, SUDOSFRM, SUDOSFRQ,
SUDOSTOT and SUROUTE may be populated; null values are permitted.
b. When the response for a substance use question on a CRF was not collected, then the value of SUSTAT = 'NOT DONE' and SUOCCUR will be null.
Page 52
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.2

EVENTS

6.2.1

Adverse Events — AE

ae.xpt, Adverse Events — Events, Version 3.1.1, August 26, 2005. One record per adverse event per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char

USUBJID

Unique Subject Identifier

Char

AESEQ

Sequence Number

Num

AEGRPID

Group ID

AEREFID

Controlled
Terms or
Format

Origin

Role

CRF
Derived

Identifier
Identifier

Sponsor
Defined
CRF or
Derived

Identifier

Char

Sponsor
Defined

Identifier

Reference ID

Char

Identifier

AESPID

Sponsor-Defined Identifier

Char

Sponsor
Defined
Sponsor
Defined

AETERM
AEMODIFY

Reported Term for the Adverse Event
Modified Reported Term

Char
Char

AEDECOD

Dictionary-Derived Term

Char

CRF
Sponsor
Defined
Derived

Topic
Synonym
Qualifier
Synonym
Qualifier

AECAT

Category for Adverse Event

Char

Sponsor
Defined

Grouping
Qualifier

CDISC, © 2005. All rights reserved
FINAL

**AE

Identifier

CDISC Notes

Core

References

Unique identifier for a study within the submission. Req
Two-character abbreviation for the domain most
Req
relevant to the observation.
Unique subject identifier within the submission.
Req

SDTM 2.2.4
SDTM 2.2.4

Sequence number given to ensure uniqueness
Req
within a dataset for a subject. Can be used to join
related records.
Used to tie together a block of related records in a Perm
single domain to support relationships within the
domain and between domains.
Optional internal or external identifier such as a
Perm
serial number on an SAE reporting form
Optional Sponsor-defined reference number.
Perm
Perhaps pre-printed on the CRF as an explicit line
identifier or defined in the sponsor’s operational
database. Example: Line number on a Adverse
Events page.
Verbatim name of the event.
Req
If AETERM is modified, then AEMODIFY will
Perm
contain the modified text.
Dictionary-derived text description of AETERM or Req
AEMODIFY. Equivalent to the Preferred Term (PT
in MedDRA). The sponsor should specify the
dictionary name and version in the Sponsor
Comments column of the Define document.
Used to define a category of related records.
Perm
Example: BLEEDING, HYPOGLYCEMIA.

SDTM 2.2.4

SDTM 2.2.4
SDTM 2.2.4

SDTMIG 4.1.3.6
SDTMIG 4.1.3.6
SDTMIG 4.1.3.5;
SDTMIG 4.1.3.6

SDTMIG 4.1.2.6

Page 53
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Origin
Format
*
Sponsor
Defined
**Y, N or CRF or
Null
Sponsor
Defined

Role

AESCAT

Subcategory for Adverse Event

Char

AEOCCUR

Adverse Event Occurrence

Char

AEBODSYS

Body System or Organ Class

Char

CRF or
Derived

Record
Qualifier

AELOC

Location of the Reaction

Char

AESEV

Severity/Intensity

Char

CRF or
Derived
CRF

AESER

Serious Event

Char

**Y, N

AEACN

Action Taken with Study Treatment

Char

Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier

AEACNOTH

Other Action Taken

Char

AEREL

Causality

Char

AERELNST

Relationship to Non-Study Treatment

Char

AEPATT

Pattern of Adverse Event

Char

Page 54
August 26, 2005

CRF or
Derived
CRF

Grouping
Qualifier
Record
Qualifier

CRF

Record
Qualifier

CRF

Record
Qualifier

CRF

Record
Qualifier

CRF

Record
Qualifier

CDISC Notes

Core

A further categorization of adverse event. Example: Perm
NEUROLOGIC.
Used when the occurrence of specific adverse
Perm
events is solicited to indicate whether an adverse
event occurred or not. Values are null for
spontaneously reported events.
Note: Use of this variable is under evaluation by
the SDS Team.
Body system or organ class (Primary SOC) that is Exp
involved in an event or measurement from the
standard hierarchy (e.g., MedDRA).
Describes anatomical location relevant for the
Perm
event. (e.g., LEFT ARM for skin rash).
The severity or intensity of the event. Examples:
Perm
MILD, MODERATE, SEVERE.
Is this is a serious event?
Exp
Describes changes to the study treatment as a result
of the event. Examples include ICH E2B values:
DRUG WITHDRAWN, DOSE REDUCED,DOSE
INCREASED, DOSE NOT CHANGED,
UNKNOWN or NOT APPLICABLE
Describes other actions taken as a result of the
event. Usually reported as free text. Example:
“Treatment unblinded. Primary care physician
notified.”
Records the investigator’s opinion as to the
causality of the event to the treatment. Examples:
NOT RELATED,UNLIKELY RELATED,
POSSIBLY RELATED, RELATED
Records the investigator's opinion as to whether the
event may have been to due to a treatment other
than study drug. Reported as free text. Example:
"More likely related to aspirin use”.
Used to indicate the pattern of the event over time.
Examples: INTERMITTENT, CONTINUOUS,
SINGLE EVENT.

References
SDTMIG 4.1.2.6

SDTMIG 4.1.3.5

Exp

Perm

Exp

Perm

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

AEOUT

Outcome of Adverse Event

Char

AESCAN

Involves Cancer

Char

AESCONG

Congenital Anomaly or Birth Defect

Char

AESDISAB

Persist or Signif Disability/Incapacity

Char

AESDTH

Results in Death

Char

AESHOSP

Requires or Prolongs Hospitalization

Char

AESLIFE

Is Life Threatening

Char

AESOD

Occurred with Overdose

Char

AESMIE

Controlled
Terms or
Origin
Format
*
CRF

CRF

AECONTRT

Other Medically Important Serious
Char
Event
Concomitant or Additional Trtmnt GivenChar

**Y, N or
Null
**Y, N or
Null
**Y, N or
Null
**Y, N or
Null
*Y, N or
Null
**Y, N or
Null
**Y, N or
Null
**Y, N or
Null
**Y, N

AETOXGR

Standard Toxicity Grade

Char

CRF or
Derived

AESTDTC

Start Date/Time of Adverse Event

Char

ISO 8601

AEENDTC

End Date/Time of Adverse Event

Char

ISO 8601

CRF or
Derived
CRF or
Derived

CDISC, © 2005. All rights reserved
FINAL

CRF
CRF
CRF or
Derived
CRF
CRF
CRF
CRF
CRF

Role
Record
Qualifier

Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier
Record
Qualifier

Timing
Timing

CDISC Notes

Core

References

Description of the outcome of an event. Examples Perm
include ICH E2B values: RECOVERED/
RESOLVED, RECOVERING/ RESOLVING, NOT
RECOVERED/ NOT RESOLVED, RECOVERED/
RESOLVED WITH SEQUELAE, FATAL or
UNKNOWN.
Was the event associated with the development of Perm
cancer?
Was the event associated with congenital anomaly Perm
or birth defect?
Did the event result in persistent or significant
Perm
disability/incapacity?
Did the event result in death?
Perm
Did the event require or prolong hospitalization?

Perm

Was the event life threatening?

Perm

Did the event occur with an overdose?

Perm

Do additional categories for seriousness apply?

Perm

Was another treatment given because of the
Perm
occurrence of the event?
Toxicity grade according to a standard toxicity
Perm
scale such as Common Terminology Criteria for
Adverse Events v3.0 (CTCAE). Sponsor should
specify scale and version used in the Comments
column of the Define data definition document.
Value should contain valid numbers only; datatype
will be changed to numeric in future version of
SDTM.
Exp
Exp

SDTMIG 4.1.4.1;
SDTMIG 4.1.4.2
SDTMIG 4.1.4.1;
SDTMIG 4.1.4.2

Page 55
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

AESTDY

Study Day of Start of Adverse Event

Num

Derived

Timing

AEENDY

Study Day of End of Adverse Event

Num

Derived

Timing

AEDUR

Duration of Adverse Event

Char

ISO 8601

CRF

Timing

AEENRF

End Relative to Reference Period

Char

**
Derived
BEFORE,
DURING,
AFTER,
DURING/
AFTER, U

Timing

CDISC Notes

Core

References

Study day of start of adverse event relative to the Perm
sponsor-defined RFSTDTC.
Study day of end of event relative to the sponsor- Perm
defined RFSTDTC.
Collected duration and unit of an adverse event.
Perm
Used only if collected on the CRF and not derived
from start and end date/times. Example: P1DT2H
(for 1 day, 2 hours).

SDTMIG 4.1.4.4

Identifies the end of the event as being BEFORE, Perm
DURING, DURING/AFTER or AFTER the
sponsor-defined reference period. The sponsordefined reference period is a continuous period of
time defined by a discrete starting point and a
discrete ending point. Typically, this period is
defined by the start (RFSTDTC) and end
(RFENDTC) of the trial. Sponsors should define
the reference period in the study metadata. Events
that are ongoing at the end of the reference period
should have a value of AFTER for this variable. If
information such as "PRIOR", "ONGOING", or
"CONTINUING" was collected, this information
should be translated into AEENRF.

SDTMIG 4.1.4.7

SDTMIG 4.1.4.4
SDTMIG 4.1.4.3

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.2.1.1
Assumptions for Adverse Events (AE) domain model
1. AE Definition
a.

The Adverse Events dataset includes "any untoward medical occurrence in a patient or clinical investigation subject administered a
pharmaceutical product and which does not necessarily have to have a causal relationship with this treatment" (ICH E2A). Adverse events
may be captured either as free text or a pre-specified list of terms.

Adverse Event Description and Coding
a.
b.

Page 56
August 26, 2005

AETERM captures the verbatim term collected for the event. It is the topic variable for the AE dataset. AETERM is a required variable and
must have a value.
AEMODIFY is a permissible variable and should be included if the sponsor’s procedure permits modification of a verbatim term for coding.
The modified term is listed in AEMODIFY. The variable should be populated as per the sponsor’s procedures; null values are permitted.

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

c.
d.
3.

Additional Categorization and Grouping
a.

b.
4.

AECAT and AESCAT should not be redundant with the domain code or dictionary classification provided by AEDECOD and AEBODSYS.
That is, they should provide a different means of defining or classifying AE records. For example, a sponsor may be interested in identifying
all adverse events that the investigator feels might represent an infection and thus will collect that categorization on the CRF. This
categorization might differ from the categorization derived from the coding dictionary.
AEGRPID may be used to link (or associate) different records together to form a block of related records at the subject level within AE. It
should not be used in place of AECAT or AESCAT, which are used to group data across subjects..

Presence or Absence of Adverse Events
a.

b.
c.
a.

AEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is a required variable and must have a value. It is
expected that the reported term (AETERM) will be coded using a standard dictionary such as MedDRA. The sponsor is expected to provide
the dictionary name and version used to map the terms in the metadata (using the Comments column in the Define document).
AEBODSYS is the primary system organ class derived by the sponsor from the coding dictionary. It is expected that this variable will be
populated.

Adverse events are generally collected in two different ways, either by recording free text or using a pre-specified list of terms. In the latter
case, the solicitation of information on specific adverse events may affect the frequency at which they are reported; therefore, the fact that a
specific adverse event was solicited may be of interest to reviewers. Consequently, the SDS Team is proposing the addition of a new variable -PRESP to the SDTM to indicate that the use of those specific medications was solicited. Until then, AEPRESP can be used as a supplemental
qualifier.
If specific adverse events or a pre-specified list of terms are collected, AEOCCUR may be used to indicate whether or not each event occurred.
Use of this variable is under evaluation by the SDS Team.
If a study collects both pre-specified events as well as subject reported events, the value of AEOCCUR should be populated for all prespecified events and null for subject reported events.
When adverse events are collected with the recording of free text, some sponsors may enter a record into the data management system to
indicate 'no adverse events,' for a specific subject. For these subjects, do not include a record to indicate that there were no events unless
AEOCCUR is being used to represent records for non-occurring events. Otherwise, records should be included in the submission dataset only
for adverse events that have actually occurred.

Timing Variables
a.
b.

Either AEENDTC or AEENRF should be populated.
If adverse events are collected more than once within the CRF (indicating that the data are visit-based), then VISITNUM is expected. If the
adverse events are collected only once within the CRF (indicating that the data are event-based), then VISITNUM is permissible. VISITDY
and VISIT are always permissible.

CDISC, © 2005. All rights reserved
FINAL

Page 57
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Other Qualifier Variables
a.

b.
c.
d.

If categories of serious events are collected secondarily to a leading question as in the example below, the values may be null. For example, if
Serious is answered 'No,' the values for AESDTH, AESLIFE, AESHOSP, etc. may be null. However, if Serious is answered ‘Yes,’ at least one
of AESDTH, AESLIFE, AESHOSP, etc. will have a ‘Y’ response.
Serious? [ ] Yes [ ] No
If yes, check all that apply: [ ] Fatal [ ] Life-threatening [ ] Inpatient hospitalization… [ ] etc.
On the other hand, if the CRF were structured so that a response is collected for each serious category, all category variables (e.g., AESDTH,
AESHOSP) would be populated and AESER could be derived.
When a description of Other Medically Important Serious Adverse Events category is collected on a CRF, sponsors should place the description
in the SUPPQUAL dataset as described in Section 8.4.
The serious categories “Involves cancer” (AESCAN) and “Occurred with overdose” (AESOD) are not part of the ICH definition of a serious
adverse event, but these categories are available for use for studies conducted under guidelines that existed prior to the FDA’s adoption of the
ICH definition.
In studies using toxicity grade according to a standard toxicity scale such as Common Terminology Criteria for Adverse Events v3.0 (CTCAE The Common Terminology is the current version for toxicity criteria published by the NCI (National Cancer Institute) at
http://ctep.cancer.gov/reporting/ctc.html), AETOXGR should be used instead of AESEV. AESEV would not be included on the dataset. The
sponsor is expected to specify which scale and version are used in the metadata (using the Comments column in the Define document).

AE Structure.
a. The structure of the AE domain is one record per adverse event per subject. It is the sponsor's responsibility to define an event. This definition
may vary based on the sponsor's requirements for characterizing and reporting product safety and is usually described in the protocol. The
submission dataset structure may differ from the structure at the time of collection. One common approach is to collapse all records for an
event to a summary level with the highest level of severity, causality, seriousness, etc. If there is a need to evaluate AEs at a more granular
level, sponsors may choose to create a new record when severity, causality, or seriousness changes or worsens. Other approaches, including a
visit-based record, may also be reasonable as long as they meet the sponsor's safety evaluation requirements.

Page 58
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.2.2

Disposition — DS

ds.xpt, Disposition — Events Version 3.1.1, August 26, 2005. One record per disposition status or protocol milestone per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char

USUBJID

Unique Subject Identifier

Char

DSSEQ

Sequence Number

Num

DSGRPID

Group ID

Char

DSREFID

Reference ID

Char

DSSPID

Sponsor-Defined Identifier

Char

DSTERM

Reported Term for the
Disposition Event

Char

CDISC, © 2005. All rights reserved
FINAL

Controlled
Terms or
Format
**DS

Origin

Role

CRF
Derived

Identifier
Identifier

Sponsor
Defined
CRF or
Derived
Sponsor
Defined
Sponsor
Defined
Sponsor
Defined

Identifier

CRF

Topic

Identifier
Identifier
Identifier
Identifier

CDISC Notes
Unique identifier for a study within the submission.
Two-character abbreviation for the domain most relevant to the
observation.
Unique subject identifier within the submission.

Core

References

Req
Req

SDTM 2.2.4
SDTM 2.2.4

Req

SDTM 2.2.4

Sequence number given to ensure uniqueness within a dataset for Req
a subject. Can be used to join related records.
Used to tie together a block of related records in a single domain Perm
to support relationships within the domain and between domains.
Optional internal or external identifier.
Perm
Optional Sponsor-defined reference number. Perhaps pre-printed Perm
on the CRF as an explicit line identifier or defined in the
sponsor’s operational database. Example: Line number on a
Disposition page.
Verbatim name of the event or protocol milestone. Some terms in Req
DSTERM will match DSDECOD, but others, such as 'Subject
moved,' will map to controlled terminology in DSDECOD, such
as 'LOST TO FOLLOW-UP.'

SDTM 2.2.4
SDTMIG 2.1;
SDTM 2.2.4
SDTM 2.2.4
SDTM 2.2.4

SDTMIG 4.1.3.6

Page 59
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

DSDECOD

Standardized Disposition
Term

DSCAT

VISIT

Category for Disposition
Char
Event
Subcategory for Disposition Char
Event
Visit Name
Char

VISITNUM

Visit Number

Num

VISITDY

Planned Study Day of Visit

Num

EPOCH

Trial Epoch

Char

DSDTC

Date/Time of Collection

Char

ISO 8601

DSSTDTC

Start Date/Time of
Disposition Event
Study Day of Start of
Disposition Event

Char

ISO 8601

DSSCAT

DSSTDY

Char

Controlled
Terms or
Origin
Format
*
CRF or
Derived

Num

*
*

Sponsor
Defined
Sponsor
Defined
CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived
Derived

Role
Synonym
Qualifier

Grouping
Qualifier
Grouping
Qualifier
Timing
Timing

CDISC Notes

Core

Controlled terminology for the name of disposition event or
protocol milestone. Examples of disposition events:
COMPLETED, ADVERSE EVENT, DEATH, LACK OF
EFFICACY, LOST TO FOLLOW-UP, NON-COMPLIANCE
WITH STUDY DRUG, PHYSICIAN DECISION,
PREGNANCY, PROGRESSIVE DISEASE, PROTOCOL
VIOLATION, SCREEN FAILURE, STUDY TERMINATED
BY SPONSOR, TECHNICAL PROBLEMS, WITHDRAWAL
OF CONSENT, OTHER. Examples of protocol milestones:
INFORMED CONSENT OBTAINED, RANDOMIZED
Used to define a category of related records. Examples:
DISPOSITION EVENT or PROTOCOL MILESTONE.
A further categorization of disposition event.

Req

SDTMIG 4.1.3.5

Perm

SDTMIG 2.1

Perm

SDTMIG 2.1

1. Protocol-defined description of clinical encounter.
2. May be used in addition to VISITNUM and/or VISITDY.
1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.4.4

Perm

Timing

Perm

Timing

EPOCH may be used when DSCAT = 'DISPOSITION EVENT'. Perm
Examples: TREATMENT PHASE, SCREENING, FOLLOW-UP
Perm

Timing
Timing
Timing

References

Exp
Study day of start of the disposition event relative to the sponsor- Perm
defined RFSTDTC.

SDTMIG 4.1.4.1
SDTMIG 4.1.4.1
SDTMIG 4.1.4.4

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.2.2.1
Assumptions for Disposition (DS) domain model
1. DS Definition
a. The Disposition dataset provides an accounting for all subjects who entered the study and may include protocol milestones, such as
randomization, as well as the subject's completion status or reason for discontinuation for each phase or segment of the study, including
screening and post treatment follow-up. Sponsors may choose which disposition events and milestones to submit for a study.

Page 60
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

DS Description and Coding
a. DSTERM contains the disposition or other event information such as a protocol milestone. It is a required variable and must have a value.
DSTERM contains either specific verbatim information of the disposition event and/or sponsor defined controlled terms with the same values
as DSDECOD. Some terms in DSTERM will match those in DSDECOD, but others such as 'Subject moved' will map to controlled
terminology in DSDECOD such as 'LOST TO FOLLOW-UP'.
b. DSDECOD is the sponsor defined controlled term for the disposition event or other event information such as protocol milestones. It is a
required variable and will always have a value. The value in DSDECOD may be equivalent to the value in DSTERM. For disposition events,
DSDECOD = ‘COMPLETE’ when the subject completed the phase or segment described in EPOCH; otherwise, DSDECOD indicates the
reason the subject did not complete the EPOCH.

Other Qualifier Variables
a. DSCAT may be used to distinguish between disposition events and protocol milestones. It is a permissible variable, but its use is recommended
for clarity when both types of events are submitted.
b. Additional information about a death such as autopsy data could be modeled in a separate 'autopsy' domain based on the Findings class.

Timing Variables
a. DSSTDTC is expected as the date/time of the disposition event. Disposition events do not have start and end dates since disposition events do
not span an interval (e.g. randomization date) but occur on a single date/time.
b. EPOCH may bes used to indicate when the disposition event occurred. EPOCH is populated when DSCAT= 'DISPOSITION EVENT'.
EPOCH should not be populated when DSCAT = 'PROTOCOL MILESTONE'.

CDISC, © 2005. All rights reserved
FINAL

Page 61
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.2.3

Medical History — MH

mh.xpt, Medical History — Events, Version 3.1.1, August 26, 2005. One record per medical history event per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

MHSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant to
the observation.

Req

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a dataset Req
for a subject. Can be used to join related records.

SDTM 2.2.4

MHGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single
domain to support relationships within the domain and
between domains.

Perm

SDTMIG 2.1;
SDTM 2.2.4

MHREFID

Reference ID

Char

Sponsor
Defined

Identifier

Optional internal or external medical history identifier.

Perm

SDTM 2.2.4

MHSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Optional Sponsor-defined reference number. Perhaps prePerm
printed on the CRF as an explicit line identifier or defined in
the sponsor’s operational database. Example: Line number
on a Medical History page.

SDTM 2.2.4

MHTERM

Reported Term for the
Medical History

Char

CRF

Topic

Verbatim or preprinted CRF term for the medical condition or Req
event.

SDTMIG 4.1.3.6

MHMODIFY

Modified Reported Term

Char

Sponsor
Defined

Synonym
Qualifier

If MHTERM is modified, then MHMODIFY will contain the Perm
modified text.

SDTMIG 4.1.3.5

MHDECOD

Dictionary-Derived Term

Char

Derived

Synonym
Qualifier

Dictionary-derived text description of MHTERM or
Perm
MHMODIFY. Equivalent to the Preferred Term (PT in
MedDRA). The sponsor should specify the dictionary name
and version in the Sponsor Comments column of the Define
data definition document.

SDTMIG 4.1.3.5

MHCAT

Category for Medical History Char

Sponsor
Defined

Grouping
Qualifier

Used to define a category of related records. Examples:
CARDIAC or GENERAL

Page 62
August 26, 2005

**MH

Perm

SDTMIG 2.1

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

MHSCAT

Subcategory for Medical
History

Char

MHOCCUR

Medical History Occurrence Char

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

Sponsor
Defined

Grouping
Qualifier

A further categorization of the condition or event.

Perm

**Y, N or
Null

CRF or
Sponsor
Defined

Record
Qualifier

Used when the occurrence of specific medical history events Perm
is solicited to indicate whether or not a medical condition had
ever occurred. Values are null for spontaneously reported
events.

References
SDTMIG 2.1

Note: Use of this variable is under evaluation by the SDS
Team.
MHSTAT

Medical History Status

CRF or
Sponsor
Defined

Record
Qualifier

The status indicates that the question was not asked.

Perm

SDTMIG 4.1.5.1.

MHREASND

Reason Medical History Not Char
Collected

CRF

Record
Qualifier

Describes the reason medical history was not collected. Used Perm
in conjunction with MHSTAT when value is NOT DONE.

SDTMIG 4.1.5.3

MHBODSYS

Body System or Organ Class Char

Derived

Record
Qualifier

Body system or organ class (Primary SOC) that is involved in Perm
an event or measurement from the standard hierarchy (e.g.,
MedDRA).

SDTMIG 4.1.3.5

VISIT

Visit Name

Char

CRF or
Derived

Timing

1. Protocol-defined description of clinical encounter.
Perm
2. May be used in addition to VISITNUM and/or VISITDY.

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITNUM

Visit Number

Num

CRF or
Derived

Timing

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITDY

Planned Study Day of Visit

Num

CRF or
Derived

Timing

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

MHDTC

Date/Time of History
Collection

Char

ISO 8601

CRF or
Derived

Timing

Perm

SDTMIG 4.1.4.1

MHSTDTC

Start Date/Time of Medical
History Event

Char

ISO 8601

CRF or
Derived

Timing

Perm

MHENDTC

End Date/Time of Medical
History Event

Char

ISO 8601

CRF or
Derived

Timing

Perm

SDTMIG 4.1.4.1

MHDY

Study Day of History
Collection

Num

Derived

Timing

1. Study day of medical history collection, measured as
Perm
integer days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics. This formula
should be consistent across the submission.

SDTMIG 4.1.4.4

CDISC, © 2005. All rights reserved
FINAL

Char

**NOT
DONE

Page 63
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name
MHENRF

Variable Label
End Relative to Reference
Period

Type
Char

Controlled
Terms or
Format

Origin

** BEFORE, Derived
DURING,
AFTER,
DURING
/AFTER, U

Role
Timing

CDISC Notes

Core

Identifies the end of the event as being BEFORE, DURING, Perm
DURING/AFTER or AFTER the sponsor-defined reference
period. Sponsors should define the reference period in the
study metadata. Events that are ongoing at the end of the
reference period should have a value of AFTER for this
variable. If information such as "PRIOR", "ONGOING", or
"CONTINUING" was collected, this information should be
translated into MHENRF.

References
SDTMIG 4.1.4.7

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.2.3.1

Assumptions for Medical History (MH) domain model

MH Definition
a. The Medical History dataset generally includes the subject's prior history at the start of the trial. Note that treatments for prior and concomitant
conditions should usually be submitted in an appropriate dataset from the Interventions class such as CM or SG.
b. Examples of subject medical history information could include general medical history, gynecological history, and primary diagnosis.

Medical History Description and Coding
a. MHTERM captures the verbatim term collected for the condition or event. It is the topic variable for the MH dataset. MHTERM is a required
variable and must have a value.
b. MHMODIFY is a permissible variable and should be included if the sponsor’s procedure permits modification of a verbatim term for coding.
The modified term is listed in MHMODIFY. The variable should be populated as per the sponsor’s procedures; null values are permitted.
c. If the sponsor codes the reported term (MHTERM) using a standard dictionary, then MHDECOD will be populated with the preferred term
derived from the dictionary. The sponsor is expected to provide the dictionary name and version used to map the terms in the metadata (using
the Comments column in the Define document).
d. If the sponsor codes the reported term (MHTERM) using a standard dictionary, then MHBODSYS will be populated with the primary system
organ class derived from the dictionary.
e. If a CRF collects medical history by pre-specified body systems and the sponsor also codes reported terms using a standard dictionary, then
MHDECOD and MHBODSYS are populated using the information from the standard dictionary. MHCAT and MHSCAT should be used
for the pre-specified body systems.

Page 64
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Additional Categorization and Grouping
a. MHCAT and MHSCAT may be populated with the sponsor's categorization of medical history events, which are often displayed on the CRF.
MHCAT and MHSCAT should not be redundant with the domain code or dictionary classification provided by MHDECOD and/or
MHBODSYS. That is, they should provide a different means of defining or classifying MH records.
i. This categorization should not group all records (within the MH Domain) into one generic group such as 'Medical History' or 'General
Medical History' because this is redundant information with the domain code. If no smaller categorization can be applied, then it is
not necessary to include or populate this variable.
ii. Examples of MHCAT could include 'General Medical History,' 'Allergy Medical History,' and 'Reproductive Medical History.'
b. MHGRPID may be used to link (or associate) different records together to form a block of related records at the subject level within MH. It
should not be used in place of MHCAT or MHSCAT, which are used to group data across subjects. For example, if a group of syndromes were
related to a particular disease then this variable could be populated with the appropriate text.

Presence or Absence of History
a. Information on medical history is generally collected in two different ways, either by recording free text or using a pre-specified list of terms.
In the latter case, the solicitation of information on specific medical history events may affect the frequency at which they are reported;
therefore, the fact that a specific medical history event was solicited may be of interest to reviewers. Consequently, the SDS Team is proposing
the addition of a new variable --PRESP to the SDTM to indicate that the occurrence of those specific medical history events was solicited.
Until then, MHPRESP can be used as a supplemental qualifier.
b. If history is collected by body system or category, MHOCCUR may be used to indicate the presence or absence of events for a given system or
category.
c. If specific medical history events are solicited (i.e., a pre-specified list of terms is collected), MHOCCUR may be used to indicate whether or
not each event occurred. Use of this variable is under evaluation by the SDS Team.
d. When the response for a medical history question or group of questions on a CRF was not collected, then the value of MHSTAT = 'NOT
DONE' and MHOCCUR will be null. The reason that medical history was not done may be documented in MHREASND.
e. If a study collects both pre-specified events as well as subject reported events, the value of MHOCCUR should be populated for all prespecified events and null for subject-reported events unless the response was not collected.

CDISC, © 2005. All rights reserved
FINAL

Page 65
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3

FINDINGS

6.3.1

ECG Test Results — EG

eg.xpt, ECG — Findings, Version 3.1.1, August 26, 2005. One record per ECG observation per time point per visit per subject, Tabulation
Variable Name

Variable Label

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

EGSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant to the
observation.

Req

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a dataset for Req
a subject. Can be used to join related records.

SDTM 2.2.4

EGGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single domain Perm
to support relationships within the domain and between domains.

SDTMIG 2.1;
SDTM 2.2.4

EGREFID

ECG Reference ID

Char

Sponsor
Defined or
Derived

Identifier

Internal or external ECG identifier. Example: UUID for external Perm
ECG Waveform File.

EGSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Optional Sponsor-defined reference number. Perhaps pre-printed Perm
on the CRF as an explicit line identifier or defined in the
sponsor's operational database. Example: Line number from the
ECG page.

EGTESTCD

ECG Test or Examination
Short Name

Char

CRF or
Derived

Topic

Short name of the measurement, test, or examination described in Req
EGTEST. It can be used as a column name when converting a
dataset from a vertical to a horizontal format. The value in
EGTESTCD cannot be longer than 8 characters, nor can it start
with a number (e.g.,'1TEST'). EGTESTCD cannot contain
characters other than letters, numbers, or underscores. Examples:
PR, QT, INTP.

Page 66
August 26, 2005

**EG

CDISC, © 2005. All rights reserved
FINAL

SDTM 2.2.4

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

EGTEST

ECG Test or Examination
Name

Char

CRF

Synonym
Qualifier

EGCAT

Category for ECG

Char

Sponsor
Defined

Grouping
Qualifier

EGSCAT

Subcategory for ECG

Char

Perm

ECG Position of Subject

Char

Grouping
Qualifier
Record
Qualifier

A further categorization of the ECG.

EGPOS

Sponsor
Defined
CRF or
Derived

Position of the subject during a measurement or examination.
Examples: SUPINE, STANDING: SITTING.

Perm

EGORRES

Result or Finding in Original Char
Units

CRF or
Derived

Result
Qualifier

EGORRESU

Original Units

Char

CRF or
Derived

Variable
Qualifier

Result of the ECG measurement or finding as originally received Exp
or collected. Examples of expected values are 62 or 0.151 when
EGTEST is a measured finding, or ATRIAL FIBRILLATION or
QT PROLONGATION when EGTEST is 'interpretation'.
Original units in which the data were collected. The unit for
Perm
EGORRES. Examples: SECONDS or MILLISECONDS.

EGNRIND

Reference Range Indicator

Char

CRF or
Derived

Variable
Qualifier

EGSTRESC

Character Result/Finding in Char
Std Format

Derived

Result
Qualifier

EGSTRESN

Numeric Result/Finding in
Standard Units

Num

Derived

Result
Qualifier

EGSTRESU

Standard Units

Char

CRF or
Derived

Variable
Qualifier

CDISC, © 2005. All rights reserved
FINAL

Verbatim name of the test or examination used to obtain the
Req
measurement or finding. The value in EGTEST cannot be longer
than 40 characters. Examples: PR Interval, QT Interval, etc.
Used to categorize ECG observations. Examples:
Perm
MEASUREMENT or FINDING.

References

SDTMIG 2.1
SDTMIG 2.1

1. Indicates where value falls with respect to reference range
Perm
which could be defined by EGORNRLO and EGORNRHI (if
those variables are used) or by EGSTNRC. Examples:
NORMAL, ABNORMAL, HIGH, LOW.
2. Should not be used to indicate clinical significance.
Contains the result value for all findings, copied or derived from Exp
EGORRES in a standard format or standard units. EGSTRESC
should store all results or findings in character format; if results
are numeric, they should also be stored in numeric format in
EGSTRESN. For example, if a test has results 'NONE', 'NEG',
and 'NEGATIVE' in EGORRES and these results effectively
have the same meaning, they could be represented in standard
format in EGSTRESC as 'NEGATIVE'. For other examples, see
general assumptions. Additional examples of result data; SINUS
BRADYCARDIA, ATRIAL FLUTTER, ATRIAL
FIBRILLATION.
Used for continuous or numeric results or findings in standard
Perm
format; copied in numeric format from EGSTRESC. EGSTRESN
should store all numeric test results or findings.
Standardized unit used for EGSTRESC or EGSTRESN.

Perm

Page 67
August 26, 2005

SDTMIG
4.1.5.1
SDTMIG
4.1.5.1

SDTMIG
4.1.5.1

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

EGSTAT

ECG Status

EGREASND

Type

**NOT
DONE

Origin

Role

CDISC Notes

Core

CRF or
Derived

Record
Qualifier

Used to indicate an ECG was not done, or an ECG measurement Perm
was not taken. Should be null if a result exists in EGORRES.

Reason ECG Not Performed Char

CRF or
Derived

Record
Qualifier

Describes why a measurement or test was not performed.
Examples: BROKEN EQUIPMENT or SUBJECT REFUSED.
Used in conjunction with EGSTAT when value is NOT DONE.

Perm

EGXFN

ECG External file Name

Char

Sponsor
Defined or
Derived

Record
Qualifier

File name for the external ECG Waveform file

Perm

EGNAM

Vendor Name

Char

CRF or
Derived

Record
Qualifier

Name or identifier of the laboratory or vendor who provides the Perm
test results.

EGLOINC

LOINC Code

Char

Derived

Synonym
Qualifier

1. LOINC Code for EGTEST. LOINC codes are available for
many but not all commonly used ECG test observations.
2. The LOINC version should be provided in the Sponsor
Comments column in the data definition document.

EGMETHOD

Method of ECG Test

Char

CRF

Record
Qualifier

Method of the ECG test. Examples: MONITORING (1-LEAD), Perm
12-LEAD.

EGBLFL

Baseline Flag

Char

**Y or Null CRF or
Derived

Record
Qualifier

Indicator used to identify a baseline value.

EGDRVFL

Derived Flag

Char

**Y or Null Derived

Record
Qualifier

Used to indicate a derived record. The value should be Y or null. Perm
Records which represent the average of other records or
questionnaire subscores, which do not come from the CRF are
examples of records which would be derived for the submission
datasets. If EGDRVFL=Y, then EGORRES should be NULL,
with EGSTRESC, and (if numeric) EGSTRESN having the
derived value.

EGEVAL

Evaluator

Char

CRF

Record
Qualifier

Role of the person who provided the evaluation. Used only for Exp
results that are subjective (e.g., assigned by a person or a group).
Should be null for records that contain collected or derived data.
Examples: INVESTIGATOR, ADJUDICATION COMMITTEE,
VENDOR.

VISIT

Visit Name

Char

CRF or
Derived

Timing

1. Protocol-defined description of clinical encounter.
2. May be used in addition to VISITNUM and/or VISITDY.

Page 68
August 26, 2005

Char

Controlled
Terms or
Format

Perm

Exp

Perm

CDISC, © 2005. All rights reserved
FINAL

References
SDTMIG
4.1.5.1

SDTMIG
4.1.3.2

SDTMIG
4.1.3.7
SDTMIG
4.1.3.7

SDTMIG 7.8;
SDTMIG
4.1.4.5

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

VISITNUM

Visit Number

Num

CRF or
Derived

Timing

VISITDY

Planned Study Day of Visit Num

CRF or
Derived

EGDTC

Date/Time of ECG

Char

EGDY

Study Day of ECG

CDISC Notes

Core
Req

SDTMIG 7.8;
4.1.4.5

Timing

Perm

SDTMIG 7.8;
SDTMIG
4.1.4.5

CRF or
Derived

Timing

Exp

SDTMIG
4.1.4.1

Num

Derived

Timing

1. Study day of the ECG, measured as integer days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics. This formula
should be consistent across the submission.

Perm

SDTMIG
4.1.4.4
SDTM 2.2.6

EGTPTNUM

Planned Time Point Number Num

CRF or
Derived

Timing

Numerical version of EGTPT to aid in sorting.

Perm

EGTPT

Planned Time Point Name

Char

CRF or
Derived

Timing

1. Text Description of time when measurement should be taken. Perm
2. This may be represented as an elapsed time relative to a fixed
reference point, such as time of last dose. See EGTPTNUM and
EGTPTREF. Examples: Start, 5 min post.

EGELTM

Elapsed Time from
Reference Point

Char

Derived

Timing

Elapsed time (in ISO 8601) relative to a planned fixed reference Perm
(EGTPTREF). This variable is useful where there are repetitive
measures. Not a clock time or a date time variable. Examples: 'P15M' to represent the period of 15 minutes prior to the reference
point indicated by EGTPTREF, or 'P8H' to represent the period of
8 hours after the reference point indicated by EGTPTREF.

EGTPTREF

Time Point Reference

Char

Sponsor
Defined

Timing

Name of the fixed reference point referred to by EGELTM,
Perm
EGTPTNUM, and EGTPT. Examples: Previous Dose, Previous
Meal.

ISO 8601

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

References

SDTMIG
4.1.4.3

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.1.1

Assumptions for ECG (EG) domain model
1. The method for QT interval correction is included in the test name by controlled terminology. The controlled terminology would be QTCF for
Fridericia and QTCB for Bazett in EGTESTCD. EGTEST would contain either 'QT interval correction Fridericia' or 'QT interval correction Bazett'.
The value of the calculated QT interval results goes into EGORRES.
2.

Although EGLOINC is included to allow use of LOINC codes for ECG tests where appropriate, other coding schemes may be recommended by the
CDISC terminology team in the future.

CDISC, © 2005. All rights reserved
FINAL

Page 69
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.2

Inclusion/Exclusion Exceptions — IE

ie.xpt, Inclusion/Exclusion Exceptions — Findings, Version 3.1.1, August 26, 2005. One record per inclusion/exclusion criteria exception per subject,
Tabulation
Variable Name

Variable Label

Controlled
Terms or
Format

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

IESEQ

Origin

Role

CDISC Notes

Core

References

CRF

Identifier

Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier

Two-character abbreviation for the domain most relevant to Req
the observation.

SDTM 2.2.4

Char

Sponsor
Defined

Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a
dataset for a subject. Can be used to join related records.

Req

SDTM 2.2.4

IESPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

Sponsor-defined reference number. Perhaps pre-printed on Perm
the CRF as an explicit line identifier or defined in the
sponsor’s operational database. Example: Question number
on a questionnaire.

IETESTCD

Inclusion/Exclusion Criterion Char
Short Name

CRF

Topic

Short name of the criterion described in IETEST. It can be Req
used as a column name when converting a dataset from a
vertical to a horizontal format. The value in IETESTCD
cannot be longer than 8 characters, nor can it start with a
number (e.g.'1TEST'). IETESTCD cannot contain
characters other than letters, numbers, or underscores.
Examples: IN01, EX01.

IETEST

Inclusion/Exclusion Criterion Char

CRF

Synonym
Qualifier

Verbatim description of the inclusion or exclusion criterion Req
that was the exception for the subject within the study.

IECAT

Inclusion//Exclusion
Category

Char

**INCLUSION, Sponsor
EXCLUSION Defined

Grouping
Qualifier

Used to define a category of related records.

Req

SDTMIG 2.1

IESCAT

Inclusion//Exclusion
Subcategory

Char

Grouping
Qualifier

A further categorization of the exception criterion. Can be
used to distinguish criteria for a sub-study.

Perm

SDTMIG 2.1

Page 70
August 26, 2005

**IE

Sponsor
Defined

CDISC, © 2005. All rights reserved
FINAL

SDTM 2.2.4

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

IEORRES

I/E Criterion Original Result Char

**Y, N

CRF or
Derived

Result Qualifier Original response to Inclusion/Exclusion Criterion question. Req
Inclusion or Exclusion criterion met?

SDTMIG
4.1.5.1

IESTRESC

I/E Criterion Result in Std Char
Format

**Y, N

Derived

Result Qualifier Response to Inclusion/Exclusion criterion result in standard Req
format. (Same as IEORRES for the IE Domain).

SDTMIG
4.1.5.1

VISIT

Visit Name

Char

CRF or
Derived

Timing

1. Protocol-defined description of clinical encounter.
Perm
2. May be used in addition to VISITNUM and/or VISITDY.

SDTMIG 7.8;
SDTMIG
4.1.4.5

VISITNUM

Visit Number

Num

CRF or
Derived

Timing

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Perm

SDTMIG 7.8;
SDTMIG
4.1.4.5

VISITDY

Planned Study Day of Visit Num

CRF or
Derived

Timing

Perm

SDTMIG 7.8;
SDTMIG
4.1.4.5

IEDTC

Date/Time of Collection

Char

CRF or
Derived

Timing

Perm

SDTMIG
4.1.4.1

IEDY

Study Day of Collection

Num

Derived

Timing

1. Study day of collection of the inclusion/exclusion
Perm
exceptions, measured as integer days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics. This formula
should be consistent across the submission.

ISO 8601

SDTMIG
4.1.4.4
SDTM 2.2.5

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.2.1

Assumptions for Inclusion/Exclusion Exceptions (IE) domain model
1. The intent of the domain model is to only collect those criteria that cause the subject to be in violation of the Inclusion/Exclusion criteria not a
response to each criterion.
2.

This domain should not be used to collect protocol deviations/violations incurred during the course of the study. A separate domain model (DV,
available separately) will be developed for protocol deviations/violations in a future version of the Implementation Guide.

Note that the SQL statement query "select distinct IETESTCD from IE;” may not contain an exhaustive list of the inclusion / exclusion criteria
because this domain only lists those not met by subjects. The complete list would be found in the TI trial inclusion/exclusion criteria dataset
described in Section 7.9 .

CDISC, © 2005. All rights reserved
FINAL

Page 71
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.3

Laboratory Test Results — LB

lb.xpt, Labs — Findings, Version 3.1.1, August 26, 2005. One record per lab test per time point per visit per subject, Tabulation
Variable Name

Variable Label

Controlled
Terms or
Format

Type

STUDYID

Study Identifier

Char

DOMAIN

Domain Abbreviation

Char

USUBJID

Unique Subject Identifier

LBSEQ

Origin

Role

CDISC Notes

Core

References

CRF

Identifier Unique identifier for a study within the submission.

Req

SDTM 2.2.4

Derived

Identifier Two-character abbreviation for the domain most relevant to the
observation.

Req

SDTM 2.2.4

Char

Sponsor
Defined

Identifier Unique subject identifier within the submission.

Req

SDTM 2.2.4

Sequence Number

Num

CRF or
Derived

Identifier Sequence number given to ensure uniqueness within a dataset for a
subject. Can be used to join related records.

Req

SDTM 2.2.4

LBGRPID

Group ID

Char

Sponsor
Defined

Identifier Used to tie together a block of related records in a single domain to
support relationships within the domain and between domains.

Perm

SDTMIG 2.1;
SDTM 2.2.4

LBREFID

Specimen ID

Char

Sponsor
Identifier Internal or external specimen identifier. Example: Specimen ID.
Defined or
Derived

LBSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier Optional Sponsor-defined reference number. Perhaps pre-printed on Perm
the CRF as an explicit line identifier or defined in the sponsor’s
operational database. Example: Line number on the Lab page.

LBTESTCD

LAB Test or Examination
Short Name

Char

CRF or
Derived

Topic

LBTEST

LAB Test or Examination
Name

Char

CRF

Synonym Verbatim name of the test or examination used to obtain the
Qualifier measurement or finding. Note any test normally performed by a
clinical laboratory is considered a lab test. The value in LBTEST
cannot be longer than 40 characters. Examples: Alanine
Aminotransferase, Lactate Dehydrogenase.

Req

LBCAT

Category for Lab Test

Char

Sponsor
Defined

Grouping Used to define a category of related records. Examples: such as
Qualifier HEMATOLOGY, URINALYSIS, CHEMISTRY.

Exp

LBSCAT

Subcategory for Lab Test

Char

Sponsor
Defined

Grouping A further categorization of a test category such as DIFFERENTIAL, Perm
Qualifier COAGULATON, LIVER FUNCTION or ELECTROLYTES.

LBORRES

Result or Finding in Original Char
Units

CRF or
Derived

Result
Result of the measurement or finding as originally received or
Qualifier collected.

Page 72
August 26, 2005

**LB

Perm

SDTM 2.2.4

Short name of the measurement, test, or examination described in
Req
LBTEST. It can be used as a column name when converting a dataset
from a vertical to a horizontal format. The value in LBTESTCD
cannot be longer than 8 characters, nor can it start with a number
(e.g.'1TEST'). LBTESTCD cannot contain characters other than
letters, numbers, or underscores. Examples: ALT, LDH.

Exp

SDTMIG 2.1
SDTMIG 2.1.
SDTMIG 4.1.5.1

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Controlled
Terms or
Format

Type

LBORRESU

Original Units

Char

LBORNRLO

Reference Range Lower
Limit in Orig Unit

LBORNRHI

Reference Range Upper
Limit in Orig Unit

Origin

Role

CDISC Notes

Core

CRF or
Derived

Variable Original units in which the data were collected. The unit for
Qualifier LBORRES. Example: g/L.

Char

CRF or
Derived

Variable Lower end of reference range for continuous measurements in original Exp
Qualifier units. Should be populated only for continuous results.

Char

CRF or
Derived

Variable Upper end of reference range for continuous measurements in original Exp
Qualifier units. Should be populated only for continuous results.

LBSTRESC

Character Result/Finding in Char
Std Format

Derived

Result
Contains the result value for all findings, copied or derived from
Exp
Qualifier LBORRES in a standard format or standard units. LBSTRESC should
store all results or findings in character format; if results are numeric,
they should also be stored in numeric format in LBSTRESN. For
example, if a test has results 'NONE', 'NEG', and 'NEGATIVE' in
LBORRES and these results effectively have the same meaning, they
could be represented in standard format in LBSTRESC as
'NEGATIVE'. For other examples, see general assumptions.

LBSTNRC

Reference Range for Char
Rslt-Std Units

Char

CRF or
Derived

Variable For normal range values that are character in ordinal scale (e.g.,
Perm
Qualifier 'NEGATIVE TO TRACE', '-1 to +1', etc.). If categorical ranges were
supplied.

LBSTRESN

Numeric Result/Finding in
Standard Units

Num

Derived

Result
Used for continuous or numeric results or findings in standard format; Exp
Qualifier copied in numeric format from LBSTRESC. LBSTRESN should store
all numeric test results or findings.

LBSTRESU

Standard Units

Char

CRF or
Derived

Variable Standardized unit used for LBSTRESC or LBSTRESN.
Qualifier

Exp

LBSTNRLO

Reference Range Lower
Limit-Std Units

Num

CRF or
Derived

Variable Lower end of reference range for continuous measurements in
Qualifier standardized units. Should be populated only for continuous results.

Exp

LBSTNRHI

Reference Range Upper
Limit-Std Units

Num

CRF or
Derived

Variable Upper end of reference range for continuous measurements in
Qualifier standardized units. Should be populated only for continuous results.

Exp

LBNRIND

Reference Range Indicator

Char

CRF or
Derived

Variable 1. Indicates where value falls with respect to reference range defined Exp
Qualifier by LBORNRLO and LBORNRHI or by LBSTNRC. Examples:
NORMAL, ABNORMAL, HIGH, LOW.

Exp

References
SDTMIG 4.1.3.2

SDTMIG 4.1.5.1

2. Should not be used to indicate clinical significance.
LBSTAT

Lab Status

Char

LBREASND

Reason Test Not Done

Char

CDISC, © 2005. All rights reserved
FINAL

**NOT
DONE

CRF or
Derived

Record
Used to indicate exam not done. Should be null if a result exists in
Qualifier LBORRES.

Perm

CRF or
Derived

Record
Describes why a measurement or test was not performed such as
Qualifier BROKEN EQUIPMENT, SUBJECT REFUSED, or SPECIMEN
LOST. Used in conjunction with LBSTAT when value is NOT
DONE.

Perm

SDTMIG 4.1.5.1

Page 73
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Controlled
Terms or
Format

Type

LBNAM

Vendor Name

Char

LBLOINC

LOINC Code

Char

LBSPEC

Specimen Type

Char

LBSPCCND

Specimen Condition

Char

LBMETHOD

Method of Test or
Examination

Char

LBBLFL

Baseline Flag

LBDRVFL

Origin

Role

CDISC Notes

Core

References

CRF or
Derived

Record
Name or identifier of the laboratory or vendor who provides the test
Qualifier results.

Derived

Synonym 1. LOINC Code for LBTEST.
Perm
Qualifier 2. The LOINC version should be provided in the comments column in
the data definition file.

CRF

Record
Defines the type of specimen used for a measurement. Examples:
Qualifier SERUM, PLASMA, URINE.

CRF

Record
Free or standardized text describing the condition of the specimen e.g. Perm
Qualifier HEMOLYZED, ICTERIC, LIPEMIC etc.

CRF

Record
Method of the test or examination. Examples EIA (Enzyme
Qualifier Immunoassay), ELECTROPHORESIS, DIPSTICK

Perm

Char

**Y or Null

CRF or
Derived

Record
Indicator used to identify a baseline value.
Qualifier

Exp

Derived Flag

Char

**Y or Null

CRF or
Derived

Record
Used to indicate a derived record. The value should be Y or null.
Perm
Qualifier Records which represent the average of other records or questionnaire
subscores, which do not come from the CRF, are examples of records
which would be derived for the submission datasets. If LBDRVFL=Y,
then LBORRES should be NULL, with LBSTRESC, and (if numeric)
LBSTRESN having the derived value.

LBFAST

Fasting Status

Char

**Y, N, U or CRF
Null

Record
Indicator used to identify fasting status such as Y, N, U, or null if not Perm
Qualifier relevant.

LBTOX

Toxicity

Char

Derived

Variable Description of toxicity quantified by LBTOXGR. Sponsor should
Qualifier specify which scale and version is used in sponsor comments.
Example: NCI CTCAE short name

LBTOXGR

Standard Toxicity Grade

Char

CRF or
Derived

Variable Records toxicity grade value using a standard toxicity scale (such as Perm
Qualifier the NCI CTCAE). Value should contain valid numbers only; datatype
will be changed to numeric in future version of SDTM.

VISIT

Visit Name

Char

CRF or
Derived

Timing

1. Protocol-defined description of clinical encounter
2.May be used in addition to VISITNUM and/or VISITDY

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITNUM

Visit Number

Num

CRF or
Derived

Timing

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Req

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITDY

Planned Study Day of Visit Num

CRF or
Derived

Timing

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

LBDTC

Date/Time of Specimen
Collection

CRF or
Derived

Timing

Exp

SDTMIG 4.1.4.1

Page 74
August 26, 2005

Char

ISO 8601

Perm
SDTMIG 4.1.3.2

Perm

SDTMIG 4.1.3.7
SDTMIG 4.1.5.1
SDTMIG 4.1.3.7

Perm

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

LBENDTC

End Date/Time of Specimen Char
Collection

LBDY

Study Day of Specimen
Collection

LBTPT

Planned Time Point Name

Controlled
Terms or
Format

Role

CDISC Notes

Core

References

CRF or
Derived

Timing

Perm

SDTMIG 4.1.4.1
SDTMIG 4.1.4.8

Num

Derived

Timing

1. Study day of specimen collection, measured as integer days.
Perm
2. Algorithm for calculations must be relative to the sponsor-defined
RFSTDTC variable in Demographics. This formula should be
consistent across the submission.

SDTMIG 4.1.4.4

Char

CRF or
Derived

Timing

1. Text Description of time when specimen should be taken.
2. This may be represented as an elapsed time relative to a fixed
reference point, such as time of last dose. See LBTPTNUM and
LBTPTREF. Examples: Start, 5 min post.

Perm

LBTPTNUM

Planned Time Point Number Num

CRF or
Derived

Timing

Numerical version of LBTPT to aid in sorting.

Perm

LBELTM

Elapsed Time from
Reference Point

Derived

Timing

Elapsed time (in ISO 8601) relative to a planned fixed reference
(LBTPTREF).. This variable is useful where there are repetitive
measures. Not a clock time or a date time variable. Examples: '-

Perm

Char

ISO 8601

Origin

ISO 8601

SDTMIG 4.1.4.3

P15M' to represent the period of 15 minutes prior to the
reference point indicated by LBTPTREF, or 'P8H' to represent
the period of 8 hours after the reference point indicated by
LBTPTREF.
LBTPTREF

Time Point Reference

Char

Sponsor
Defined

Timing

Name of the fixed reference point referred to by LBELTM,
LBTPTNUM, and LBTPT. Examples: PREVIOUS DOSE,
PREVIOUS MEAL.

Perm

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.3.1

Assumptions for Laboratory Test Results (LB) domain model
1. For lab tests that do not have continuous numeric results (e.g., urine protein as measured by dipstick, descriptive tests such as urine color),
LBSTNRC could be populated either with normal range values that are character in an ordinal scale (e.g., 'NEGATIVE to TRACE') or a delimited
set of values that are considered to be normal (e.g., 'YELLOW’, ‘AMBER'). LBORNRLO, LBORNRHI, LBSTNRLO, and LBSTNRHI should be
null for these type of tests.
2.

For lab tests where the specimen is collected over time, i.e., 24-hour urine collection, the start date/time of the collection goes into LBDTC and the
end date/time of collection goes into LBENDTC.

CDISC, © 2005. All rights reserved
FINAL

Page 75
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.4

Physical Examinations — PE

pe.xpt, Physical Examination — Findings, Version 3.1.1, August 26, 2005. One record per body system or abnormality per visit per subject, Tabulation
Variable Name
STUDYID
DOMAIN

Variable Label

Type

Controlled
Terms or
Format

Origin

Core

References

Char
Char

USUBJID

Unique Subject Identifier

Char

PESEQ

Sequence Number

Num

PEGRPID

Group ID

Char

Sponsor Defined Identifier

Used to tie together a block of related records in a single
Perm
domain to support relationships within the domain and between
domains.

SDTMIG 2.1;
SDTM 2.2.4

PESPID

Sponsor-Defined Identifier Char

Sponsor Defined Identifier

Perm

SDTM 2.2.4

PETESTCD

Body System Examined
Short Name

Char

CRF or Derived

Topic

PETEST

Body System Examined

Char

CRF

Synonym
Qualifier

PEMODIFY

Modified Reported Term

Char

Sponsor Defined Synonym
Qualifier

Sponsor-defined reference number. Perhaps pre-printed on the
CRF as an explicit line identifier or defined in the sponsor’s
operational database. Example: Question number on a
questionnaire.
Topic variable for PE. Short name for the value in PETEST,
which can be used as a column name when converting the
dataset from a vertical format to a horizontal format. The short
names can be up to 8 characters. Examples: CV, GI. For
subject-level exam, value should be 'ALL'.
Verbatim term part of the body examined. The value in
PETEST cannot be longer than 40 characters. Examples:
CARDIOVASCULAR and GASTROINTESTINAL. For
subject-level exam, value should be 'ALL'.
If PEORRES is modified as part of a defined procedure, then
PEMODIFY will contain the modified text.

Perm

SDTMIG 4.1.3.6

PECAT

Category for Examination

Char

Sponsor Defined Grouping
Qualifier

Used to define a category of examination. Examples:
GENERAL, NEUROLOGICAL.

Perm

SDTMIG 2.1

PESCAT

Subcategory for
Examination

Char

Sponsor Defined Grouping
Qualifier

A further categorization of the examination. Used if needed to Perm
add further detail to PECAT.

SDTMIG 2.1

PELOC

Location of Physical Exam Char
Finding

CRF or Sponsor Record
Defined
Qualifier

Can be used to specify where a physical exam finding occurred. Perm
Example: LEFT ARM for skin rash.

Page 76
August 26, 2005

Identifier
Identifier

CDISC Notes

Study Identifier
Domain Abbreviation

**PE

CRF
Derived

Role

Unique identifier for a study within the submission.
Req
Two-character abbreviation for the domain most relevant to the Req
observation.

SDTM 2.2.4
SDTM 2.2.4

Sponsor Defined Identifier

Unique subject identifier within the submission.

Req

SDTM 2.2.4

CRF or Derived

Sequence number given to ensure uniqueness within a dataset
for a subject. Can be used to join related records.

Req

SDTM 2.2.4

Identifier

Req

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

PEBODSYS

Body System or Organ
Class

Char

PEORRES

Verbatim Examination
Finding

PEORRESU

Original Units

PESTRESC

Controlled
Terms or
Format

Role

CDISC Notes

Core

References

CRF or Derived

Result
Qualifier

1. Body system or organ class (Primary SOC) that is involved in Perm
an event or measurement from the standard hierarchy (e.g.,
MedDRA).
2. May be predefined from CRF page or obtained from coding.

SDTMIG 4.1.3.5

Char

CRF or Derived

Result
Qualifier

Text description of any abnormal findings. If the examination Exp
was completed and there were no abnormal findings, the value
should be NORMAL. If the examination was not performed on
a particular body system, or at the subject level, then the value
should be null, and NOT DONE should appear in PESTAT.

SDTMIG 4.1.5.1

Char

CRF or Derived

Variable
Qualifier

Original units in which the data were collected. The unit for
PEORRES.

Perm

Character Result/Finding in Char
Std. Format

Derived

Result
Qualifier

If there are findings for a body system, then either the
dictionary preferred term (if findings are coded using a
dictionary) or PEORRES (if findings are not coded) should
appear here. If PEORRES is null, PESTRESC should be null

Exp

SDTMIG 4.1.5.1

PESTRESN

Numeric Result/Finding in Num
Standard Units

Derived

Result
Qualifier

Used for continuous or numeric results or findings in standard Exp
format; copied in numeric format from PESTRESC.
PESTRESN should store all numeric test results or findings.

SDTMIG 4.1.5.1

PESTRESU

Standard Units

Char

Derived

Variable
Qualifier

Standardized unit used for PESTRESC or PESTRESN.

Exp

PESEV

Severity/Intensity

Char

CRF

Record
Qualifier

The severity or intensity of the exam finding. PESEV is only
used to qualify the results of an observation -- it should not be
used to record the answer to the question posed in PETEST..
Example: “MODERATE” could be used to describe a
PEORRES of “ACNE”.

Perm

PESTAT

Examination Status

Char

**NOT
DONE

CRF or Derived

Record
Qualifier

Used to indicate exam not done. Should be null if a result exists Perm
in ORRES.

PEREASND

Reason Not Examined

Char

CRF or Derived

Record
Qualifier

Describes why an examination was not performed or why a
body system was not examined. Example: SUBJECT
REFUSED. Used in conjunction with STAT when value is
NOT DONE.

CDISC, © 2005. All rights reserved
FINAL

Origin

SDTMIG 4.1.5.1

Perm

Page 77
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

PEBLFL

Baseline Flag

Char

**Y or Null CRF or Derived

Record
Qualifier

Indicator used to identify a baseline value.

PEEVAL

Evaluator

Char

CRF

Record
Qualifier

Role of the person who provided the evaluation. Used only for Perm
results that are subjective (e.g., assigned by a person or a
group). Should be null for records that contain collected or
derived data. Examples: INVESTIGATOR, ADJUDICATION
COMMITTEE, VENDOR.

VISIT

Visit Name

Char

CRF or Derived

Timing

1. Protocol-defined description of clinical encounter.
2. May be used in addition to VISITNUM and/or VISITDY.

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITNUM

Visit Number

Num

CRF or Derived

Timing

1. Clinical encounter number.
2. Numeric version of VISIT, used for sorting.

Exp

SDTMIG 7.8;
SDTMIG 4.1.4.5

VISITDY

Planned Study Day of Visit Num

CRF or Derived

Timing

Perm

SDTMIG 7.8;
SDTMIG 4.1.4.5

PEDTC

Date/Time of Examination Char

CRF or Derived

Timing

Exp

SDTMIG 4.1.4.1

PEDY

Study Day of Examination Num

Derived

Timing

Perm

SDTMIG 4.1.4.4

ISO 8601

1. Study day of physical exam, measured as integer days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics. This formula
should be consistent across the submission.

Exp

References
SDTMIG 4.1.3.7

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.4.1

Assumptions for Physical Examinations (PE) domain model
1. The PE domain provides an example where the result, PEORRES, is coded. This is in contrast to other domains (e.g., AE, CM, and MH), in which
the topic variable (AETERM, CMTRT, and EXTRT, respectively) is the one coded.

Page 78
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.5

Questionnaires — QS

qs.xpt, Questionnaires — Findings, Version 3.1.1, August 26, 2005. One record per question per time point per visit per subject, Tabulation
Variable Name

Variable Label

Controlled
Terms or
Format

Type

Origin

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char

USUBJID

Unique Subject Identifier

Char

QSSEQ

Sequence Number

Num

QSGRPID

Group ID

Char

QSSPID

Sponsor-Defined Identifier

Char

QSTESTCD

Question Short Name

Char

QSTEST

Question Name

Char

QSCAT

Category of Question

Char

Sponsor
Defined

QSSCAT

Subcategory for Question

Char

Sponsor
Defined

QSORRES

Finding in Original Units

Char

QSORRESU

Original Units

Char

CDISC, © 2005. All rights reserved
FINAL

**QS

CRF
Derived
Sponsor
Defined
CRF or
Derived
Sponsor
Defined
Sponsor
Defined

CRF or
Derived

CRF or
Derived
CRF or
Derived

Role

CDISC Notes

Core

References

Identifier Unique identifier for a study within the submission.
Identifier Two-character abbreviation for the domain most relevant to the
observation.
Identifier Unique subject identifier within the submission.

Req
Req

SDTM 2.2.4
SDTM 2.2.4

Req

SDTM 2.2.4

Identifier Sequence number given to ensure uniqueness within a domain.

Req

SDTM 2.2.4

Identifier Used to tie together a block of related records in a single domain to Perm
support relationships within the domain and between domains.
Identifier Optional Sponsor-defined reference number. Perhaps pre-printed on Perm
the CRF as an explicit line identifier or defined in the sponsor’s
operational database. Example: Question number on a
questionnaire.
Topic
Topic variable for QS. Short name for the value in QSTEST, which Req
can be used as a column name when converting the dataset from a
vertical format to a horizontal format. The value in QSTESTCD
cannot be longer than 8 characters, nor can it start with a number
(e.g.'1TEST'). QSTESTCD cannot contain characters other than
letters, numbers, or underscores. Examples: COG01, GH1, PF1.
Synonym Verbatim name of the question or group of questions used to obtain Req
Qualifier the measurement or finding. The value in QSTEST cannot be longer
than 40 characters. Examples: In General, Would You Say your
Health Is.
Grouping Used to define a category of related records that will be meaningful Req
Qualifier to the Reviewer. Examples: HAMILTON DEPRESSION SCLAE,
SF36, ADAS.
Grouping A further categorization of the questions within the category.
Perm
Qualifier Examples: MENTAL HEALTH DOMAIN, DEPRESSION
DOMAIN, WORD RECALL.
Result
Finding as originally received or collected (e.g. RARELY,
Exp
Qualifier SOMETIMES).
Variable Original units in which the data were collected. The unit for
Perm
Qualifier QSORRES, such as minutes or seconds or the units associated with
a visual analog scale.

SDTMIG 2.1;
SDTM 2.2.4
SDTM 2.2.4

SDTMIG 2.1
SDTMIG 2.1
SDTMIG 4.1.5.1

Page 79
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Controlled
Terms or
Format

Type

Origin

QSSTRESC

Character Result/Finding in Char
Std Format

CRF or
Derived

QSSTRESN

Numeric Finding in Standard Num
Units

Derived

QSSTRESU

Standard Units

Char

QSSTAT

Status of Question

Char

**NOT
DONE

QSREASND

Reason Not Performed

Char

QSBLFL

Baseline Flag

Char

**Y or Null

QSDRVFL

Derived Flag

Char

**Y or Null

VISIT

Visit Name

Char

VISITNUM

Visit Number

Num

VISITDY

Planned Study Day of Visit Num

QSDTC

Date/Time of Finding

Char

QSDY

Study Day of Finding

Num

QSTPT

Planned Time Point Name

Char

Page 80
August 26, 2005

ISO 8601

CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived

CRF or
Derived
CRF or
Derived
CRF or
Derived
CRF or
Derived
Derived

CRF or
Derived

Role

CDISC Notes

Core

Result
Contains the finding for all questions or sub-scores, copied or
Exp
Qualifier derived from QSORRES in a standard format or standard units.
QSSTRESC should store all findings in character format; if findings
are numeric, they should also be stored in numeric format in
QSSTRESN. If question scores are derived from the original
finding, then the standard format is the score. Examples: 0, 1.
Result
Used for continuous or numeric findings in standard format; copied Perm
Qualifier in numeric format from QSSTRESC. QSSTRESN should store all
numeric results or findings.
Variable Standardized unit used for QSSTRESC or QSSTRESN.
Perm
Qualifier
Record
Used to indicate a questionnaire or response to a questionnaire was Perm
Qualifier not done. Should be null if a result exists in QSORRES.
Record
Describes why a question was not answered. Example: subject
Perm
Qualifier refused. Used in conjunction with QSSTAT when value is NOT
DONE.
Record
Indicator used to identify a baseline value.
Exp
Qualifier
Record
The value should be Y or null. Records which represent the average Perm
Qualifier of other records or questionnaire sub-scores which do not come
from the CRF are examples of records which would be derived for
the submission datasets. If QSDRVFL=Y, then QSORRES should
be NULL, with QSSTRESC and (if numeric) QSSTRESN having
the derived value.
Timing
1. Protocol-defined description of clinical encounter.
Perm
2. May be used in addition to VISITNUM and/or VISITDY.
Timing
1. Clinical encounter number.
Exp
2. Numeric version of VISIT, used for sorting.
Timing
Perm
Timing
Timing

Timing

Exp
1. Study day of finding collection, measured as integer days.
Perm
2. Algorithm for calculations must be relative to the sponsor-defined
RFSTDTC variable in Demographics. This formula should be
consistent across the submission.
1. Text Description of time when questionnaire is administered.
Perm
2. This may be represented as an elapsed time relative to a fixed
reference point, such as time of last dose. See QSTPTNUM and
QSTPTREF.

References
SDTMIG 4.1.5.1

SDTMIG 4.1.5.1

SDTMIG 4.1.3.7
SDTMIG 4.1.5.1
SDTMIG 4.1.3.7

SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.5
SDTMIG 4.1.4.
SDTMIG 4.1.4.4

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable Name

Variable Label

Type

QSTPTNUM

Planned Time Point Number Num

QSELTM

Elapsed Time from
Reference Point

Char

Controlled
Terms or
Format

ISO 8601

Origin
CRF or
Derived
Derived

Role

CDISC Notes

Core

Timing

Numerical version of QSTPT to aid in sorting.

Perm

Timing

Elapsed time (in ISO 8601) relative to a planned fixed reference
(QSTPTREF). This variable is useful where there are repetitive
measures. Not a clock time or a date time variable. Examples: '-

Perm

References

SDTMIG 4.1.4.3

P15M' to represent the period of 15 minutes prior to the
reference point indicated by QSTPTREF, or 'P8H' to
represent the period of 8 hours after the reference point
indicated by QSTPTREF.
QSTPTREF

Time Point Reference

Char

QSEVLINT

Evaluation Interval

Char

ISO 8601

Sponsor
Defined

Timing

CRF or
Derived

Timing

Name of the fixed reference point referred to by QSELTM,
Perm
QSTPTNUM, and QSTPT. Examples: PREVIOUS DOSE,
PREVIOUS MEAL.
Evaluation Interval associated with a QSTEST question represented Perm
in ISO 8601 character format. Example: "P2Y" to represent an
interval of 2 years in the question "Have you experienced any
episodes in the past 2 years?"

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.5.1
Assumptions for Questionnaire (QS) domain model
1. Questionnaire data may include, but are not limited to the following: subject reported outcomes, validated or non-validated questionnaires, and validated
or non-validated diaries (i.e., data with a common topicality). When objective numeric data with result qualifiers are collected in a questionnaire or
diary format, the sponsor should consider whether this data actually belongs in a separate (new) domain. It is realized that questionnaires may include
some objective questions and some of these may trigger additional data collection in other domains.
2. The names of the questionnaires should be described under the variable QSCAT in the questionnaire domain. For example, ADAS for Alzheimer's
Disease Assessment Scale, SF36 for SF-36 Health Survey, PANSS for Positive and Negative Syndrome Scale, etc.
3. Names of categories/subcategories for groups of items/questions should be described under QSSCAT.
Derived information such as, total scores, and sub scores, etc, should be stored in the QS domain as derived records with appropriate
category/subcategory names (QSCAT/QSSCAT), item names (QSTESTCD/QSTEST), and results (QSSTRESN/QSSTRESC). Derived records should
be flagged by QSDRVFL.
.

CDISC, © 2005. All rights reserved
FINAL

Page 81
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.6

Subject Characteristics — SC

sc.xpt, Subject Characteristics — Findings, Version 3.1.1, August 26, 2005. One record per characteristic per subject, Tabulation
Variable
Name

Variable Label

Type

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char

USUBJID

Unique Subject Identifier

SCSEQ

Controlled
Terms or
Format

Origin

Role

CDISC Notes

Core

References

Unique identifier for a study within the submission.
Two-character abbreviation for the domain most relevant to the
observation.
Unique subject identifier within the submission.

Req
Req

SDTM 2.2.4
SDTM 2.2.4

Req

SDTM 2.2.4

CRF
Derived

Identifier
Identifier

Char

Sponsor
Defined

Identifier

Sequence Number

Num

CRF or
Derived

Identifier

Sequence number given to ensure uniqueness within a dataset for a
subject. Can be used to join related records.

Req

SDTM 2.2.4

SCGRPID

Group ID

Char

Sponsor
Defined

Identifier

Used to tie together a block of related records in a single domain to
support relationships within the domain and between domains.

Perm

SDTMIG 2.1;
SDTM 2.2.4

SCSPID

Sponsor-Defined Identifier

Char

Sponsor
Defined

Identifier

SDTM 2.2.4

SCTESTCD

Subject Characteristic Short Char
Name

CRF or
Derived

Topic

Sponsor-defined reference number. Perhaps pre-printed on the CRF as Perm
an explicit line identifier or defined in the sponsor’s operational
database. Example: Question number on a questionnaire.
Short name of the measurement, test, or examination described in
Req
SCTEST. It can be used as a column name when converting a dataset
from a vertical to a horizontal format. The value in SCTESTCD cannot
be longer than 8 characters, nor can it start with a number (e.g.'1TEST').
SCTESTCD cannot contain characters other than letters, numbers, or
underscores. Example: SUBJINIT, EYECD.

SCTEST

Subject Characteristic

Char

CRF

Synonym
Qualifier

SCCAT

Category for Subject
Characteristic

Char

Sponsor
Defined

Grouping
Qualifier

SCSCAT

Subcategory for Subject
Characteristic

Char

Sponsor
Defined
CRF or
Derived
CRF or
Derived

Result or Finding in Original Char
Units
SCORRESU Original Units
Char

**SC

SCORRES

Page 82
August 26, 2005

Verbatim name of the test or examination used to obtain the
Req
measurement or finding. The value in SCTEST cannot be longer than
40 characters. Examples: Subject Initials, Eye Color.
Used to define a category of related records.
Perm

SDTMIG 2.1

Grouping
Qualifier

A further categorization of the subject characteristic.

Perm

SDTMIG 2.1

Result
Qualifier
Variable
Qualifier

Result of the subject characteristic as originally received or collected.

Exp

SDTMIG 4.1.5.1

Original Unit in which the data were collected. The unit for
SCORRES.

Perm

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable
Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

SCSTRESC

Character Result/Finding in Char
Std Format

Derived

Result
Qualifier

SCSTRESN

Numeric Result/Finding in
Standard Units

Num

Derived

Result
Qualifier

SCSTRESU

Standard Units

Char

SCSTAT

Status of SC Measurement

Char

**NOT
DONE

CRF or
Derived
CRF or
Derived

Variable
Qualifier
Record
Qualifier

CRF or
Derived

Record
Qualifier

CRF or
Derived
Derived

Timing

SCREASND Reason Not Performed

Char

SCDTC

Date/Time of Collection

Char

SCDY

Study Day of Examination

Num

ISO 8601

Timing

CDISC Notes

Core

References

Contains the result value for all findings, copied or derived from
Exp SDTMIG 4.1.5.1
SCORRES in a standard format or standard units. SCSTRESC should
store all results or findings in character format; if results are numeric,
they should also be stored in numeric format in SCSTRESN. For
example, if a test has results 'NONE', 'NEG', and 'NEGATIVE' in
SCORRES and these results effectively have the same meaning, they
could be represented in standard format in SCSTRESC as
'NEGATIVE'. For other examples, see general assumptions.
Used for continuous or numeric results or findings in standard format; Perm SDTMIG 4.1.5.1
copied in numeric format from SCSTRESC. SCSTRESN should store
all numeric test results or findings.
Standardized unit used for SCSTRESC or SCSTRESN.
Perm
Used to indicate that the measurement was not done. Should be null if a Perm SDTMIG 4.1.5.1
result exists in SCORRES.
Describes why a question was not answered. Example: subject refused. Perm
Used in conjunction with SCSTAT when value is NOT DONE.
Exp
1. Study day of collection, measured as integer days.
2. Algorithm for calculations must be relative to the sponsor-defined
RFSTDTC variable in Demographics. This formula should be
consistent across the submission.

SDTMIG 4.1.4.1

Perm SDTMIG 4.1.4.4

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.
6.3.6.1
Assumptions for Subject Characteristics (SC) domain model
1. Subject Characteristics is for data not collected in other domains that is subject-related. Examples: subject initials, other race details, eye color,
childbearing status, etc.
2. The structure for demographic data is fixed and includes date of birth, age, sex , race, ethnicity and country. The structure of subject characteristics is
based on the Findings general class and is an extension of the demographics data. Subject Characteristics consists of data that is collected once per
subject (per test) and that is not expected to change during the trial. Subject characteristics contains data such as additional information about race,
subject initials, economic information, and eye color.

CDISC, © 2005. All rights reserved
FINAL

Page 83
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

6.3.7

Vital Signs — VS

vs.xpt, Vital Signs — Findings, Version 3.1.1, August 26, 2005. One record per vital sign measurement per time point per visit per subject, Tabulation
Variable
Name

Variable Label

Type

Controlled
Terms or
Format

Origin

STUDYID
DOMAIN

Study Identifier
Domain Abbreviation

Char
Char

USUBJID
VSSEQ

Unique Subject Identifier
Sequence Number

Char
Num

Sponsor Defined
CRF or Derived

VSGRPID

Group ID

Char

Sponsor Defined

VSSPID

Sponsor-Defined Identifier

Char

Sponsor Defined

**VS

CRF
Derived

VSTESTCD Vital Signs Test Short Name Char

CRF or Derived

VSTEST

Vital Signs Test Name

Char

CRF

VSCAT

Category for Vital Signs

Char

Sponsor Defined

VSSCAT

Subcategory for Vital Signs Char

Sponsor Defined

Page 84
August 26, 2005

Role
Identifier
Identifier

CDISC Notes

Core

Unique identifier for a study within the submission.
Two-character abbreviation for the domain most relevant to the
observation.
Identifier Unique subject identifier within the submission.
Identifier Sequence number given to ensure uniqueness within a dataset for
a subject. Can be used to join related records.
Identifier Used to tie together a block of related records in a single domain
to support relationships within the domain and between domains.
Identifier Optional Sponsor-defined reference number. Perhaps pre-printed
on the CRF as an explicit line identifier or defined in the
sponsor’s operational database.
Topic
Short name of the measurement, test, or examination described in
VSTEST. It can be used as a column name when converting a
dataset from a vertical to a horizontal format. The value in
VSTESTCD cannot be longer than 8 characters, nor can it start
with a number (e.g.'1TEST'). VSTESTCD cannot contain
characters other than letters, numbers, or underscores. Examples:
SYSBP, DIABP, BMI.
Synonym Verbatim name of the test or examination used to obtain the
Qualifier measurement or finding. The value in VSTEST cannot be longer
than 40 characters. Examples: Systolic Blood Pressure, Diastolic
Blood Pressure, Body Mass Index.
Grouping Used to define a category of related records.
Qualifier
Grouping A further categorization of a measurement or examination.
Qualifier

Reference

Req
Req

SDTM 2.2.4
SDTM 2.2.4

Req
Req

SDTM 2.2.4
SDTM 2.2.4

Perm

SDTMIG 2.1;
SDTM 2.2.4

Perm
Req

Req

SDTMIG 2.1

Perm

SDTMIG 2.1

Perm

SDTMIG 2.1

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable
Name

Variable Label

Type

VSPOS

Vital Signs Position of
Char
Subject
VSORRES
Result or Finding in Original Char
Units
VSORRESU Original Units
Char

Controlled
Terms or
Format
*

Origin
CRF or Derived
CRF or Derived

CRF or Derived

Role
Record
Qualifier
Result
Qualifier
Variable
Qualifier

VSSTRESC

Character Result/Finding in Char
Std Format

Derived

Result
Qualifier

VSSTRESN

Numeric Result/Finding in
Standard Units

Num

Derived

Result
Qualifier

VSSTRESU

Standard Units

Char

CRF or Derived

VSNRIND

Reference Range Indicator

Char

CRF or Derived

Variable
Qualifier
Variable
Qualifier

VSSTAT

Vitals Status

Char

**NOT
DONE

CRF or Derived

VSREASND Reason Not Performed

Char

VSLOINC

LOINC Code

Char

Derived

VSLOC

Location of Vital Signs
Measurement

Char

CRF or Derived

CDISC, © 2005. All rights reserved
FINAL

CRF or Derived

CDISC Notes

Core

Position of the subject during a measurement or examination.
Perm
Examples: SUPINE, STANDING, SITTING.
Result of the vital signs measurement as originally received or
Exp
collected.
Original units in which the data were collected. The unit for
Exp
VSORRES. Examples: INCHES, FEET, POUNDS, BEATS PER
MINUTE.
Contains the result value for all findings, copied or derived from Exp
VSORRES in a standard format or standard units. VSSTRESC
should store all results or findings in character format; if results
are numeric, they should also be stored in numeric format in
VSSTRESN. For example, if a test has results 'NONE', 'NEG', and
'NEGATIVE' in VSORRES and these results effectively have the
same meaning, they could be represented in standard format in
VSSTRESC as 'NEGATIVE'. For other examples, see general
assumptions.
Used for continuous or numeric results or findings in standard
Exp
format; copied in numeric format from VSSTRESC. VSSTRESN
should store all numeric test results or findings.
Standardized unit used for VSSTRESC or VSSTRESN.
Exp

1. Indicates where value falls with respect to reference range
(which could be defined by VSORNRLO and VSORNRHI or by
VSSTNRC (if those variables are used). Examples: NORMAL,
ABNORMAL, HIGH, LOW.
2. Should not be used to indicate clinical significance.
Record
Used to indicate that a vital sign measurement was not done.
Qualifier Should be null if a result exists in VSORRES.
Record
Describes why a measurement or test was not performed.
Qualifier Examples: BROKEN EQUIPMENT or SUBJECT REFUSED.
Used in conjunction with VSSTAT when value is NOT DONE.
Synonym 1. LOINC Code for VSTEST.
Qualifier 2. The LOINC version should be provided in the Sponsor
Comments column in the data definition document.
Record
Location relevant to the collection of Vital Signs measurement.
Qualifier Example: LEFT ARM for blood pressure.

Reference

SDTMIG
4.1.5.1

SDTMIG 4.1.5.1
SDTMIG 4.1.5.1

Perm

Perm
Perm

SDTMIG
4.1.5.1
SDTMIG 4.1.5.1

Perm

SDTMIG 4.1.3.2

Perm

SDTMIG 4.1.3.7

Page 85
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Variable
Name

Variable Label

Type

Controlled
Terms or
Format

Origin

Role

VSBLFL

Baseline Flag

Char

**Y or Null CRF or Derived

VSDRVFL

Derived Flag

Char

**Y or Null Derived

VISIT

Visit Name

Char

CRF or Derived

Timing

VISITNUM

Visit Number

Num

CRF or Derived

Timing

VISITDY

Planned Study Day of Visit Num

CRF or Derived

Timing

VSDTC
VSDY

Date/Time of Measurements Char
Study Day of Vital Signs
Num

CRF or Derived
Derived

Timing
Timing

VSTPT

Planned Time Point Name

CRF or Derived

Timing

CRF or Derived
Derived

Timing
Timing

ISO 8601

Char

VSTPTNUM Planned Time Point Number Num
VSELTM
Elapsed Time from
Char
Reference Point

ISO 8601

Record
Qualifier
Record
Qualifier

CDISC Notes

Core

Indicator used to identify a baseline value

Exp

Used to indicate a derived record. The value should be Y or null. Perm
Records which represent the average of other records or
questionnaire sub-scores which do not come from the CRF are
examples of records which would be derived for the submission
datasets. If VSDRVFL=Y, then VSORRES should be NULL,
with VSSTRESC and (if numeric) VSSTRESN having the derived
value.
1. Protocol-defined description of clinical encounter.
Perm
2. May be used in addition to VISITNUM and/or VISITDY.
1. Clinical encounter number.
Req
2. Numeric version of VISIT, used for sorting.
Perm
1. Study day of vital signs measurements, measured as integer
days.
2. Algorithm for calculations must be relative to the sponsordefined RFSTDTC variable in Demographics. This formula
should be consistent across the submission.
1. Text Description of time when measurement should be taken.
2. This may be represented as an elapsed time relative to a fixed
reference point, such as time of last dose. See VSTPTNUM and
VSTPTREF. Examples: Start, 5 min post.
Numerical version of VSTPT to aid in sorting.
Elapsed time (in ISO 8601) relative to a planned fixed reference
(VSTPTREF). This variable is useful where there are repetitive
measures. Not a clock time or a date time variable. Examples: '-

Exp
Perm

Reference
SDTMIG 4.1.3.7
SDTMIG 4.1.5.1
SDTMIG 4.1.3.7

SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 7.8;
SDTMIG 4.1.4.5
SDTMIG 4.1.4.1
SDTMIG 4.1.4.4

Perm

Perm
Perm

SDTMIG 4.1.4.3

P15M' to represent the period of 15 minutes prior to the
reference point indicated by VSTPTREF, or 'P8H' to
represent the period of 8 hours after the reference point
indicated by VSTPTREF.
VSTPTREF

Time Point Reference

Char

Sponsor Defined

Timing

Name of the fixed reference point referred to by VSELTM,
VSTPTNUM, and VSTPT. Examples: PREVIOUS DOSE,
PREVIOUS MEAL.

Perm

* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external controlled terminology.

Page 86
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7 Trial Design Datasets
7.1

INTRODUCTION

The Trial Design Model, which is included in the SDTM, allows description of key aspects of the planned conduct
of a clinical trial in a standardized way. These standardized descriptions will allow reviewers to:
•

clearly and quickly grasp the design of a clinical trial

•

compare the designs of different trials

•

search a data warehouse for clinical trials with certain features

•

compare planned and actual treatments and visits for subjects in a clinical trial.

Modeling a clinical trial in this standardized way requires the explicit statement of certain decision rules that may
not be addressed or may remain vague or ambiguous in the usual prose protocol document. Prospective modeling of
the design of a clinical trial should lead to a clearer, better protocol. Retrospective modeling of the design of a
clinical trial should ensure a clear description of how the trial was interpreted by the sponsor.
The aspects of clinical trial design currently included in the Trial Design Model are as follows:
•

the planned arms of the trial

•

what happens to a subject in each arm (i.e., what series of treatment and non-treatment time periods [trial
Elements] are planned for a subject assigned to that arm)

•

the planned schedule of visits

•

the inclusion and exclusion criteria for the trial.

Future versions of the Trial Design Model are expected to include additional aspects of clinical trials, such as
planned exposures and planned assessments.
The Trial Design Model is built upon the concepts of Elements, Arms, Epochs and Visits. An Element is the basic
building block for time within a clinical trial, and has the following characteristics:
•

A description of what happens to the subject during the Element.

•

A definition of the start of the Element.

•

A rule for ending the Element.

An Arm is a planned sequence of Elements, typically equivalent to a treatment group. Branches may take place
between one Element and the next and some designs allow for some flexibility of Elements within an Arm. The
term EPOCH (which is discussed in Section 7.4.4) is used to refer to the portion of a blinded trial that corresponds to
an individual element (when the actual element may not be known).
A Visit is defined as a clinical encounter that encompasses planned and unplanned trial interventions, procedures,
and assessments that may be performed on a subject. A Visit has a start and an end, each described with a rule. A
Visit need not be nested within an Element. In other words, it may start in one Element and end in another.
In most blinded trials, the timing of Visits is the same for all subjects, regardless of the Arm to which they have been
assigned. In these cases, the Arm is not needed to describe the timing of Visits, and is left blank in the Trial Visits domain.
If the timing of Visits depends on Arm, then the complete set of Visits for each Arm should be represented in the domain.
The Trial Design Model also includes the Trial Inclusion/Exclusion (TI) dataset to describe the inclusion/exclusion
criteria used to screen subjects. The IE domain (subject specific inclusion/exclusion criteria not met) described in
section 6.3.2 contains the actual exceptions to those criteria for enrolled subjects.
CDISC, © 2005. All rights reserved
FINAL

Page 87
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

7.2

PLANNED ELEMENTS, ARMS, AND VISITS

Under the Trial Design Model, planned information is presented in a series of three tables:
•

The Trial Element table (Table 7.2.1)

•

The Trial Arms table (Table 7.2.2)

•

The Trial Visits table (Table 7.2.3).

7.2.1

Trial Elements

te.xpt, Trial Elements, Version 3.1.1, August 26, 2005. One record per Planned Element
Variable Variable Label
Name

Type Controlled Origin
Terms or
Format

Role

STUDYID Study Identifier

Char

CRF

Identifier Unique identifier for a study within Req
the submission.

DOMAIN Domain Abbreviation

Char

**TE

Derived

Identifier Two-character abbreviation for the Req
domain most relevant to the
observation.

ETCD

Char

Sponsor Defined

Topic

ELEMENT Description of Element Char

Sponsor Defined / Protocol Synonym The name of the Element.
Qualifier

Req
Req

Element Code

CDISC Notes

Core

Short name of ELEMENT used for Req
programming and sorting.

TESTRL

Rule for Start of
Element

Char

Sponsor Defined / Protocol Rule

Expresses rule for beginning
Element.

TEENRL

Rule for End of Element Char

Sponsor Defined / Protocol Rule

Expresses rule for ending Element. Perm
Either TEENRL or TEDUR must
be present for each element.

TEDUR

Planned Duration of
Element

Sponsor Defined / Protocol Timing

Planned Duration of Element in
ISO 8601 format. Used when the
rule for ending the Element is to
applied after a fixed duration.

Char

ISO 8601

* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.

Page 88
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

Perm

CDISC SDTM Implementation Guide (Version 3.1.1)

7.2.2

Trial Arms

ta.xpt, Trial Arms, Version 3.1.1, August 26, 2005. One record per Planned Element per Arm
Variable Label

Type Controlled Origin
Terms or
Format

Role

STUDYID

Study Identifier

Char

CRF

Identifier Unique identifier for a study within the
submission.

Req

DOMAIN

Domain Abbreviation Char **TA

Derived

Identifier Two-character abbreviation for the domain
most relevant to the observation.

Req

ARMCD

Arm Code

Char *

Derived

Topic

Req

ARM

Description of Arm

Char *

Derived

Synonym Name given to an Arm or treatment group.
Qualifier

Req

TAETORD

Order of Element
within Arm

Num

Sponsor Defined Identifier Number that gives the order of the Element
within the Arm.

Req

ETCD

Element Code

Char *

Sponsor Defined Record
Short name of ELEMENT used for
Qualifier programming and sorting.

Req

ELEMENT

Description of
Element

Char *

Sponsor Defined / Synonym The name of the Element.
Protocol
Qualifier

Perm

Variable
Name

CDISC Notes

Core

Short name of ARM., used for programming
and sorting.

TABRANCH Branch

Char

Rule

Condition subject met, at a 'branch' in the trial Exp
design at the end of this Element, to be
included in this Arm; (e.g., randomization to
Drug A).

TATRANS

Transition Rule

Char

Rule

If the trial design allows a subject to transition Exp
to an Element other than the next Element in
sequence, then the conditions for transitioning
to those other Elements, and the alternative
Element sequences, are specified in this rule
(e.g., responders go to washout).

EPOCH

Trial Epoch

Char *

Timing

Name of the Trial Epoch with which this
Element of the Arm is associated.

Note: The same Element may occur more than once within an Arm.
* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.

CDISC, © 2005. All rights reserved
FINAL

Page 89
August 26, 2005

Perm

CDISC SDTM Implementation Guide (Version 3.1.1)

7.2.3

Trial Visits

tv.xpt, Trial Visits, Version 3.1.1, August 26, 2005. One Record per Planned Visit per Arm
Variable Variable Label
Name

Type Controlled Origin
Terms or
Format

Role

Char

CRF

Identifier Unique identifier for a study within
the submission.

Req

Derived

Identifier Two-character abbreviation for the
domain most relevant to the
observation

Req

CRF or Derived

Topic

Req

STUDYID

Study Identifier

DOMAIN

Domain Abbreviation Char

VISITNUM Visit Number

**TV

Num

CDISC Notes

1. Clinical encounter number

Core

2. Numeric version of VISIT, used for
sorting.
VISIT

Visit Name

Char

CRF or Derived

Synonym 1. Protocol-defined description of
clinical encounter.
Qualifier
2. May be used in addition to
VISITNUM and/or VISITDY as a
text description of the clinical
encounter.

Perm

VISITDY

Planned Study Day of Num
Visit

CRF or Derived

Timing

Perm

ARMCD

Arm Code

Char

1. Planned study day of VISIT.
2. Due to its sequential nature, used
for sorting.

Derived

Record
1 Short name of ARM, used for
Qualifier programming and sorting.

Exp

2. If the timing of visits for a trial
does not depend on which ARM a
subject is in, then ARMCD should be
null.
ARM

Description of Arm

Char

TVSTRL

Visit Start Rule

TVENRL

Visit End Rule

Derived

Synonym 1. Name given to an Arm or
Perm
Qualifier Treatment Group.
2. If the timing of Visits for a trial
does not depend on which Arm a
subject is in, then Arm should be left
blank.

Char

Derived

Rule

Rule describing when the Visit starts, Perm
in relation to the sequence of
Elements. Used only when Visits are
dependent on occurrences within the
study, not fixed by protocol.

Char

Sponsor Defined /
Protocol

Rule

Rule describing when the Visit ends, Perm
in relation to the sequence of
Elements.

* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.

Page 90
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.3

SUBJECT ELEMENTS AND VISITS

While the Trial Elements, Trial Arms and Trial Visits datasets describe the planned design of the study, it is also
necessary to collect the corresponding actual data. Subject assignment to an Arm is captured in the ARM variable in
Demographics. Actual Elements and Visits data for each subject are described in two additional datasets:
•

The Subject Elements dataset (Table 7.3.1)

•

The Subject Visits dataset (Table 7.3.2).

7.3.1

Subject Elements

se.xpt ,Subject Elements, Version 3.1.1, August 26, 2005. One record per Actual Element per Subject
Variable Variable Label
Name

Type Controlled Origin
Terms or
Format

Role

STUDYID Study Identifier

Char

CRF

Identifier Unique identifier for a study within the
submission.

DOMAIN Domain Abbreviation

Char

Derived

Identifier Two-character abbreviation for the
Req
domain most relevant to the observation.

USUBJID Unique Subject
Identifier

Char

Sponsor Defined

Identifier Unique subject identifier within the
submission.

Req

SESEQ

Sequence Number

Num

Derived

Identifier Sequence number given to ensure
uniqueness within dataset. Can be used
to join related records.

Req

ETCD

Subject Element Code

Char

Sponsor Defined

Topic

Req

**SE

CDISC Notes

Core

1. Short name of ELEMENT, used for
programming and sorting.

Req

2. If an encountered Element differs
from the planned Element to the point
that it is considered a new Element, then
use 'UNPLAN' as the value for ETCD to
represent this Element.
ELEMENT Description of Subject Char
Element

Sponsor Defined /
Protocol

Synonym The name of the Element. If an
Perm
Qualifier encountered Element differs from the
planned ELEMENT to the point that it is
considered a new ELEMENT, then
ELEMENT should be Null

SESTDTC Start Date/
Time of Element

Char

ISO 8601

CRF or Derived

Timing

Start date/time for an Element for each
subject.

Exp

SEENDTC End Date/
Time of Element

Char

ISO 8601

CRF or Derived

Timing

End date/time of an Element for each
subject.

Exp

SEUPDES Description of
Unplanned Element

Char

Sponsor Defined

Synonym Description of what happened to the
Qualifier subject during this unplanned Element.
Used only if ETCD has the value of
'UNPLAN'.

* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.

CDISC, © 2005. All rights reserved
FINAL

Page 91
August 26, 2005

Perm

CDISC SDTM Implementation Guide (Version 3.1.1)

7.3.2

Subject Visits

sv.xpt, Subject Visits, Version 3.1.1, August 26, 2005. One record per Subject per Actual Visit
Variable Variable Label
Name

Type Controlled Origin
Terms or
Format

Role

Char

CRF

Identifier Unique identifier for a study within Req
the submission.

Derived

Identifier Two-character abbreviation for the
domain most relevant to the
observation.

Char

Sponsor Defined

Identifier Unique subject identifier within the Req
submission.

Num

CRF or Derived

Topic

STUDYID

Study Identifier

DOMAIN

Domain Abbreviation Char

USUBJID

Unique Subject
Identifier

VISITNUM Visit Number

**SV

CDISC Notes

Core

Req

1. Clinical encounter number.
Req
(Decimal numbering may be useful
for inserting unplanned visits.)
2. Numeric version of VISIT, used
for sorting.

VISIT

Visit Name

Char

CRF or Derived

Synonym 1. Protocol-defined description of
Qualifier clinical encounter.

Perm

2. May be used in addition to
VISITNUM and/or VISITDY as a
text description of the clinical
encounter.
VISITDY
SVSTDTC

Planned Study Day of Num
Visit

CRF or Derived

Timing

Planned study day of VISIT.
Perm

Start Date/Time of
Visit

Char

ISO 8601

CRF or Derived

Timing

Start date/time for a Visit.

Exp

SVENDTC End Date/Time of
Visit

Char

ISO 8601

CRF or Derived

Timing

End date/time of a Visit.

Exp

SVUPDES

Char

CRF or Derived

Synonym Description of what happened to the Perm
Qualifier subject during an unplanned visit.

Description of
Unplanned Visit

* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.

Page 92
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.4

TRIAL ARMS

The core of the Trial Design models is the Trial Arms domain (TA). It contains one record for each occurrence of an
Element in each Arm of the trial.

7.4.1

Identifying Trial Arms

Arms are a familiar concept in Clinical Trials. They usually correspond to treatment groups.

Example: Figure 1

Flowchart, Parallel Trial
Placebo
Screen

Run-in

Drug A
Drug B

Figure 1

In this example, the number of Arms is three. However, in some trials with multiple branchings, the number of
Arms in the trial may not be obvious.

CDISC, © 2005. All rights reserved
FINAL

Page 93
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Example: Figure 2

Counting Arms
in More Complex Trials
Treatment A

Open label
Rescue

Screen

Open label
Treatment B
Rescue
Randomization
Response
Evaluation

Figure 2

In this example, subjects are randomized to one of two treatment groups. At the end of this first treatment period,
they are assigned to one of two further treatment groups on the basis of their response to their initial period of
treatment. The combination of these two major branchings results in four Arms for this trial.
See Section 7.4.7 for additional considerations that arise in a multi-stage trial design like this one.
See Section 7.4.3 for additional discussion of when a decision point in a trial design should be considered to give
rise to a new Arm.

7.4.2

Developing the Trial Arms Table

In Figure 1 (shown previously), the trial has three Arms. This diagram is similar to the kind of study schema or
flowchart usually included in most trial protocols. The 'building blocks' shown in these diagrams are referred to
within the Trial Design Model as 'Elements.' Further details on how Elements are defined are in Section 7.5
Parallel Trial Example: Figure 3

Page 94
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Arms Representation,
Parallel Trial
Screen

Run-in

Placebo

Screen

Run-in

Drug A

Screen

Run-in

Drug B

Randomization

Figure 3

The trial design can be represented as three parallel Arms, as in this diagram. The screen and run-in Elements,
which occur before the branching at the point of randomization, are repeated in each Arm.
Note that the randomization is represented by red lines at the ends of the run-in Elements in the three Arms.
Randomizations, and other branchings in the trial design, are represented by such markers between Elements.
One kind of branching, other than a randomization, is an assignment based on the subject’s clinical response to
treatment. This was mentioned in the example in Section 7.4.1. Branchings could also depend on a subject’s
disease severity, or any other clinical finding.
Another kind of branching occurs in dose-escalation cohort studies. In this kind of trial design, there are rules that
say whether the next subject should be in the current cohort (receive the current dose level) depending on how many
subjects are in the current cohort and what their response to treatment has been. For example, the rule might say that
five subjects should be entered in each cohort, and that additional subjects would be added to a cohort if a certain
proportion of subjects experienced dose-limiting toxicity. The rule might say that entry of subjects (and the addition
of new cohorts) would stop when a certain proportion of subjects in such an enlarged cohort experiences doselimiting toxicity.

CDISC, © 2005. All rights reserved
FINAL

Page 95
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

The diagram in Figure 3 can be further transformed into a table to aid in creating the trial design datasets. There is
one row in the table for each Element in each Arm in Figure 3. Note how the column labeled 'Branch' captures the
information represented by the red markers in the diagram. Note also that the value in the Branch column shows the
randomization result that is needed for a subject to be in that Arm.
ARMCD

TAETORD

ELEMENT

Placebo

Screen

Placebo

Run-In

Placebo

Screen

Run-In

Drug A

Screen

Run-In

Drug B

TABRANCH

Randomized to Placebo

Randomized to Drug A

Randomized to Drug B

Crossover Trial Example: Figure 4

Flowchart, Crossover Trial
Placebo Rest
Screen

5 mg

Rest 10 mg

Follow up

5 mg

Rest Placebo Rest 10 mg

Follow up

5 mg

Rest 10 mg

Rest Placebo Follow up

Figure 4

This trial is similar to the Parallel-Trial example, except that there are multiple treatment periods. Note that the
Arms are distinguished by the order of treatments, rather than the presence of one treatment or another. Note also
that rest Elements occur twice within each Arm.

Page 96
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

CrossOver Trial Example: Figure 5

Arms Representation,
Crossover Trial
Screen Placebo Rest 5 mg

Rest 10 mg Follow up

Screen

5 mg

Rest Placebo Rest 10 mg Follow up

Screen

5 mg

Rest 10 mg Rest Placebo Follow up

Randomization

Figure 5

The trial design is represented with three parallel Arms. This transformation is similar to that shown in the Parallel
Trial example (previously shown Figures1-3).
As for the previous example, the diagram in Figure 5 can be further transformed into a table. Only the first 10 of the
21 rows of the table for this trial are shown in this example table.
ARM

TAETORD

ELEMENT

TABRANCH

P-5-10

Screen

Randomized to Placebo - 5 mg - 10 mg

P-5-10

Placebo

P-5-10

Rest

P-5-10

5 mg

P-5-10

Rest

P-5-10

10 mg

P-5-10

Follow-up

5-P-10

Screen

5-P-10

5 mg

5-P-10

Rest

CDISC, © 2005. All rights reserved
FINAL

Randomized to 5 mg - Placebo - 10 mg

Page 97
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Oncology Trial Example: Figure 6

Flowchart, Oncology Trial
Repeat until disease progression

Trt A Rest

Follow up

Trt B Rest

Follow up

Screen

Figure 6

Many oncology trials feature repeating cycles of treatment. As indicated, there is a condition for repeating the cycle.

Page 98
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Oncology Trial Example: Figure 7

Flowchart with Repeats,
Oncology Trial

Trt A Rest Trt A Rest Trt A Rest Trt A Rest Follow up
Screen
Trt B Rest Trt B Rest Trt B Rest Trt B Rest Follow up
Note: If protocol does not specify maximum number of cycles,
use actual maximum number of cycles that occurred in trial.

Figure 7

The first step in transforming this design into tabular format is to put in the repeating cycles, replacing the arrow
indicating cycling through the treatment Element.
If the protocol indicates a maximum number of permitted cycles, that number of cycles should be included. If the
protocol does not specify a maximum, then use maximum number of cycles that actually occurred in the trial. At the
time of submission, the trial has completed, and the maximum number of cycles is known.

CDISC, © 2005. All rights reserved
FINAL

Page 99
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Oncology Trial Example: Figure 8

Arm Representation,
Oncology Trial
Transition rules:
If disease progresses, skip forward

Screen Trt A Rest Trt A Rest Trt A Rest Trt A Rest Follow up

Screen Trt B Rest Trt B Rest Trt B Rest Trt B Rest Follow up
Randomization
Figure 8

This diagram shows parallel Arms, as before. The randomization is represented by red markers, as before.
The green arrows represent the fact that subjects may not pass through all the cycles in the trial. In this case, a
subject whose disease progresses will skip further treatment cycles and jump to the follow-up Element. In previous
examples, the implicit rule was 'when the subject finishes one Element, move to the next.' In this trial, at the end of
each Rest Element, the subject may move to one of two Elements. Thus there is a need for an explicit transition
rule.
As before, this diagram can be transformed into a table. However, this table requires another column, for the
transition rule. If this column is blank, then the default transition rule, 'go to the next Element in sequence' is
assumed. Only the rows for one Arm are shown in this example table.
ARM

TAETORD

ELEMENT

TABRANCH

Screen

Randomized to A

Trt A

Rest

Trt A

Rest

Trt A

Rest

Trt A

Rest

Follow-up

Page 100
August 26, 2005

TATRANS

If disease progression, go to 10th Element.
If disease progression, go to 10th Element.
If disease progression, go to 10th Element.

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.4.3

Distinguishing between Branches and Transitions

Both the Branch and Transition columns contain rules, but there are two columns because they represent two
different types of rules. Branch rules represent forks in the trial flowchart, giving rise to separate Arms. The Branch
rules thus appear in multiple Arms in the Trial Arms dataset. Within any one Arm, there is no choice in the value of
the Branch condition. e.g., the subject must have been randomized to Arm A. Transition rules are used for choices
within an Arm. In the Oncology example shown in Figure 8, subjects who receive 1, 2, 3, or 4 cycles are all
considered to belong to Arm A.
In modeling a trial, decisions may have to be made about whether a decision point in the flow chart represents the
separation of two or more separate Arms, or simply to variations within the same Arm. This decision will depend
on the comparisons of interest in the trial.

7.4.4

Trial Epoch Concept

In all the trials we have considered thus far, the several trial Arms are similar in that they have the same numbers of
Elements and the same pattern of treatment and non-treatment Elements.
Example: Figure 9

Epochs, Crossover Trial
1
Screen

2
1st Trt

3
1st
Rest

4
2ndTrt

Screen Placebo Rest 5 mg

5
2nd
Rest

6
3ndTrt

7
Follow-up

Rest 10 mg Follow up

Screen

5 mg

Rest Placebo Rest 10 mg Follow up

Screen

5 mg

Rest 10 mg Rest Placebo Follow up

Figure 9

This diagram shows the similarity between Arms by means of dotted vertical lines that divide the trial as a whole,
across all Arms, into 'Epochs.' When the trial elements form a grid in this way, the rows are Arms and the columns
are Epochs. The numbers assigned to the columns correspond to TAETORD, the 'Order' column in the example
tables. The names assigned to the columns are the names of the Epochs. The names suggested in this example
represent familiar concepts. Only the terminology 'Epoch' is new.
The great majority of clinical trials, particularly blinded clinical trials, have this grid structure of Epochs and Arms.
During the conduct of a blinded study, when the Arm assignment of a subject is unknown, a subject's progress
through the trial must be spoken of in terms of Epochs, since the subject's specific treatment Elements are unknown.
The concept of Epochs is not universally applicable. The following examples show trials for which Epochs are
applicable and are not applicable and some that fall in a gray area.
In Figure 9, the Elements of the Arms fall into columns because the blocks representing the Elements in a column all
have the same width. The widths of these blocks represent the Element durations, which are determined by their

CDISC, © 2005. All rights reserved
FINAL

Page 101
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

End Rules. (Element Start and End Rules are described in Section 7.5.) The following is a join of the TA and TE
datasets for this trial (i.e., the TA dataset, to which the Start Rule (TESTRL) and Duration (TEDUR) from the TE
dataset have been added).
ARM

TAETORD

ELEMENT

TESTRL

P-5-10

Screen

P-5-10

TEDUR

TABRANCH

Informed consent

P14D

Randomized to Placebo
- 5 mg - 10 mg

Placebo

First dose of placebo

P14D

Rest

48 hrs after last dose drug

P-5-10

5 mg

First dose of 5 mg drug

P14D

P-5-10

Rest

48 hrs after last dose drug

P-5-10

10 mg

First dose of 10 mg drug

P14D

P-5-10

Follow-up

48 hrs after last dose drug

P21D

5-P-10

Screen

Informed consent

P14D

5-P-10

5 mg

First dose of 5 mg drug

P14D

5-P-10

Rest

48 hrs after last dose drug

5-P-10

Placebo

First dose of placebo

P14D

5-P-10

Rest

48 hrs after last dose drug

5-P-10

10 mg

First dose of 10 mg drug

P14D

5-P-10

Follow-up

48 hrs after last dose drug

P21D

5-10-P

Screen

Informed consent

P14D

5-10-P

5 mg

First dose of 5 mg drug

P14D

5-10-P

Rest

48 hrs after last dose drug

5-10-P

10 mg

First dose of 10 mg drug

P14D

5-10-P

Rest

48 hrs after last dose drug

5-10-P

Placebo

First dose of placebo

P14D

5-10-P

Follow-up

48 hrs after last dose drug

P21D

Page 102
August 26, 2005

TEENRL

Randomized to 5 mg Placebo - 10 mg

Randomized to 5 mg 10 mg - Placebo

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Sorting this dataset by TAETORD displays the similarity between Elements with the same value of TAETORD. For
each value of TAETORD, the End Rules are the same (not shown with the example) and the Start Rules are either
the same or differ only by drug dose. Each value of TAETORD corresponds to an Epoch, and the associated Start
and End Rules of the Elements associated with that value of TAETORD represent, in effect, the Start and End Rules
for the associated Epoch.
ARM

TAETORD

EPOCH

ELEMENT

TESTRL

TEDUR

TABRANCH

5-P-10

Trial Screen

Screen

Informed consent

P14D

Randomized to 5
mg/Placebo/10 mg

P-5-10

Trial Screen

Screen

Informed consent

P14D

Randomized to
Placebo/5 mg/10
mg

5-10-P

Trial Screen

Screen

Informed consent

P14D

Randomized to 5
mg/10 mg/Placebo

5-P-10

First Treatment

5 mg

First dose of 5 mg drug

P14D

P-5-10

First Treatment

Placebo

First dose of placebo

P14D

5-10-P

First Treatment

5 mg

First dose of 5 mg drug

P14D

5-P-10

First Rest

Rest

48 hrs after last dose drug

P-5-10

First Rest

Rest

48 hrs after last dose drug

5-10-P

First Rest

Rest

48 hrs after last dose drug

5-P-10

Second Treatment

Placebo

First dose of placebo

P14D

P-5-10

Second Treatment

5 mg

First dose of 5 mg drug

P14D

5-10-P

Second Treatment

10 mg

First dose of 10 mg drug

P14D

5-P-10

Second Rest

Rest

48 hrs after last dose drug

P-5-10

Second Rest

Rest

48 hrs after last dose drug

5-10-P

Second Rest

Rest

48 hrs after last dose drug

5-P-10

Third Treatment

10 mg

First dose of 10 mg drug

P14D

P-5-10

Third Treatment

10 mg

First dose of 10 mg drug

P14D

5-10-P

Third Treatment

Placebo

First dose of placebo

14D

5-P-10

Trial Follow-up

Follow-up

48 hrs after last dose drug

P21D

P-5-10

Trial Follow-up

Follow-up

48 hrs after last dose drug

P21D

5-10-P

Trial Follow-up

Follow-up

48 hrs after last dose drug

P21D

CDISC, © 2005. All rights reserved
FINAL

Page 103
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Inconsistent numbers and durations of Elements Example: Figure 10

Trial with Inconsistent Numbers
and Durations of Elements
1
1

2
2

5
4

6
5

9
7

10
8

Screen

Trt B

Trt A

Rest B

Rest A

Follow-up
Figure 10

The trial in Figure 10 compares cancer therapies given as 3-week and 4-week cycles. The table below is a join of
TA and TE datasets for this trial, sorted by TAETORD. Note that the number of Elements in Arm A is different from
the number of Elements in Arm B and that the Start and End Rules for Elements with the same value of TAETORD
are only loosely comparable for the 2nd through the 7th Elements. It is questionable whether it would be meaningful
to compare data for the 2nd Elements through the 7th Elements, not meaningful to compare the 8th Elements, and
there are no 9th and 10th Elements in Arm B for comparison
It would be reasonable to compare data for the Screen and Follow-up Elements. The existing Element variable is
available for selecting data for this comparison, so it is not necessary to define Epochs to facilitate this comparison.
ARM

TAETORD

ELEMENT

TESTRL

TEDUR

TABRANCH

Screen

Informed consent

14D

Randomized to A

Screen

Informed consent

14D

Randomized to B

Trt A

First dose A

Trt B

First dose B

P7D

Rest A

48 hrs after last dose A

12D

If disease progresses,
go to 10th Element

Rest B

48 hrs after last dose B

21D

If disease progresses,
go to 8th Element

Trt A

First dose A

Trt B

First dose B

P7D

Rest A

48 hrs after last dose A

12D

If disease progresses,
go to 10th Element

Rest B

48 hrs after last dose B

21D

If disease progresses,
go to 8th Element

Page 104
August 26, 2005

EPOCH

TATRANS

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

ARM

TAETORD

EPOCH

ELEMENT

TESTRL

TEDUR

Trt A

First dose A

Trt B

First dose B

P7D

Rest A

48 hrs after last dose A

12D

Rest B

48 hrs after last dose B

21D

Trt A

First dose A

Follow-up

Decision not to treat
further

90D

Rest A

48 hrs after last dose A

12D

Follow-up

Decision not to treat
further

90D

TABRANCH

TATRANS

If disease progresses,
go to 10th Element

Inconsistent Element Durations Example: Figure 11

Trial with
Inconsistent Element Durations
1
1

2
2

3
3

4
4

5
5

6
6

7
7

8
8

Screen

Trt B

Trt A

Rest B

Rest A

Follow-up
Figure 11

In the trial in Figure 11, the numbers of Elements are the same, and comparisons of the 2nd through 7th Elements of
the two treatment Arms may be reasonable. The issue of whether Elements of different durations should be
compared should be decided on the merits of the particular trial.

CDISC, © 2005. All rights reserved
FINAL

Page 105
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Dissimilar treatments: Figure 12

Trial with Dissimilar Treatments
1
Screen

123

Drug Treatment
Behavior Modification
Pre-Op
Surgery
Post-Op

Follow up A
Follow up B
Follow up C

Figure 12

The trial shown in Figure 12 compares dissimilar treatments with different durations. The usefulness of
comparisons between data from these different treatment Elements would depend on the particular trial. If such
comparisons were desired, an alternate model that uses one Surgery treatment Element (combining Pre-Op, Surgery
and Post-Op in one element), instead of the three Elements shown here, might be considered. See Section 7.5.1 for
additional discussion of 'lumping' versus 'splitting' in defining Elements.

7.4.5

Rules concept

The Branch and Transition columns shown in the example tables thus far are instances of a new concept being added
to SDS in Version 3.1. A variable may have a Role of 'Rule.' The values of a Rule variable describe conditions for
something happening. At the moment, values of Rule variables are text. At some point in the future, it is expected
that these will be become executable code. Other Rule variables are present in the Trial Elements and Trial Visits
domains.
The value in the Branch rule gives conditions under which a subject was assigned to this Arm. A value in the
Transition rule gives conditions under which a subject would move to an Element other than the next Element.

7.4.6

Recap of Trial Arms Variables

Variables

Purpose

STUDYID, DOMAIN

Identifiers

ARM, ARMCD

Name the Arm

TAETORD

Put Elements in order within the Arm

ETCD, ELEMENT

Name an Element within the Arm

TABRANCH

Mark a branch in the trial design at the end of the Element. A branch may be a
randomization or another method of assignment to Arms

Page 106
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Variables

Purpose

TATRANS

A rule for where to go at the end of the Element. A blank represents the default
rule, 'go to the next Element in sequence.'

EPOCH

Permissible. Names the Trial Epoch with which the Element is associated.

7.4.7

Truncated Arms

In trials with multiple branch points, such as that shown in Figure 2, some subjects may drop out of the study before
they reach the second branch point. This raises the question how a value of ARM should be assigned to such a
subject.
We recommended adopting names for the Arms of a multi-branching trial that reflect the various branches. For
example, the four Arms in the trial shown in Figure 2 could be named A-Open, A-Rescue, B-Open, and B-Rescue.
ARM values of A and B can be used for subjects who do not reach the second branch point.
Note that it may be necessary to create an Arm name for subjects who fail to reach the branch point even for a trial
with only one Branch. For example, it might be necessary to submit data on subjects who drop out during the run-in
Element in the trial in Figure 1.

7.5

TRIAL ELEMENTS

Trial Elements (TE) contains one record for each type of Element in TA. It is like a key or legend for the TA domain.
Note that although the same value of ELEMENT may appear in more than one record in the TA dataset, it will
appear in just one record in the TE dataset.
Examples: Figures 13, 14 and 15 show keys for Trial Elements added to the Trial Arms models shown previously in
Figures 3, 5, and 8.
Trial Elements Corresponding to Figure 3: Figure 13

Arms and Elements, Parallel Trial
Screen

Run-in

Placebo

Screen

Run-in

Drug A

Screen

Run-in

Drug B

9 records in
Trial Arms table

Screen
Run-in
Placebo

5 records in Trial Elements table

Drug A
Drug B

CDISC, © 2005. All rights reserved
FINAL

Figure 13

Page 107
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Trial Elements Corresponding to Figure 5: Figure 14

Arms and Elements, Crossover Trial
Screen Placebo Rest 5 mg

Rest 10 mg Follow up

Screen

5 mg

Rest Placebo Rest 10 mg Follow up

Screen

5 mg

Rest 10 mg Rest Placebo Follow up

Screen
Placebo
5 mg
10 mg

21 records in Trial Arms table

6 records in Trial Elements table

Rest
Figure 14

Follow up
Trial Elements Corresponding to Figure 8: Figure 15

Arms and Elements, Oncology Trial
Screen Trt A Rest Trt A Rest Trt A Rest Trt A Rest Follow up
Screen Trt B Rest Trt B Rest Trt B Rest Trt B Rest Follow up
20 records in Trial Arms table
Screen
Trt A
Trt B

5 records in Trial Elements table

Rest
Follow up

Page 108
August 26, 2005

Figure 15

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.5.1

Identifying Trial Elements

An Element is a building block for creating Arms. Or, from another point of view, an Arm is composed of Elements
(i.e., the trial design assigns subjects to Arms, which are comprised of steps called Elements). Trial Elements
represent an interval of time in which certain activities are planned for the subjects participating in the trial. Both
the activities and the time description are essential to the concept of the Element. The activities may be run-ins,
wash-outs, drug treatments, or other interventions. The time description defines an interval of time, with a start and
an end, during which the activities are planned to take place.
Assumption: There are no gaps between Elements. The instant one Element ends, the next Element begins. A
subject spends no time 'between Elements.'
Since an Element is defined by both a period of time and what is happening to the subject during that time, 'Week 2
to Week 4' is not a valid Element. 'Two weeks of treatment with Drug A' is a valid Element. Elements may describe
periods of non-treatment as well as periods of treatment. Common kinds of non-treatment Elements include washout, rest, and follow-up periods.
Deciding how finely to divide trial time when identifying trial Elements is a matter of judgment.
For example, a trial might include a dose titration, spelled out as one week each at a series of increasing doses until
certain conditions are met. The trial design could be modeled in any of the following ways:
•

using several one-week Elements at specific doses, followed by an Element of variable length at the chosen
dose,

•

as a titration Element of variable length followed by a constant dosing Element of variable length

•

one Element with dosing determined by titration

The choice of model will depend on how the data will be analyzed and reported. If it is important to examine side
effects or lab values at each individual dose, the first model is appropriate. If it is important only to identify the time
to achieve titration, the second model might be appropriate. If the titration process is routine and of little interest,
the third model might be adequate for the purposes of this trial.
Oncology trials with cycles of treatment and rest present another example where the needs of the trial will determine
whether the trial should be modeled with two Elements per cycle, as in Figure 8 (previously shown), or with one
Element per cycle, as in Figure 16 below.
Oncology Trial, One Element per Cycle: Figure 16

Transition rules:
If disease progresses, skip forward

Screen

Trt A

Follow up

Screen

Trt B

Follow up

Randomization
Figure 16

CDISC, © 2005. All rights reserved
FINAL

Page 109
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

7.5.2

Developing the Trial Elements Table

An Element’s name usually describes what happens to the subject during the Element. The time period associated
with an Element is expressed in two Rules, the Element Start and Element End Rules. If the element is of fixed
duration, then the Element Duration variable should also be populated.
Element Start Rules identify the time point at which a subject is considered to have entered an Element. Many
analyses depend on placing data in the proper Element, so the Element Start Rules should be as clear as possible,
and should be chosen with consideration for planned analyses.
Treatment Elements are usually considered to start with the beginning of the Element treatment (e.g., with the first
dose of the relevant drug). The Start Rules for non-treatment Elements can be more difficult to define. They will
often be defined relative to the end of the preceding treatment. For example, a wash-out period might be defined as
starting 24 or 48 hours after the last dose of drug for the preceding treatment period. Defining a clear start point for
the start of a non-treatment Element that follows another non-treatment Element can be difficult.
The Element Start Rule for a treatment Element may be thought of as 'active' and the Element Start Rule for a nontreatment Element as 'passive.' The start of a treatment Element will not occur until a dose is given, no matter how
long that dose is delayed. Once the last dose is given, the start of the subsequent non-treatment Element is
inevitable, as long as another dose is not given.
Element End Rules are rather different from Element Start Rules. The actual end of one Element is the beginning of
the next Element. Thus the Element End Rule does not give the conditions under which an Element does end, but
the conditions under which it should end. The most common type of Element End Rule is the rule for an Element of
fixed duration. Such a rule might be expressed as '14 days after Element starts' or, perhaps more realistically, as '1216 days after Element starts.' Element End Rules may also depend on other conditions. For instance, a typical
criterion for ending a rest Element between oncology chemotherapy treatment Elements would be, '15 days after
start of Element and after WBC values have recovered'.
There is not yet a standardized method for expressing rules in computer-executable form. However, for the most
common type of Element End Rule, for elements of fixed duration, we can easily express element duration. Thus, a
variable for Element Duration has been included in the model.

Page 110
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

Example: Trial Elements table for the parallel trial shown in Figure 13
ELEMENT

TESTRL

TEENRL

TEDUR

Screen

Informed consent

1 week after start of element

P7D

Run-In

Eligibility confirmed

2 weeks after start of element

P14D

Placebo

First dose of placebo

2 weeks after start of element

P14D

Drug A

First dose of Drug A

2 weeks after start of element

P14D

Drug B

First dose of Drug B

2 weeks after start of element

P14D

Example: Trial Elements table for the crossover trial shown in Figure 14
ELEMENT

TESTRL

TEENRL

TEDUR

Screen

Informed consent

2 weeks after start of element

P14D

Placebo

First dose of placebo

2 weeks after start of element

P14D

5 mg

First dose of 5 mg drug

2 weeks after start of element

P14D

10 mg

First dose of 10 mg drug

2 weeks after start of element

P14D

Rest

48 hrs after last dose drug

1 week after start of element

P7D

Follow-up

48 hrs after last dose drug

3 weeks after start of element

P21D

The transition between one Element and the next can be complex, since it may involve meeting criteria for ending
one Element, evaluating criteria for choosing which Element to go to next, and actually taking the action that
initiates the new Element.
For example, in the trial shown in Figure 15, the Trial Elements dataset might be as follows:
ELEMENT

TESTRL

TEENRL

TEDUR

Screen

Consent

2 weeks after start of element

P14D

Trt A

First dose drug

5 days after start of element

P5D

Trt B

First dose drug

16 days after start of element and
WBC recovers

Rest

Last dose + 24 hrs

16 days after start of element and
WBC recovers

Follow-up

Decision not to treat further

4 weeks

P28D

A subject in the 3rd Element (Trt B) must meet the Element End criteria (16 days pass and WBC recovers), then be
evaluated to see whether disease has progressed. If it has not progressed, they must still wait until the first dose of
the 4th Element is administered before they can be considered to be in the 4th Element. During the whole time from
meeting the Element End criteria to meeting the new Element Start criteria, the subject stays in the 'old' Element.
See Section 7.7.2 for a discussion of unplanned Elements.

CDISC, © 2005. All rights reserved
FINAL

Page 111
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

7.5.3

Recap of Trial Elements Variables

Variables

Purpose

STUDYID, DOMAIN

Identifiers

ETCD, ELEMENT

Name the Element

TESTRL

Rule describing the time point that defines the start of the Element

TEENRL, TEDUR

Rule describing when the Element should end and its duration (if the element is
of fixed duration)

7.5.4

Distinguishing Elements from Epochs

Figure 9, which was used to introduce the concept of trial Epoch is also useful for showing how the concepts of
Elements and Epoch can be confused. Note that the natural name for the first Epoch is 'Screen,' which is also the
natural name of the Element that appears in each Arm in this Epoch. The same is true for the 7th Epoch, where the
Epoch and the Elements in the Epoch are both named 'Follow-up.' Clearly, it will be easy to confuse Element and
Epoch in these cases.
We recommend avoiding using the same names for Elements and Epochs. One possible solution is to prefix Epoch
names with the word 'trial', on the grounds that an Epoch is a feature of the trial as a whole. In the example, 'Trial
Screen' would be the Epoch, while 'Screen' would be the Element
In the treatment Epochs of this trial, the Epoch describes a period of time in the trial, First, Second, or Third
Treatment, while the Elements describe particular treatments which may occur during different Epochs of the trial.
This trial has First and Second Rest Epochs, which are populated by the one Rest Element in this trial.
It may be useful to think of a trial design as a table like the following, with a row for each Arm and a column for
each Epoch.
Trial
Screen

First
Treatment

First

Second
Treatment

Second
Rest

Third
Treatment

Trial

P-5-10

Screen

Placebo

Rest

5 mg

Rest

10 mg

Follow-up

5-P-10

Screen

5 mg

Rest

Placebo

Rest

10 mg

Follow-up

5-10-P

Screen

5 mg

Rest

10 mg

Rest

Placebo

Follow-up

Rest

Follow-up

The bold column headers are the names of the Epochs. The secondary column headers (1, 2, etc.) show how each
value of TAETORD in this trial corresponds to an Epoch. The bold row labels are the names of the Arms. The cells
are filled with the names of the Elements in the trial Arms.
For some analysis purposes, one would want to group data by Element, but for other purposes, data would be
grouped by Epoch or TAETORD. In this crossover trial, for instance, comparisons of incidences of side affects of
the different treatments would group data by Element (Placebo vs. 5 mg vs. 10 mg). The analysis of PK results for
this trial would include both treatment and period effects in the model. 'Treatment effect' derives from Element
(Placebo vs. 5 mg vs. 10 mg), while 'Period effect' derives from the EPOCH (1st, 2nd, or 3rd Treatment), which is in
turn associated with TAETORD (2nd vs. 4th. vs. 6th Element).

Page 112
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.6

TRIAL VISITS

Trial Visits (TV) describes the planned visits in a trial.

7.6.1

Identifying Trial Visits

The SDS definition of Visit is a clinical encounter. Assessments and procedures are planned at Visits.
Assumption: Visits have both a start and an end.
For many trials, the exact timing and duration of Visits are not important, but for other trials this detail is needed, so
both start and end are included in the model.
Assumption: A Visit may start in one Element and end in another.
Example: Visits in clinical pharmacology trials are often planned to include a series of timed assessments (a profile)
associated with a dose of drug. The dose is often the start of an Element. The planned Visit might start a hour
before the dose (the end of the current Element) and end eight hours after the dose (the beginning of the new
Element), to allow for pre-dose assessments and a series of post-dose assessments.
The term 'Visit' reflects the fact that data in out-patient studies is usually collected when the subject Visits the clinic.
Diary data and other data collected outside the clinic may not fit the usual concept of a Visit, but the planned times
of collection of such data may be described as 'Visits' in the Trial Visits dataset.
The description of planned 'Visits' may also require careful thought for studies of hospitalized subjects.

7.6.2

Developing the Trial Visits Table

For most trials, particularly blinded trials, the timing of Visits does not depend on Arm. However, planned Visits
may be different for different Arms in the trial, so ARM and ARMCD are included in the Trial Visits dataset. If
planned Visits do not depend on Arm, ARM and ARMCD can be left blank. If planned Visits do depend on Arm,
records for planned Visits for each Arm should be submitted. The trial shown in Figure 12 would probably have
different planned Visits for each Arm.
Visit Start Rules are different from Element Start Rules because they usually describe when a Visit should occur,
rather than the moment at which a Visit is considered to start. There are usually gaps between Visits, periods of time
that do not belong to any Visit, so it usually not necessary to identify the moment when one Visit stops and another
starts. However, some trials of hospitalized subjects may divide time into Visits in a manner more like that used for
Elements.
Visit Start Rules are usually expressed relative to the start or end of an Element, e.g., '1-2 hours before end of 3rd
Element' or '8 weeks after end of 2nd Element.' Note that the Visit may or may not occur during the Element used as
the reference for Visit Start Rule. For example, a trial with variable Elements might plan a Visit 6 months after the
start of the first treatment period, regardless of the Element the subject is in at that time.
Visit End Rules are similar to Element End Rules, describing when a Visit should end. They may be expressed
relative to the start or end of an Element, or relative to the start of the Visit.
Ranges may be used to describe the planned timing of Visits (e.g., 12-16 days after the start of 2nd Element), but this
is different from the 'windows' that may be used in selecting data points to be included in an analysis associated with
that Visit. For example, although Visit 2 was planned for 12-16 days after the start of treatment, data collected 1018 days after the start of treatment might be included in a 'Visit 1' analysis. The two ranges serve different purposes.
Unplanned Visits are discussed further in Section 7.8.

CDISC, © 2005. All rights reserved
FINAL

Page 113
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Trial Visits Example: Figure 17

Trial Visits
1

Screen

Run-in

Placebo

Screen

Run-in

Drug A

Screen

Run-in

Drug B

Figure 17

The trial shown in Figure 17 might have the following Trial Visits dataset:
VISITNUM

TVSTRL

TVENRL

Start of 1 Element

1 hour after start of visit

30 minutes before end of 1st Element

30 minutes after start of 2nd Element

30 minute before end of 2nd Element

1 hour after start of 3rd Element

1 week after start of 3rd Element

1 hour after start of visit

7.6.3

2 weeks after start of 3

Element

1 hour after start of visit

Recap of Trial Visits Variables

Variables

Purpose

STUDYID, DOMAIN

Identifiers

VISIT, VISITNUM, VISITDY

Name and order the visits

ARM, ARMCD

Blank if visit schedule does not depend on Arm.
Names of the ARM if visit schedule does depend on Arm.

TVSTRL

Rule describing when the visit should start.
Usually expressed relative to starts or ends of Elements described
using TAETORD.

TVENRL

Rule describing when the visit should end.
Usually expressed relative to the start of the Element, or to starts or
ends of Elements described using TAETORD.

Page 114
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.7

SUBJECT ELEMENTS

Subject Elements (SE) describes the sequence of Elements a subject passed through, with their start and stop
date/times. Note there is no need for a Subject Arms dataset, because the Arm for each subject is represented in the
Demography (DM) dataset.
The subject Element start date/times allow a comparison of the sequence of Elements a subject actually passed
through to the planned sequence of Elements for the Arm to which they were assigned.
The date/times in Subject Elements also allows any date/time to be placed within one Element. This assignment of
data to actual Elements is often used in analyses.
Subject Elements data involves judgment and interpretation.

7.7.1

Identifying Subject Elements

The Element Start Rules in the Trial Elements dataset should allow identification of the Elements the subject passed
through and the derivation of start date/times for each subject Element. This derivation may be more or less
difficult, depending on the trial design, on how well the Element Start Rules have been defined, and on how well the
date/times associated with the transition from one Element to the next have been collected.
Note that this process of matching the subject’s actual experience with planned Elements involves judgment, and
may be open to interpretation. The programming used to derive subject Elements will incorporate decisions about
how close a match a time period and its treatments have to be to the plan to be considered a 'match.' For instance if
the plan included Elements with treatment doses of 5 mg and 10 mg, is a period of treatment with a dose of 7 mg a
'5mg' Element? If an Element is planned to last 2 weeks but actually lasts 6 weeks, is this a match? It is usually
better to associate subject experience with one of the planned Elements, than to describe, note or summarize
deviations from the plan, but this is a matter of judgment.

7.7.2

Unplanned Elements

It is usually better to parse a subject’s time in the trial into segments labeled with names from the list of planned
Elements, but occasionally a subject departs so much from plan that a decision is made to label a part of the
subject’s experience as an unplanned Element.
Example: A crossover trial that involves three single doses of drug, one each week for three weeks. The period
from one dose to the next is considered a treatment Element. A subject is enrolled in the trial and completes two of
the doses. He departs for a month-long trip. On his return, he is given the third dose, then returns for follow-up a
week later. It is decided that only the first week after the second dose should be considered as belonging to the
second treatment Element. The remaining 3 weeks before the third dose is labeled an 'Unplanned' Element.
Example: A trial involves treatment with an IV drug that is prepared in the hospital pharmacy. By error, the subject
receives only one tenth of the planned dose. The error is discovered, and the subject is treated again, with the
correct dose. It is decided to label the period starting with the initiation of the erroneous infusion and ending the
initiation of the correct infusion an 'unplanned' Element.
If an unplanned Element occurs, a record for the unplanned Element should be included in SE. For this record,
ETCD cannot be populated with any of the values associated with planned Elements.
It is recommended that the SE record for the unplanned Element use 'UNPLAN' as the value for ETCD, that
ELEMENT be left blank, and that a description of the unplanned Element be given in SEUPDES.

7.7.3

Deriving SE End Date/Times

Because there are no gaps between Elements, once subject Element start date/times have been derived for all
Elements, the derivation of all but one of the subject end date/times is trivial. For all subject Elements except the
last, the end date/time of the Element is equal to the start date time of the next Element.

CDISC, © 2005. All rights reserved
FINAL

Page 115
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

It may be desirable to define RFENDTC (in the DM domain) as the end date/time for the end of the last subject
element date/time.

7.7.4

Recap of Subject Elements Variables

Variables

Purpose

STUDYID, DOMAIN, USUBJID

Identifiers

ETCD, ELEMENT

Name this Element in the subject’s course

SESTDTC, SEENDTC

Date/times of start and end of the Element for the subject

SEUPDES

Permissible variable. Blank except for unplanned Elements.
Describes the unplanned Element.

7.7.5

Using Subject Elements Data to Place Subject Data within an Element or
Epoch

SDS V3 contained deprecated Period, Phase, and Cycle variables. The date/times in SE allow any date/time to be
placed in one subject Element, or before the first subject Element (before the trial) or after the last subject Element
(after the trial). Thus, if the subject Elements dataset is submitted, the deprecated period, phase, and cycle variables
are not needed.
An observation date/time may be compared to the date/times in the Subject Elements dataset in order to place that
observation in the proper element. However, if the date/time of the observation is equal to the end date/time of one
element and the start date/time of the following element, then it is not immediately clear whether the observation
should be assigned to the element that is ending or to the element that is starting. Thus Sponsors should choose a
convention for assigning observations to one element or the other, and document the convention. It will be
particularly important to specify this convention if date/times are collected only to the nearest day, when "ties" of
this kind will be fairly common.
The sequence of subject Elements may be compared to the planned sequence of Elements for the Arm to which the
subject was assigned. If the sequences match (or if the actual sequence is a truncated version of the planned
sequence, as when a subject withdraws early) then it makes sense to associate a value of TAETORD with each
subject Element. For trials with Epochs, values of EPOCH may also be associated with subject Elements.
If a subject’s planned and actual sequences of Elements do not match, then it may not make sense to associate values
of TAETORD or EPOCH with the subject Elements, depending on the use that is being made of TAETORD or
EPOCH.

7.8

SUBJECT VISITS

Subject Visits (SV) describes the visits a subject passed through, with their start and end date/times.

7.8.1

Identifying Subject Visits

Visit start and end date/times are usually collected directly. In many studies, only a single visit date is collected for
each visit. This single date can be used to populate both start and end date/time.
Unplanned Visits commonly occur in clinical trials, and records for unplanned visits should be included in SV.
Mechanisms for labeling unplanned visits are in common use. SDS is not recommending particular conventions for
populating VISIT, VISITNUM, and VISITDY for unplanned visits at this time.

Page 116
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.8.2

Recap of Subject Visits Variables

Variables

Purpose

STUDYID, DOMAIN, USUBJID

Identifiers

VISIT, VISITNUM, VISITDY

Variables that name and order the visits

SVSTDTC, SVENDTC

Date/times of start and end of this visit for this subject

SVUPDES

Permissible variable. Blank except for unplanned Visits.
Describes the unplanned Visit.

7.9

TRIAL INCLUSION/EXCLUSION CRITERIA

The Trial Inclusion Exclusion Domain (TI) is not subject oriented. It contains all the inclusion and exclusion criteria
for the trial, and thus provides information that may not be present in the subject-level data on inclusion and
exclusion criteria. The IE Domain (described in Section 6.3.2) contains records only for inclusion and exclusion
criteria that a subject did not meet, and thus includes only criteria which one or more subjects failed to meet.
Inclusion and Exclusion Criteria are rules, so the TI domain includes both the familiar text version of a criterion,
IETEST, and a Rule version, TIRL.
ti.xpt, Trial Inclusion/Exclusion Criteria, Version 3.1.1. August 26, 2005. One record per I/E criterion
Variable Label

Type Controlled Origin
Terms or
Format

Role

STUDYID

Study Identifier

Char

CRF

Identifier Unique identifier for a study within the
submission.

DOMAIN

Domain Abbreviation

Char

**TI

Derived

Identifier Two-character abbreviation for the domain. Req

IETESTCD

Inclusion/Exclusion
Criterion Short Name

Char

Sponsor Defined

Topic

IETEST

Inclusion/Exclusion
Criterion

Char

Sponsor Defined / Synonym Full text of the inclusion or exclusion
Req
Protocol
Qualifier criterion. The prefix “IE” is used to ensure
consistency with the IE domain.

IECAT

Inclusion//Exclusion
Category

Char *INCLUSI Sponsor Defined
ON,
EXCLUSI
ON

Grouping 'Used to categorization of the inclusion or
Qualifier exclusion criteria.

TIRL

Inclusion/Exclusion
Criterion Rule

Char

Rule

Variable
Name

CDISC, © 2005. All rights reserved
FINAL

Sponsor Defined

CDISC Notes

Core

Req

Short name IETEST. It can be used as a
Req
column name when converting a dataset
from a vertical to a horizontal format. The
value in IETESTCD cannot be longer than 8
characters, nor can it start with a number
(e.g.,'1TEST'). IETESTCD cannot contain
characters other than letters, numbers, or
underscores. The name “IE” prefix is used
to ensure consistency with the IE domain.

Req

Optional rule that expresses the criterion in Perm
computer-executable form.

Page 117
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

7.10

TRIAL SUMMARY INFORMATION

The Trial Summary Model allows the sponsors to submit a summary of the trial in a structured format. The Trial Summary
dataset contains values for each characteristic described for a trial. Trial Summary is used to record basic information about
the study such as trial phase, protocol title, and trial objectives. The Trial Summary domain contains information about the
planned trial characteristics such as length of trial, planned number of subjects, planned maximum age of subject and others.
The Trial Summary (TS) domain does not contain subject level data or data that can be derived from subject data. Thus, for
example, it includes the number of subjects planned for the trial but not the number of subjects enrolled in the trial.
ts.xpt, Trial Summary, Version 3.1.1, August 26, 2005. One record per trial summary parameter
Variable
Label

Variable
Name

Type

STUDYID

Study
Identifier

DOMAIN

Domain
Char
Abbreviation
Sequence
Num
Number

Controlled
Terms or
Format

Char

Origin
Derived

**TS

Role

CDISC Notes

Identifier Unique identifier for a study within the submission.

Derived

Identifier Two-character abbreviation for the domain most
relevant to the observation.
TSSEQ
Derived Identifier Sequence number given to ensure uniqueness within a
dataset. Allows inclusion of multiple records for the
same parm, and can be used to join related records.
TSPARMCD Trial
Char
**
Derived
Topic
Short name for the Parameter described in TSPARM.
The value in TSPARMCD cannot be longer than 8
Summary
Parameter
characters, nor can it start with a number. TSPARMCD
cannot contain characters other than letters, numbers, or
Short Name
underscores. Examples: DESIGN, MASK, COMPTRT
TSPARM
Trial
Char
**
Derived Synonym Term for the Trial Summary Parameter. The value in
Summary
Qualifier TSPARM cannot be longer than 40 characters.
Parameter
Examples: Description Of Trial Design, Trial Blinding
Schema, Comparative Name Of Treatment
TSVAL
Value of TSPARM. Example: 'ASTHMA' when
Derived Result
Parameter Char **
Qualifier
TSPARM value is 'Trial Indications'. TSVAL cannot
Value
be null – a value is required for the record to be valid.
The first 200 characters of TSVAL will be in TSVAL,
then next 200 in TSVAL1, and continuing as needed to
TSVALn.
* indicates variable may be subject to sponsor-controlled terminology; ** indicates variable may be subject to external
controlled terminology.

Core
Req
Req
Req
Req

Req

7.10.1.1 Assumptions for Trial Summary (TS) domain model
1.
2.
3.
4.
5.
6.

The intent of the domain model is to provide a summary of the trial information. This is not subject level data.
TSVAL may have controlled terminology depending on the value of TSPARMCD, see appendix 10.3.5
"Trial Summary" for more information.
Trial Summary is similar to the COMMENTS special-purpose domain. It allows for one value to span
multiple variables (TSVAL-TSVALn) in order to accommodate values longer than 200 characters.1
The TSPARMCD value 'PHASE' is not defined with any exactness since it can vary by drug class.
For LENGTH OF TRIAL is defined as the planned length of time for a subject's participation. For
"LENGTH OF TRIAL", units for duration are not needed. See Section 4.1.4.3.
For some trials, there will be multiple records in the Trial Summary dataset for a single parameter such as.
"TYPE OF TRIAL" since a trial could be for both the Safety and Efficacy parameters. In this case, when
TSPARMCD=TYPE there will be two records for TSVAL, one with the value of 'SAFETY' and the other
with the value of 'EFFICACY'.

Allowing for multiple variables per comment is an interim solution until the limitations posed by SAS® Version 5 transport files
are eliminated.

Page 118
August 26, 2005

CDISC, © 2005. All rights reserved
FINAL

CDISC SDTM Implementation Guide (Version 3.1.1)

7.11

HOW TO MODEL THE DESIGN OF A CLINICAL TRIAL

The following steps allow the modeler to move from familiar concepts, such as Arms, to less familiar concepts, such
as Elements and Epochs. The actual process of modeling a trial may depart from these numbered steps. Some steps
will overlap, there may be several iterations, and not all steps are relevant for all studies.
1.

Start from the flow chart or schema diagram usually included in the trial protocol. This diagram will show how
many arms the trial has, and the branch points, or decision points, where the arms diverge.

Write down the decision rule for each branching point in the diagram. Does the assignment of a subject to an
arm depend on a randomization? On whether the subject responded to treatment? On some other criterion?

If the trial has multiple branching points, check whether all the branches that have been identified really lead to
different Arms. The Arms will relate to the major comparisons the trial is designed to address. For some trials,
there may be a group of somewhat different paths through the trial that are all considered to belong to a single
Arm.

For each arm, identify the major time periods of treatment and non-treatment a subject assigned to that arm will
go through. These are the Elements, or building blocks, of which the Arm is composed.

Define the starting point of each Element. Define the rule for how long the Element should last. Determine
whether the element is of fixed duration.

Re-examine the sequences of Elements that make up the various Arms and consider alternative Element
definitions. Would it be better to 'split' some Elements into smaller pieces or 'lump' some Elements into larger
pieces? Such decisions will depend on the aims of the trial and plans for analysis.

Compare the various Arms. In most clinical trials, especially blinded trials, the pattern of Elements will be
similar for all Arms, and it will make sense to define Trial Epochs. Assign names to these Epochs. During the
conduct of a blinded trial, it will not be known which Arm a subject has been assigned to, or which treatment
Elements they are experiencing, but the Epochs they are passing through will be known.

Identify the Visits planned for the trial. Define the planned start timings for each visit, expressed relative to the
ordered sequences of Elements that make up the Arms. Define the rules for when each visit should end.

Identify the inclusion and exclusion criteria to be able to populate the TI domain.

CDISC, © 2005. All rights reserved
FINAL

Page 119
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8 Representing Data
Relationships
Although each domain in a regulatory submission is defined to stand alone as a separate dataset, there are many
occasions when it is necessary or desirable to represent relationships among datasets or records, such as
relationships between separate domains, or between domains and other special-purpose datasets. In some cases, this
is necessary because the fixed structure of the SDTM observation classes restricts the ability of sponsors to represent
data that do not entirely fit within those structures. The SDTM accommodates five distinct types of relationships,
which are described in more detail in subsequent sections.
•

Section 8.1 describes a relationship between a group of records for a given subject within the same domain.

•

Section 8.2 describes a relationship between independent records (usually in separate domains) for a
subject, such as a concomitant medication taken to treat an adverse event.

•

Section 8.3 describes a relationship between two (or more) datasets where all the records of one (or more)
dataset(s) have parent or counterpart record(s) in another dataset (or datasets).

•

Section 8.4 describes a dependent relationship between data that cannot be represented by a standard
variable in the general class and a parent record (or records) within a domain.

•

Section 8.5 describes a dependent relationship between a comment and a parent record (or records) in other
domains, such as a comment recorded with an adverse event.

•

Section 8.6 discusses the concept of related datasets and whether to place additional data in a domain or
supplemental qualifier table

See appendix 10.6 for a proposed approach for modeling findings data that may refer to interventions or events
information.
All relationships make use of the standard domain identifiers, STUDYID, DOMAIN, and USUBJID. In addition,
the variables IDVAR and IDVARVAL are essential for identifying the record-level merge/join keys. The specific set
of identifiers necessary to properly identify each type of relationship is described in detail in the following sections.
The Sequence Number (--SEQ) variable uniquely identifies a record for a given USUBJID within a domain.
--SEQ is required in all domains except DM. For example, if subject 1234-2003 has 25 adverse event records in the
adverse event (AE) domain, AESEQ values for this subject should be the numbers 1 to 25, with numbering starting
over with 1 for the next subject. Numbers may, however, be omitted from the sequence if the sponsor assigns the
numbers early in the process and subsequently deletes some records.
The Reference Identifier (--REFID) variable can be used to capture a sponsor-defined or external identifier, such as
an identifier provided in an electronic data transfer. Some examples are lab-specimen identifiers, ECG identifiers, or
image filename identifier (sometimes used to reference external files such as medical images or waveform ECGs).
--REFID is permissible in all domains, but never required. Values for --REFID are sponsor defined and can be any
alphanumeric strings the sponsor chooses, consistent with their internal practices.
The Group Identifier (--GRPID) variable is explained below in section 8.1.

Page 120
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.1

RELATING GROUPS OF RECORDS WITHIN A DOMAIN

The optional grouping identifier variable --GRPID is permissible in all domains that are based on the general
observation classes to identify relationships between records within a domain (such as Intervention records for a
combination therapy). The relationship is defined by assigning the same unique (within USUBJID) character value
to the --GRPID variable. All records for a subject in a domain are considered to be related when they have the same
--GRPID value. The --GRPID values are only meaningful within the domain, and in the Relate Records (RELREC),
Supplemental Qualifiers (SUPPQUAL), and Comments (COMMENTS) datasets, as described in subsequent
sections. The values used for --GRPID can be any values the sponsor chooses; however, the philosophy for
assigning values should be consistent across the submission to avoid confusion. For example, --GRPID could be
any or all of the following:

The therapy name for multiple exposure records associated with a combination therapy

A sponsor-defined term used to group sets of questions together in the Questionnaire (QS) domain

Any sponsor-defined constant value used to group multiple concomitant medications together to indicate
they were all taken to treat the same condition.

Using --GRPID in the SDS Domains can be helpful to reduce the number of records in the RELREC, SUPPQUAL,
and COMMENTS datasets when it is necessary to use those datasets to capture/identify relationships/associations
for records or values to a 'group' of parent/peer records.

8.1.1

--GRPID Example

The following table illustrates how to use --GRPID in the Concomitant Medications (CM) domain to identify a
combination therapy. Note that the example only includes the most relevant variables from CM for this example;
the complete CM domain might include other variables not shown below. In this example, subject 1234 has
reported two combination therapies, each consisting of three separate medications. Each component of a
combination is given the same value for GRPID.
STUDYID DOMAIN USUBJID CMSEQ

CMGRPID

CMTRT

CMDECOD CMDOSE CMDOSU CMSTDTC CMENDTC

1234

COMBO THPY 1

Verbatim
Med A

Generic
Med A

100

2004-01-17

2004-01-19

1234

COMBO THPY 1

Verbatim
Med B

Generic
Med B

2004-01-17

2004-01-19

1234

COMBO THPY 1

Verbatim
Med C

Generic
Med C

200

2004-01-17

2004-01-19

1234

COMBO THPY 2

Verbatim
Med D

Generic
Med D

150

2004-01-21

2004-01-22

1234

COMBO THPY 2

Verbatim
Med E

Generic
Med E

100

2004-01-21

2004-01-22

1234

COMBO THPY 2

Verbatim
Med F

Generic
Med F

2004-01-21

2004-01-22

Page 121
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.2

RELATING PEER RECORDS IN SEPARATE DATASETS

The Related Records (RELREC) dataset is used to describe relationships between records in two (or more) datasets,
such as an Event record and an Intervention record, or a Finding record and an Event record.
A relationship is defined by creating RELREC records for each of the records to be related and by assigning a unique
character identifier value for the relationship. Each RELREC record contains keys that identify a record
(or group of records) and the relationship identifier, which is stored in the RELID variable. The value of RELID can
be any constant value chosen by the sponsor.
Records expressing a relationship are specified using the keys STUDYID, RDOMAIN, and USUBJID, which are
populated with the values for STUDYID, DOMAIN, and USUBJID from the SDS domain records, along with an
IDVAR and an IDVARVAL. Single records can be related by using --SEQ in IDVAR. Groups of records can be
specified by using --GRPID in IDVAR and the appropriate --GRPID value in IDVARVAL. Using the optional
grouping identifier variable --GRPID (see section 8.1) to group a set of related records in the domains can be a more
efficient method of representing relationships in RELREC, such as when relating an adverse event (or events) to a
“group” of concomitant medications taken to treat the adverse event(s).
For example, suppose adverse events are determined at the investigational site to be associated with the
administration of a concomitant medication used in standard care. Since the adverse events and the concomitant
medication are captured in separate domains, a separate record in the RELREC dataset must be used to describe the
observed association among these records.
The RELREC dataset should be used only when the sponsor either:
1. Collects information about explicit relationships, such as concomitant medications taken as a result of an
adverse event
2.

Determines there is a scientific rationale or reporting need to identify relationships after data collection such
as determining that an adverse event was due to a concomitant medication, or

Collects information of a nature that necessitates using multiple datasets, as described in section 8.3.

This is not to imply that a sponsor should retrospectively identify all potential relationships in the RELREC dataset;
instead, the purpose of the RELREC dataset is to give sponsors a standardized way to represent such relationships
when a sponsor identifies a specific need to do so. The RELREC dataset should only be used to associate entire
observations on a one-to-one or one-to-many level. Additional Qualifier variables that cannot be represented in
existing variables in Findings, Interventions, or Events domains should be represented using the Supplemental
Qualifiers (SUPPQUAL) dataset, which is described in Section 8.4.

Page 122
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.2.1

RELREC Dataset
relrec.xpt, Related Records, Version 3.1.1, August 26, 2005. One record per record or domain relationship
Variable

Variable
Label

Type

CDISC Notes

STUDYID

Study
Identifier

Char

Study Identifier of the SDS domain record(s).

RDOMAIN

Related
Domain
Abbreviation

Char*

Domain Abbreviation of the SDS domain record(s).

USUBJID

Unique Subject
Identifier

Char

Unique Subject Identifier of the SDS domain record(s).

IDVAR

Identifying
Variable

Char**

Value of the identifying variable in the general class dataset that
identifies the related record(s). Examples include --SEQ and --GRPID.

IDVARVAL

Identifying
Variable Value

Char

Value of identifying variable described in IDVAR. If --SEQ is the
variable being used to describe this record, then the value of --SEQ
would be entered here.

RELTYPE

Relationship
Type

Char**

Identifies the hierarchical level of the records in the relationship.
Values should be either ONE or MANY. However, values are only
necessary when identifying a relationship between datasets (as
described in Section 8.3).

RELID

Relationship
Identifier

Char

Unique value within USUBJID that identifies the relationship. All
records for the same USUBJID that have the same RELID are
considered 'related/associated.' RELID can be any value the sponsor
chooses, and is only meaningful within the RELREC dataset to identify
the related/associated Domain records.

* indicates variable may be subject to sponsor-controlled terminology
** indicates variable may be subject to external controlled terminology.

8.2.2

RELREC Dataset Examples

Example A:
Example A shows how to use the RELREC dataset when USUBJID 123456 had two lab tests (LBSEQ values
of 47 and 48) and took two concomitant medications (CMSEQ values of 11 and 12) as the result of an adverse event
(AESEQ value of 5). This example assumes that the lab values and the concomitant medications are not related to
each other.
STUDYID

RDOMAIN

USUBJID

IDVAR

IDVARVAL

RELTYPE

RELID

EFC1234

123456

AESEQ

EFC1234

123456

CMSEQ

EFC1234

123456

CMSEQ

EFC1234

123456

AESEQ

EFC1234

123456

LBSEQ

EFC1234

123456

LBSEQ

NOTE: The two lab tests could have the same LBGRPID if they were on the same specimen. In such a case, the two
RELREC records with RDOMAIN=LB could be replaced with one RELREC record with IDVAR=LBGRPID and
IDVARVAL having the LBGRPID value assigned in the LB domain.
CDISC, © 2005. All rights reserved
FINAL

Page 123
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Example B:
Example B is the same scenario as Example A; however, the concomitant medications and lab tests are associated
with each other in addition to being associated with the adverse event.
STUDYID

RDOMAIN

USUBJID

IDVAR

IDVARVAL

RELTYPE

RELID

EFC1234

123456

AESEQ

EFC1234

123456

CMSEQ

EFC1234

123456

CMSEQ

EFC1234

123456

LBSEQ

EFC1234

123456

LBSEQ

Example C:
Example C is the same scenario as Example B, however, both the concomitant medications are necessary for this
treatment and have been assigned a CMGRPID of 'COMBO 1' by the sponsor, allowing the elimination of a record in
the RELREC dataset.
STUDYID

RDOMAIN

USUBJID

IDVAR

IDVARVAL

EFC1234

123456

AESEQ

EFC1234

123456

CMGRPID

COMBO1

EFC1234

123456

LBSEQ

EFC1234

123456

LBSEQ

8.3

RELTYPE

RELID
1

RELATING DATASETS

The Related Records (RELREC) dataset can also be used to identify relationships between datasets (e.g., a one-tomany or parent-child relationship, as discussed in Section 8.3.1). The relationship is defined by including a single
record for each related dataset that identifies the key(s) of the dataset that can be used to relate the respective records.
Relationships between datasets should only be recorded in the RELREC dataset when the sponsor has found it
necessary to split information between datasets that are related, and that may need to be examined together for
analysis or proper interpretation. It is not necessary to use the RELREC dataset to identify associations from data in
the SUPPQUAL dataset or the COMMENTS dataset, as both these datasets include the key variable identifiers of the
parent record that are necessary to make the association.

8.3.1

RELREC Dataset Relationship Example

This example shows how to use the RELREC dataset to represent related information that is submitted as two
datasets which have a one-to-many relationship. In the example below all the records in one domain are being related
to all of the records in the other so both USUBJID and IDVAR are null.
STUDYID

RDOMAIN

EFC1234

USUBJID

IDVAR

IDVARVAL

RELTYPE

RELID

MBSPID

ONE

MSSPID

MANY

In the sponsor's operational database, these datasets may have existed as either separate datasets that were merged for
analysis, or one dataset that may have included observations from more than one observation class (e.g., Events and
Findings). The value in IDVAR should be the name of the key used to merge/join the two datasets. In the above
example, the --SPID variable is used as the single key to identify the related observations. The values for the --SPID

Page 124
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

variable in the two datasets are sponsor defined. Although other variables may also serve as a single merge key when
the corresponding values for IDVAR are equal, --SPID or --REFID are typically used for this purpose.
Since IDVAR identifies the keys that can be used to merge/join all records between the datasets, the root values
(i.e., --SPID in the above example) for IDVAR must be the same for both records with the same RELID. --SEQ
cannot be used because --SEQ only has meaning within a dataset, not across datasets.

8.4

RELATING NON-STANDARD VARIABLE VALUES TO A
PARENT DOMAIN

The Supplemental Qualifiers (SUPPQUAL) special purpose dataset model is used to capture non-standard variables
and their association to parent records in domains, and allows capturing values for variables not presently included in
the general-observation-class models. Because the SDTM does not allow the addition of new variables, it is
necessary for sponsors to represent the metadata and data for each non-standard variable/value combination in a
SUPPQUAL dataset. The SUPPQUAL dataset model is structured similarly to the RELREC dataset, in that it uses the
same set of keys to identify related records. Each SUPPQUAL record also includes the name of the Qualifier
variable being added (QNAM), the label for the variable (QLABEL), the actual value for each instance or record
(QVAL), the origin (QORIG) of the value (whether it was collected via CRF, assigned or derived), and the Evaluator
(QEVAL) to specify the role of the individual who assigned the value (such as ADJUDICATION COMMITTEE or
SPONSOR).
One common case for using a SUPPQUAL dataset is to capture attributions. An attribution is typically an
interpretation or subjective classification of one or more observations by a specific evaluator, such as a population
flag that classifies a subject or their data according to their evaluability for efficacy analysis. Since it is possible that
different attributions may be necessary in some cases, SUPPQUAL provides a mechanism for incorporating as many
attributions as are necessary. It is recognized that sponsors may also need to use a SUPPQUAL dataset to submit
additional non-standard variables that cannot be represented in the general classes. Standard names for certain
expected values for QNAM and QLABEL are included in Appendix 10.3.4.
The combined set of values for the first six columns (STUDYID…QNAM) should be unique for every record. That
is, there should not be multiple records in a SUPPQUAL dataset for the same QNAM value, as it relates to
IDVAR/IDVARVAL for a USUBJID. For example, if two individuals provide a determination on whether an Adverse
Event is Treatment Emergent (e.g., the investigator and an independent adjudicator) then separate QNAM values
should be used for each set of information, perhaps AETRTEMI and AETRTEMA. This is necessary to ensure that
reviewers can join/merge/transpose the information back with the records in the original domain without risk of
losing information.
When populating a SUPPQUAL dataset with population flags related to the Demographics domain (subject-level
evaluability), there should be one record for each population flag for each subject. QVAL values for population flags
should be Y or N, with no Null values. In the event that evaluability is based upon individual visits or CRF pages,
additional population flags attached to other domains may be included in SUPPQUAL datasets.
Just as use of the optional grouping identifier variable --GRPID can be a more efficient method of representing
relationships in RELREC, it can also be used in a SUPPQUAL dataset to identify individual qualifier values
(SUPPQUAL records) related to multiple domain records that could be grouped, such as relating an attribution to a
group of ECG measurements.

Page 125
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.4.1

SUPPQUAL Dataset

suppqual.xpt, Supplemental Qualifiers, Version 3.1.1, August 26, 2005. One record per variable
Variable

Variable Label

STUDYID Study Identifier
RDOMAIN Related Domain
Abbreviation
USUBJID Unique Subject
Identifier
IDVAR
Identifying
Variable
IDVARVAL Identifying
Variable Value
QNAM
Qualifier Variable
Name

QLABEL

QVAL

QORIG

QEVAL

Type

CDISC Notes

References

Char Study Identifier of the Parent record(s).
Char* Domain Abbreviation of the Parent record(s). Null for an attribution
(e.g., ITT) that may apply for all records in all domains for a subject.
Char Unique Subject Identifier of the Parent record(s).

SDTM 2.2.4
SDTM 2.2.4
SDTM 2.2.4

Char* Identifying variable in the dataset that identifies the related record(s).
Examples: --SEQ, --GRPID.
Char Value of identifying variable of the parent record(s).

Char* The short name of the Qualifier variable, which is used as a column
SDTMIG
name in a domain view with data from the parent domain. The value in 4.1.5.2
QNAM cannot be longer than 8 characters, nor can it start with a
number (e.g.,'1TEST'). QNAM cannot contain characters other than
letters, numbers, or underscores. This will often be the column name in
the sponsor’s operational dataset.
Qualifier Variable Char This is the long name or label associated with QNAM. The value in
Label
QLABEL cannot be longer than 40 characters. This will often be the
column label in the sponsor’s original dataset.
Data Value
Char Result of, response to, or value associated with QNAM. A value for this
column is required; no records can be in SUPPQUAL with a null value
for QVAL.
Origin
Char* Since QVAL can represent a mixture of collected (on a CRF), derived,
or assigned items, QORIG is used to indicate the origin of this data.
Examples include CRF, ASSIGNED, or DERIVED.
Evaluator
Char* Used only for results that are subjective (e.g., assigned by a person or a
group). Should be null for records that contain objectively collected or
derived data. Some examples include ADJUDICATION
COMMITTEE, STATISTICIAN, DATABASE ADMINISTRATOR,
CLINICAL COORDINATOR, PRIMARY INVESTIGATOR, etc.

* indicates variable may be subject to sponsor-controlled terminology;
** indicates variable may be subject to external controlled terminology.
Note all variables except QEVAL must be populated for each record. A record in a SUPPQUAL dataset relates back to its
general observation class dataset parent record(s) via the key identified in the IDVAR variables. SUPPQUAL dataset
records that are related to all subject records in all domains, such as the Intent To Treat (ITT) and Safety (SAFETY)
subject-level population flags, will have both IDVAR and IDVARVAL set to null. This is because the only keys needed to
identify the relationship/association to all subject records (for that subject) in all domains are STUDYID and USUBJID.
A SUPPQUAL dataset can contain both objective data (where values are collected or derived algorithmically) and
subjective data (attributions where values are assigned by a person or committee). For objective data, the value in QEVAL
will be null. For subjective data (when QORIG=”ASSIGNED”), the value in QEVAL should reflect the role of the person
or institution assigning the value (e.g., PRIMARY INVESTIGATOR or ADJUDICATION COMMITTEE).
All records in the SUPPQUAL datasets must have a value for QVAL. Transposing source variables with missing/null
values may inadvertently generate SUPPQUAL records with null values for QVAL, causing the SUPPQUAL dataset to be
extremely large. When this happens, the sponsor should delete the records where QVAL is null prior to submission.

Page 126
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.4.2

Submitting Supplemental Qualifiers in Separate Datasets

Because sponsors often have a large number of supplemental qualifier variable values, the SDTM IG has defined a
preferred approach to submit supplemental qualifiers by domain rather than placing all of the supplemental information
within one dataset. Following this convention for the supplemental qualifiers produces a one-to-one correspondence
between a domain dataset and its supplemental qualifier dataset. In such cases, the following rules should be met:
•

The set of supplemental qualifiers for each domain should be included in a separate dataset with the name
supp-- where -- denotes the source domain which the supplemental qualifiers relates back to. For example,
population flags and other demographic qualifiers would be placed in suppdm.xpt.

•

For users conforming to V3.1.1 and later versions of the SDTMIG, a SUPPQUAL dataset should NOT be
submitted in addition to separate supp-- datasets for individual domains. In other words, separate
supplemental qualifier domains cannot be used with some domains and SUPPQUAL for the other s).

8.4.3

SUPPQUAL Examples

The example below demonstrates how a set of SUPPQUAL datasets should be used to relate non-standard
information to a parent domain.
In the first two rows of suppdm.xpt, population flags are defined as supplemental information to a subject’s
demography data. Since IDVAR and IDVARVAL are not populated, we know that the qualifying information is
applicable to the subject as a whole, not to any specific record.
The next two rows of suppae.xpt add qualifying information to adverse event data. IDVAR defines the key variable
that links this information to the AE data (AESEQ). IDVARVAL specifies the value of the key variable within the
parent record that the SUPPQUAL record applies to. The remaining rows specify the supplemental variables’ names
(AESOTHC and AETRTEM), labels, values, origin (CRF or DERIVED), and who made the evaluation.
The final set of records in the suppqs.xpt example show how to record the language used for a questionnaire. The
parent domain (RDOMAIN) is QS, and the merge key (IDVAR) is QSCAT. QNAM holds the name of the
supplemental qualifier variable being defined (QSLANG). The language recorded in QVAL applies to all of a
subject’s records where IDVAR (QSCAT) equals IDVARVAL. In this case, IDVARVAL has values for two
questionnaires (SF36 and ADAS) for two separate subjects. QVAL identifies the questionnaire language version
(Flemish or Farsi) for each subject.
suppdm.xpt: Supplemental Qualifiers for DM
STUDYID RDOMAIN USUBJID IDVAR IDVARVAL QNAM
QLABEL
1996001
DM
99-401
ITT
Intent to Treat
1996001

99-401

QVAL
Y

PPROT Per Protocol Evaluable

QORIG
DERIVED

QEVAL
SPONSOR

DERIVED

SPONSOR

suppae.xpt: Supplemental Qualifiers for AE
STUDYID RDOMAIN USUBJID IDVAR IDVARVAL
1996001

99-401

AESEQ

1996001

99-401

AESEQ

QNAM

QLABEL

QVAL

AESOTHC Desc of Other Med Impt Spontaneous
Serious Event
Abortion
AETRTEM Treatment Emergent
N

QORIG

QEVAL

CRF
DERIVED SPONSOR

suppqs.xpt: Supplemental Qualifiers for QS
STUDYID RDOMAIN
1996001
1996001
1996001
1996001

QS
QS
QS
QS

USUBJID

IDVAR IDVARVAL QNAM

99-401
99-401
99-802
99-802

QSCAT
QSCAT
QSCAT
QSCAT

SF36
ADAS
SF36
ADAS

QSLANG
QSLANG
QSLANG
QSLANG

QLABEL
Questionnaire Language
Questionnaire Language
Questionnaire Language
Questionnaire Language

QVAL
FLEMISH
FLEMISH
FARSI
FARSI

QORIG QEVAL
CRF
CRF
CRF
CRF

Examples of data that should not be in the SUPPQUAL dataset include:

Subject-level objective data that fit in Subject Characteristics (SC)
ECG Interpretation -- this should be added as an additional test called EGINTP in EGTESTCD, and given
the same EGGRPID or EGREFID value for all records associated with that ECG.

Page 127
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

8.5

RELATING COMMENTS TO A PARENT DOMAIN

The Comments special-purpose domain, which is described in Section 5.1.2, is used to capture unstructured free text
comments. It allows for the submission of comments related to a particular domain (e.g., adverse events) or those
collected on separate general-comment pages not associated with a domain. Comments may be related to a Subject, a
domain for a Subject, or to specific parent records in any domain. The Comments domain is structured similarly to the
SUPPQUAL dataset, in that it uses the same set of keys (STUDYID, RDOMAIN, USUBJID, IDVAR and IDVARVAL)
to identify related records.
All comments are considered child records of data captured in domains. STUDYID, USUBJID, and DOMAIN
(with the value “CO”) must always be populated. RDOMAIN, IDVAR, and IDVARVAL should be populated as
follows:
1.

Comments related only to a subject in general would have RDOMAIN null, as the only key needed to
identify the relationship/association to that subject is USUBJID.

Comments related only to a specific domain (and not to any specific record) for a subject would populate
RDOMAIN with the code for the domain with which they are associated. IDVAR and IDVARVAL would
be null.

Comments related to specific domain records for a subject would populate the RDOMAIN, IDVAR, and
IDVARVAL variables with values from the parent record(s).

Again, --GRPID can be used as the value in IDVAR to identify comments with relationships to multiple domain
records, such as a comment that applies to a 'group' of concomitant medications.

8.5.1

COMMENTS Example

In the following example, Subject 1234-2004 has five separate comments: one comment on an adverse events (AE)
record, one on an exposure (EX) record, and one on a vital signs (VS) record; one on the PE CRF page, and another
on a separate comments CRF page. Another comments example is provided in Section 5.1.2.
STUDYID

DO RDO USUBJID CO IDVAR IDVAR COREF CODTC
MAIN MAIN
SEQ
VAL

1234

AE 1234-2004

1 AESEQ

1234

EX 1234-2004

2 EXSEQ

1234

VS 1234-2004

3 VSSEQ

1234

1234-2004

PAGE 40 2003-11-08

1234

1234-2004

2004-01-14

Page 128
August 26, 2005

PAGE
650

COVAL

COEVAL

Same AE has occurred
prior to treatment

PRINCIPAL
INVESTIGATOR

Some delays in taking
medications because of
vacation
Value confirmed in range,
but questionable based on
other related
measurements.
Subject was very
uncooperative during
physical exam.
Subject overall attitude has
improved greatly during
study.

PRINCIPAL
INVESTIGATOR
ADJUDICATION
COMMITTEE
PRINCIPAL
INVESTIGATOR
PRINCIPAL
INVESTIGATOR

CDISC SDTM Implementation Guide (Version 3.1.1)

8.6

HOW TO DETERMINE WHERE DATA BELONG IN THE SDTM

A domain is defined as a collection of observations on a particular topic. For example, Medical History is a
collection of information related to events or conditions that happened before the clinical study.
Typically the term 'domain' has been synonymous with a dataset. However, there may be cases where data related to
the same topic might, at times, need to be captured in more than one domain or observation class. In such cases,
information that may have been historically presented in a single dataset may now need to be represented in more
than one SDTM dataset. It is often necessary to refer to the protocol or statistical analysis plan to decide how to
model new data domains not modeled in the SDTMIG and understand whether a collection of information logically
belongs together in a single domain or dataset.
When determining how to model a new type of data, it is best to identify the domain topicality first and classify its
primary observation class as an Event, Intervention, or Finding (see section 2.4). To do this, begin by evaluating the
overall logical content of the information rather than analyzing the physical structure. Applying this principle to
Medical History, for example, note that the collected information is related to previous conditions or events,
regardless of whether dates were collected. Just because dates were not collected or available in specific cases does
not change the fact that the primary topicality fits Events. Conversely, if the topic of the information is more related
to specific measurements rather than just recording occurrences, it is typically modeled in the Findings class.
Once the domain topicality and its general observation class are identified, then the physical structure of the
information should be evaluated to verify whether all collected information can be represented in a single
observation class. Just because the information is collected /recorded on the same individual CRF pages does not
necessarily mean that all the data collected/recorded on those individual CRF pages belongs in the same domain.
Information grouped together on CRFs for convenience but obviously having different topicalities (such as
Concomitant Medications collected on SAE forms) should be mapped to multiple domains. If the sponsor feels that
it’s important for the reviewer to easily identify the relationship between the AE and CM records, then RELREC can
be used (see Section 8.2.1).
Information grouped together because it is dependent on other information, such as findings collected as a result of
an event, requires careful evaluation to determine whether all the information should be in a single domain, split into
multiple datasets, or submitted in a supplemental qualifiers dataset. The following guidelines should be used in
making this determination:
•

Submit data in a supplemental qualifiers special-purpose dataset (see Section 8.4) if the information that
does not fit consists only of additional variables that would not be classified as Identifiers, Topic, or Timing
variables in a separate domain. In other words, the information consists only of what would be classified as
additional Qualifiers to further describe an existing record, and would not be considered sufficient to exist
as an entire 'record' of information by itself in any observation class. A general way of thinking about this
is if the data would simply have been another column in the sponsor’s original dataset.

•

Submit data as a separate dataset if the information that does not fit could comprise a complete record in
that dataset (it contains variables that would be classified as Identifiers, Topic, or Timing variables). Section
8.2 describes how information should be stored in a second dataset of another general observation class for
the same Domain when the information has, at minimum a Topic Variable, its own Timing variables and
(for Findings domains) at least one Result Qualifier.

General rules for creating a separate related dataset of common topicality with another are as follows:
1.

Typically, additional datasets should be created for either
a.

Interventions with associated Findings, or

Events with associated Findings

Two sets of Findings that do not fit logically in a single dataset.

Page 129
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

The topicality of the information and the context determine the Parent (or master) dataset general
observation class (Interventions, Events or Findings). In some cases, a Parent (master) dataset may be
required, even if the records in that dataset have limited information

Both datasets should include a common identifier variable (e.g., --REFID) to capture the identification
(name) of the record to be used as a merge/join key: however, it is recognized that in some cases it
would be more appropriate to use --GRPID. Values for the --REFID or --GRPID variables would need
to be the same for related records in the two (or more) datasets.

Both datasets should use a different two-character code for a value in the Domain variable, and as the
variable prefix (MB and MS for example). The dataset names for the two datasets should be the twocharacter Domain codes chosen for the datasets (MB and MS respectively). Since it is not self-evident
that a Domain is captured in multiple datasets using this combination of dataset names (a reviewer
might not automatically know that MB and MS are related to each other), sponsors must populate the
RELREC dataset (see Section 8.2.1) with rows that identify the dataset relationship and document the
approach used in the Define file (metadata) and/or Annotated CRF. This approach is fully compatible
with the current V3.x standard as long as the dataset relationship is clearly documented.

Page 130
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9 Implementation Examples
9.1

DEMOGRAPHICS EXAMPLE

This is an example of demographics that illustrates the use of the RACE and ETHNIC variables. Both RACE and ETHNIC are subjected to the rules of
controlled terminology. Race (RACE) and ethnicity (ETHNIC) are independent of each other, for example, the first subject (USUBJID=1) is 'WHITE' for RACE
and 'HISPANIC OR LATINO' for ETHNIC. Ethnicity can only have two values, either 'HISPANIC OR LATINO' or 'NOT HISPANIC OR LATINO'. In cases of
mixed race, the RACE variable should be used for the primary race, and the SC domain should be used for additional non-primary race values. For example, in
Row 4, the 4th subject (USUBJID=4), who is recorded as 'ASIAN' for RACE could have the value 'INDIAN' in SC where SCTESTCD equals ‘RACEOTH.’
Row

STUDYID

DOMAIN

USUBJID

RACE

ETHNIC

Row 1

ABC123

WHITE

HISPANIC OR LATINO

Row 2

ABC123

WHITE

NOT HISPANIC OR LATINO

Row 3

ABC123

BLACK OR AFRICAN AMERICAN

NOT HISPANIC OR LATINO

Row 4

ABC123

ASIAN

NOT HISPANIC OR LATINO

Row 5

ABC123

AMERICAN INDIAN OR ALASKA NATIVE

NOT HISPANIC OR LATINO

Row 6

ABC123

NATIVE HAWAIIAN OR OTHER PACIFIC ISLANDERS

NOT HISPANIC OR LATINO

9.2

INTERVENTIONS EXAMPLES

9.2.1

CM Example: Intermittent Use of Concomitant Medications

Sponsors collect the timing of concomitant medication use with varying specificity, depending on the pattern of use; the type, purpose, and importance of the
medication; and the needs of the study. Often the same information can be conveyed with a range of dates and the daily frequency rather than presenting every
unique instance of medication use. If appropriate, medications taken intermittently or sporadically over a time period may be reported with a date range and a
frequency of 'PRN'.
The example below shows three subjects who took the same medication at the same times. For the first subject (USUBJID=1), each instance is recorded
separately, and frequency (CMDOSFRQ) is ONCE. For the second subject (USUBJID=2), the second record (CMSEQ=2) shows that aspirin was taken twice on
January 7th, so the frequency is BID. The frequency is also included for the other daily records to avoid confusion. The third subject’s (USUBJID=3) records are
CDISC, © 2005. All rights reserved
FINAL

Page 131
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
collapsed (this is shown as an example only, not as a recommendation) into a single entry that spans the relevant time period, with a frequency of PRN. This
approach assumes that knowing exactly when aspirin was used is not important for evaluating this study’s safety and efficacy.
Row

STUDYID

DOMAIN

USUBJID

CMSEQ

CMTRT

CMDOSFRQ

CMSTDTC

CMENDTC

Row 1

ABC123

Aspirin

ONCE

2004-01-01

Row 2

ABC123

Aspirin

ONCE

2004-01-02

Row 3

ABC123

Aspirin

ONCE

2004-01-03

Row 4

ABC123

Aspirin

ONCE

2004-01-07

Row 5

ABC123

Aspirin

ONCE

2004-01-07

Row 6

ABC123

Aspirin

ONCE

2004-01-09

Row 7

ABC123

Aspirin

2004-01-01

2004-01-03

Row 8

ABC123

Aspirin

BID

2004-01-07

Row 9

ABC123

Aspirin

2004-01-09

Row 10

ABC123

Aspirin

PRN

2004-01-01

2004-01-09

Page 132
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.2.2

EX Examples:

Exposure Example 1:
This is an example of an Exposure dataset for a parallel design study. In this example, subjects were randomized to one of three treatment groups: Drug A 40 mg
q.d., Drug A 20 mg q.d., or Drug B 150 mg bid. Drug A was in capsule form and Drug B was in tablet form. To maintain the blind, subjects took both capsules
and tablets with only one form being active. The study included 8 weeks of treatment, with subjects remaining on the same treatment throughout the study. With
respect to timing of doses, the sponsor only collected the start and stop dates of uninterrupted periods of treatment. Note below that Subject 12345003 missed
taking study medications on Study Days 23 and 24.
STUDYID DOMAIN

USUBJID

EXSEQ

EXTRT

EXDOSE EXDOSU

EXDOSFRM

Row 1

12345

12345001

DRUG A

CAPSULE

Row 2

12345

12345001

PLACEBO

Row 3

12345

12345002

DRUG A

Row 4

12345

12345002

PLACEBO

TABLET

Row 5

12345

12345003

PLACEBO

CAPSULE

Row 6

12345

12345003

DRUG B

150

Row 7

12345

12345003

PLACEBO

Row 8

12345

12345003

DRUG B

150

TABLET
MG

CAPSULE

TABLET
CAPSULE

TABLET

EXDOSFRQ

EXDOSTO
T

EXROUTE

EXSTDTC

EXENDTC

EXSTDY

EXENDY

Row 1 (cont)

ORAL

2002-01-10

2002-03-08

Row 2 (cont)

BID

ORAL

2002-01-10

2002-03-08

Row 3 (cont)

ORAL

2002-01-10

2002-03-07

Row 4 (cont)

BID

ORAL

2002-01-10

2002-03-07

Row 5 (cont)

ORAL

2002-01-11

2002-02-01

Row 6 (cont)

BID

300

ORAL

2002-01-11

2002-02-01

Row 7 (cont)

ORAL

2002-02-04

2002-03-06

Row 8 (cont)

BID

300

ORAL

2002-02-04

2002-03-06

Page 133
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Exposure Example 2:
This is an example of an Exposure dataset for a two-way crossover study comparing once daily oral administration of Drug A 20 mg with Drug B 30 mg. Study
drug was taken for 3 consecutive mornings 30 minutes prior to a standardized breakfast. There was a 5-day washout period between treatments.
STUDYID

DOMAIN

USUBJID

EXSEQ

EXGRPID

EXTRT

EXDOSFRM

EXDOSFRQ

Row 1

56789

56789001

DRUG A

Row 2

56789

56789001

DRUG A

CAPSULE

Row 3

56789

56789001

DRUG A

CAPSULE

Row 4

56789

56789001

Row 5

56789

56789001

DRUG B

TABLET, COATED

DRUG B

TABLET, COATED

Row 6

56789

56789001

DRUG B

TABLET, COATED

Row 7

56789

56789003

Row 8

56789

56789003

DRUG B

TABLET, COATED

DRUG B

TABLET, COATED

Row 9

56789

56789003

DRUG B

TABLET, COATED

Row 10

56789

Row 11

56789

56789003

DRUG A

CAPSULE

56789003

DRUG A

CAPSULE

Row 12

56789

56789003

DRUG A

CAPSULE

EXDOSTOT EXROUTE

EXDOSE EXDOSU

EXSTDTC

EXENDTC

EXSTDY

EXENDY

EXTPT

Row 1 (cont)

ORAL

2002-07-01T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 2 (cont)

ORAL

2002-07-02T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 3 (cont)

ORAL

2002-07-03T07:32

30 MINUTES PRIOR TO STD BREAKFAST

Row 4 (cont)

ORAL

2002-07-09T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 5 (cont)

ORAL

2002-07-10T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 6 (cont)

ORAL

2002-07-11T07:34

30 MINUTES PRIOR TO STD BREAKFAST

Row 7 (cont)

ORAL

2002-07-03T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 8 (cont)

ORAL

2002-07-04T07:24

30 MINUTES PRIOR TO STD BREAKFAST

Row 9 (cont)

ORAL

2002-07-05T07:24

30 MINUTES PRIOR TO STD BREAKFAST

Row 10 (cont)

ORAL

2002-07-11T07:30

30 MINUTES PRIOR TO STD BREAKFAST

Row 11 (cont)

ORAL

2002-07-12T07:43

30 MINUTES PRIOR TO STD BREAKFAST

Row 12 (cont)

ORAL

2002-07-13T07:38

30 MINUTES PRIOR TO STD BREAKFAST

Page 134
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.2.3

SU Example:

Example and Usage Notes for V3.1.1 Substance Use (SU) Domain Model
The use of the Interventions general observation class to model substance use data meets the needs of the complex, detailed dosing, frequency, and duration
information requirements for analysis where collection of this information is key to the outcome of a clinical trial (e.g., smoking cessation).
This example is for clinical trials where detailed substance use dosing, frequency, and duration information is required (e.g., smoking cessation trials). In such
cases, detailed information (e.g., smoking substance, total amount per day, start and stop dates) about the substance used is collected. This data could then be
used in primary efficacy analyses to support therapy effectiveness claims. Figure 9.2.3.1 presents a CRF that captures data of this nature. The information in the
gray bar/ellipses is the sponsor's original annotation.

Page 135
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Figure 9.2.3.1 - Sample Case Report Form for Smoking Status
Visit x

Smoking Status

SMOKING

SMOKCAT

Please identify one of the following smoking categories for the subject:

Non-smoker (never smoked)

SMOKSDT

Start date

Not assessed

NOTDONE

SMOKEDT

Stop date

Ex smoker

Current smoker

If Ex or Current smoker, complete detail section below, checking all that apply

SMOKTYPE

Cigars

per day. Round to next highest whole number. Specify average daily amount
smoked during the time the subject smoked.

Pipe

bowls per day. Round to next highest whole number. Specify average daily amount
smoked during the time the subject smoked.

Cigarettes

per day. Round to next highest whole number. Specify average daily amount
smoked during the time the subject smoked.
TOBACONO

Page 136
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Table 1 presents data that could be captured using the detailed smoking status CRF presented in Figure 9.2.3.1 using the Sponsor’s Operational database
structure.
Row 1: Subject is a non-smoker.
Row 2: Subject is an ex-smoker. Detailed substance use information is provided.
Rows 3, 4: Subject is an ex-smoker of more than one type of tobacco. Detailed substance use information is provided.
Row 5: Subject is a current smoker. Detailed substance use information is provided.
Rows 6, 7: Subject came in for 2 visits, for the first visit subject was an ex-smoker. At the 2nd visit, subject began to smoke again. Detailed substance use
information is provided.
Row 8: Subject did not have an assessment done.
Table 1: Data Captured Using the Detailed Smoking Status CRF in the Sponsor’s Operational Database
STUDYID

USUBJID

VISIT

SEQ

SMOKCAT

SMOKTYPE

TOBACONO

SMOKSDT

SMOKEDT

Row 1

1234

1234005

NON

Row 2

1234

1234006

CIGARS

1977

2003

Row 3

1234

1234007

PIPE

01-01-2000

04-02-2003

Row 4

1234

1234007

CIGARETTES

01-01-1990

04-02-1993

Row 5

1234

1234008

CURRENT

CIGARETTES

1945

Row 6

1234

1234009

CIGARS

1965

Row 7

1234

1234009

CURRENT

CIGARETTES

01-01-2003

Row 8

1234

1234010

NOTDONE

1970

Table 2 presents the data structured according to the SDTM. If this was a multi-page CRF, collecting multiple substance use information (for example, tobacco
use and alcohol consumption) then SUCAT would have values of TOBACCO and ALCOHOL. As the primary physiological impact of tobacco use is due to
nicotine content, the value of SUDECOD was set to NICOTINE. SUSTRF and SUENRF hold the values of SMOKCAT as they are interpreted based on the
subject's use status at sponsor-defined start and end reference timeframes.
Row 1: Because this subject did not consume tobacco products, the value of SRTRT was set to 'Tobacco'. In addition, the values of SUSTRF and SUENRF are
set to NULL, and the value of SUOCCUR could be set to "N" because this subject did not use any tobacco products.
Row 8: Because the assessment for this subject was not done, the value of SUSTAT was set to NOT DONE.
CDISC, © 2005. All rights reserved
FINAL

Page 137
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Table 2: Data from Example 3 Modeled in SDS V3.x SU Domain
STUDYID

USUBJID

SUSEQ

SUTRT

SUDECOD

SUCAT

Row 1

1234

1234005

TOBACCO

NICOTINE

TOBACCO

Row 2

1234

1234006

CIGARS

NICOTINE

Row 3

1234

1234007

PIPE

Row 4

1234

1234007

Row 5

1234

Row 6

SUSTRF

SUENRF

TOBACCO

BEFORE

AVG/DAY

NICOTINE

TOBACCO

BEFORE

AVG/DAY

CIGARETTES NICOTINE

TOBACCO

BEFORE

AVG/DAY

1234008

CIGARETTES NICOTINE

TOBACCO

BEFORE

ONGOING

AVG/DAY

1234

1234009

NICOTINE

TOBACCO

BEFORE

AVG/DAY

Row 7

1234

1234009

CIGARETTES NICOTINE

TOBACCO

DURING

ONGOING

AVG/DAY

Row 8

1234

1234010

VISITNUM

CIGARS

TOBACCO

SUSTDTC

SUENDTC

Row 1 (cont)

Row 2 (cont)

1977

2003

Row 3 (cont)

2000-01-01

2003-02-04

Row 4 (cont)

1990-01-01

1993-02-04

Row 5 (cont)

1945

Row 6 (cont)

1965

Row 7 (cont)

2003-01-01

Row 8 (cont)

SUSTAT

SUDOSFRQ SUDOSTOT

NOT DONE

1970

Not all variables specified in the CDISC SU domain are present on the example CRF. Since they are not used, the variables are not present on the SU dataset.

Page 138
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.3

EVENTS EXAMPLES

9.3.1

AE Example

In this example, an AE CRF collects AE terms as free text. There is a section at the bottom of the form for free-text comments. AEs are collected one time per
study. In this example, first study drug was administered to the subject on 13Oct2003 at 12:00. 3 AEs were reported. AEs are coded using MedDRA and the
sponsor’s procedures include the possibility of modifying the reported term to aid in coding.
Notes:
1.
2.
3.
4.
5.

Not all variables specified in the CDISC AE domain are present on the CRF (e.g., AEACNOTH, AERELNST, AEDUR). Since they are not used, the
variables are not present in the AE dataset. However, all required and expected variables are present and populated.
Comments would be placed in the Comments domain (CO).
The CRF is structured so that serious category variables (e.g., AESDTH, AESHOSP) are checked only when an overall seriousness question is answered 'Y.'
If a subject had no adverse events reported, no records are included for that subject in the AE dataset.
If a subject has a value for AEENDTC then AEENRF is null.

Sample data that illustrates the above:
STUDYID DOMAIN USUBJID AESEQ
Row 1 ABC123

123101

AETERM

AESTDTC

AEENDTC

AEMODIFY

AEDECOD

POUNDING HEADACHE

2003-10-12

HEADACHE

Row 2 ABC123

123101

BACK PAIN FOR 6 HOURS 2003-10-13T13:05 2003-10-13T19:00 BACK PAIN

Row 3 ABC123

123101

PULMONARY EMBOLISM

Row 1 (cont)
Row 2 (cont)

2003-10-21

AEBODSYS

AESEV

AESER

NERVOUS SYSTEM DISORDERS

SEVERE

MUSCULOSKELETAL AND CONNECTIVE TISSUE DISORDERS MODERATE
VASCULAR DISORDERS

Row 3 (cont)
AEOUT

MODERATE

BACK PAIN
PULMONARY EMBOLISM

AEACN

AEREL

NOT APPLICABLE DEFINITELY NOT RELATED

DOSE REDUCED

PROBABLY RELATED

DOSE REDUCED

PROBABLY NOT RELATED

AESCONG AESDISAB AESDTH AESHOSP AESLIFE

AESMIE

AESTDY AEENDY AEENRF

Row 1 (cont)

RECOVERED/RESOLVED

-1

Row 2 (cont)

RECOVERED/RESOLVED

Row 3 (cont)

RECOVERING/RESOLVING

AFTER

Page 139
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.3.2

DS Examples

Disposition Example 1:
In this example, a DS CRF collects multiple disposition events at different time points in the study indicated by EPOCH. There are also several protocol
milestones which are indicated by DSCAT = 'PROTOCOL MILESTONE'. DSTERM is populated with controlled terminology with the same value as
DSDECOD except in the case when there is free text for DSTERM such as 'Subject moved'. In this case, the controlled terminology is only in DSDECOD
(LOST TO FOLLOW-UP).
Notes
1.
2.
3.

Not all variables specified in the CDISC DS domain are present on the CRF (e.g., DSSCAT, DSSTDY). Since they are not used; the variables are not
present on the DS dataset. However, all required and expected variables are present and populated.
In the Events observation class, the date/time of the Disposition Event is the DSSTDTC variable. The date of collection of the disposition information is
the DSDTC variable
EPOCH can be derived from VISITNUM. In the example below, when VISITNUM = 0, then EPOCH = SCREENING. EPOCH is populated when
DSCAT is a disposition event and null when DSCAT is a protocol milestone.

There are multiple disposition events for each subject:
1. Subject 123101 has 3 records to indicate the completion of 3 stages of the study, which are screening, treatment phase and follow-up. Protocol milestone
records for informed consent and randomization are also included.
2. Subject 123102 is a screen drop. Screen drops are identified by a DSDECOD that is not equal to 'COMPLETED' for the SCREENING stage. This is an
example of the submission of the verbatim reason for discontinuation in DSTERM.
3. Subject 123103 completed the screening stage but did not complete the treatment stage.
4. Subject 123104 died on October 29, 2003 (see DSSTDTC) after the completion of treatment, but prior to the completion of follow-up. Note that the date of
collection of the event information was on October 31, 2003 (DSDTC).
5. Subject 123105 discontinued study treatment due to an AE, but went on to complete the follow-up phase of the trial.

Page 140
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Sample data that illustrates the above:
STUDYID DOMAIN USUBJID DSSEQ
ABC123

123101

ABC123
ABC123
ABC123

DS
DS
DS

123101
123101
123101

2
3
4

ABC123
ABC123

DS
DS

123101
123102

5
1

ABC123

123102

Row 8

ABC123

123103

Row 9
Row 10

ABC123
ABC123

DS
DS

123103
123103

2
3

Row 11

ABC123

123103

Row 12

ABC123

123104

Row 13
Row 14
Row 15

ABC123
ABC123
ABC123

DS
DS
DS

123104
123104
123104

2
3
4

Row 16

ABC123
ABC123

DS
DS

123104
123105

5
1

ABC123
ABC123
ABC123

DS
DS
DS

123105
123105
123105

2
3
4

Row 21 ABC123

123105

Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7

Row 17
Row 18
Row 19
Row 20

DSTERM

DSDECOD

DSCAT

INFORMED CONSENT INFORMED CONSENT PROTOCOL MILESTONE
OBTAINED
OBTAINED
COMPLETED
COMPLETED
DISPOSITION EVENT
RANDOMIZED
RANDOMIZED
PROTOCOL MILESTONE
COMPLETED
COMPLETED
DISPOSITION EVENT
COMPLETED
COMPLETED
DISPOSITION EVENT
INFORMED CONSENT INFORMED CONSENT PROTOCOL MILESTONE
OBTAINED
OBTAINED
DISPOSITION EVENT
SUBJECT DENIED MRI
PROTOCOL
PROCEDURE
VIOLATION
INFORMED CONSENT INFORMED CONSENT PROTOCOL MILESTONE
OBTAINED
OBTAINED
COMPLETED
COMPLETED
DISPOSITION EVENT
RANDOMIZED
RANDOMIZED
PROTOCOL MILESTONE
SUBJECT MOVED

LOST TO FOLLOW-UP

DISPOSITION EVENT

INFORMED CONSENT INFORMED CONSENT PROTOCOL MILESTONE
OBTAINED
OBTAINED
COMPLETED
COMPLETED
DISPOSITION EVENT
RANDOMIZED
RANDOMIZED
PROTOCOL MILESTONE
COMPLETED
COMPLETED
DISPOSITION EVENT
SUBJECT DIED
DEATH
DISPOSITION EVENT
INFORMED CONSENT INFORMED CONSENT PROTOCOL MILESTONE
OBTAINED
OBTAINED
COMPLETED
COMPLETED
DISPOSITION EVENT
RANDOMIZED
RANDOMIZED
PROTOCOL MILESTONE
ANEMIA
ADVERSE EVENT
DISPOSITION EVENT
COMPLETED

COMPLETED

DISPOSITION EVENT

VISITNUM

EPOCH

0
0
1
2

DSDTC

DSSTDTC

2003-09-21 2003-09-21
SCREENING

3
0

2003-09-29 2003-09-29
2003-09-30 2003-09-30
TREATMENT 2003-10-31 2003-10-31
PHASE
FOLLOW-UP 2003-11-15 2003-11-15
2003-11-21 2003-11-21

SCREENING

2003-11-22 2003-11-20
2003-09-15 2003-09-15

0
1

SCREENING

TREATMENT 2003-10-31 2003-10-31
PHASE
2003-09-15 2003-09-15

0
0
1
2
1
0
0
1
2
3

2003-09-22 2003-09-22
2003-09-30 2003-09-30

SCREENING

2003-09-22 2003-09-22
2003-09-30 2003-09-30
TREATMENT 2003-10-15 2003-10-15
PHASE
FOLLOW-UP 2003-10-31 2003-10-29
2003-09-28 2003-09-28
SCREENING

2003-10-02 2003-10-02
2003-10-02 2003-10-02
TREATMENT 2003-10-17 2003-10-17
PHASE
FOLLOW-UP 2003-11-02 2003-11-02

Page 141
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Disposition Example 2:
In this example, the sponsor has chosen to simply submit whether or not the subject completed the study. Examples are shown of 1 subject who completed the
study and 2 who discontinued prior to completion. In this very straightforward situation, only required and expected variables have been included.
STUDYID

DOMAIN

USUBJID

DSSEQ

DSTERM

DSDECOD

DSSTDTC

Row 1

ABC456

456101

COMPLETED

2003-09-21

Row 2

ABC456

456102

SUBJECT TAKING STUDY MED ERRATICALLY

PROTOCOL VIOLATION

2003-09-29

Row 3

ABC456

456103

LOST TO FOLLOW-UP

2003-10-15

Disposition Example 3:
In this example, the sponsor collects whether or not the subject completes the treatment and follow-up phases as well as whether the subject’s treatment
assignment was unblinded. The date of the unblinding is represented in DSSTDTC. Note that maintaining the blind as per protocol is not considered to be an
event since there is no change in the subject’s state.

Row 1
Row 2
Row 3
Row 4
Row 5

Page 142
August 26, 2005

STUDYID

DOMAIN

USUBJID

DSSEQ

DSCAT

EPOCH

DSTERM

DSDECOD

DSSTDTC

ABC789

789101

DISPOSITION
EVENT

TREATMENT
PHASE

COMPLETED

2004-09-12

ABC789

789101

DISPOSITION
EVENT

FOLLOW-UP

COMPLETED

2004-12-20

ABC789

789102

DISPOSITION
EVENT

TREATMENT
PHASE

SKIN RASH

ADVERSE
EVENT

2004-09-30

ABC789

789102

ABC789

789102

OTHER EVENTS TREATMENT SUBJECT HAD TREATMENT
PHASE
SEVERE RASH UNBLINDED
DISPOSITION
EVENT

FOLLOW-UP

COMPLETED

2003-10-01
2004-12-28

CDISC SDTM Implementation Guide (Version 3.1.1)

9.3.3 MH Example:
In this example, a study collects medical history information using 3 separate CRFs. A general medical history CRF collects descriptions of events by body
system (e.g., Endocrine, Metabolic) and asks whether the conditions were ongoing or not at study start (Rows 1-3). The reported events are coded using
MedDRA. Another CRF asks whether the subject had any of a list of specific risk factors. The third CRF collects the primary diagnosis and onset date. Risk
factors and primary diagnosis are not coded using MedDRA.
Notes
a.
b.
c.
d.
e.

Not all variables specified in the CDISC MH domain are present on the CRF (e.g., MHENDTC). Since they are not used, the variables are not
present in the MH dataset shown. However, all required variables are present and populated.
Comments, if provided, would be placed in the Comments domain (CO).
MHCAT is used to specify the category of data collected (GENERAL MEDICAL HISTORY, RISK FACTORS, PRIMARY DIAGNOSIS).
MHSCAT displays the body systems specified on the general medical history CRF.
The “Ongoing at Study Start” question on the general medical history has been translated to MHENRF. If “Yes” is specified,
MHENRF=”DURING/AFTER;” if “No” is specified, MHENRF=”BEFORE.”

Sample data that illustrates the above:
STUDYID DOMAIN USUBJID MHSEQ

MHTERM

MHDECOD

MHCAT

MHSCAT

Row 1 ABC123

123101

ASTHMA

GENERAL MEDICAL HISTORY

RESPIRATORY

Row 2 ABC123

123101

FREQUENT HEADACHES

HEADACHE

GENERAL MEDICAL HISTORY

CNS

Row 3 ABC123

123101

BROKEN LEG

BONE FRACTURE

GENERAL MEDICAL HISTORY

OTHER

Row 4 ABC123

123101

HYPERTENSION

RISK FACTORS

Row 5 ABC123

123101

TIA

RISK FACTORS

Row 6 ABC123

123101

STROKE

PRIMARY DIAGNOSIS

MHBODSYS

MHSTDTC

MHENRF

Row 1 (cont)

RESPIRATORY SYSTEM DISORDERS

DURING/AFTER

Row 2 (cont)

CENTRAL AND PERIPHERAL NERVOUS SYSTEM DISORDERS

DURING/AFTER

Row 3 (cont)

MUSCULOSKELTAL SYSTEM DISORDERS

BEFORE

Row 4 (cont)
Row 5 (cont)
Row 6 (cont)

2004-09-17T07:30

Page 143
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4

FINDINGS EXAMPLES

9.4.1

EG Examples

ECG Example 1:
This is an example of an ECG dataset for one subject at one visit where cycle measurements, findings, and an interpretation were delivered to the sponsor by an
ECG provider. EGREFID is an internal or external ECG identifier that links to the external ECG Waveform Files. EGXFN is the file name for the external ECG
Waveform file.
Rows 1-6 - Show how ECG cycle measurements are represented.
Rows 2-6 - Show the data in original units of measure in EGORRES and in the converted value in EGSTRESC and EGSTRESN
Rows 5-6 - Show QTCB and QTCF. The actual data should have a 'Y' in the EGDRVFL column since these results are derived by the sponsor in this example.
See assumption 4.1.5.1.
Rows 7-10 - Show how ECG findings are represented.
Row 11

- Shows a way of representing comments that are important to the overall understanding of the ECG, but which are not truly findings or
interpretations.

Row 12

- Shows how interpretations are represented.

Page 144
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
STUDYID DOMAIN

Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11
Row 12

XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ

USUBJID

EG
EG
EG
EG
EG
EG
EG
EG
EG
EG
EG
EG

XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002
XYZ-US-701-002

VISIT

EGORRES

62
0.15
0.103
0.406
0.469
0.446
ATRIAL
FIBRILLATION
Row 8 (cont) Screening 1 ATRIAL FLUTTER
Row 9 (cont) Screening 1 QT PROLONGATION

Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)

Screening 1
Screening 1
Screening 1
Screening 1
Screening 1
Screening 1
Screening 1

Row 10 (cont) Screening 1 LEFT VENTRICULAR
HYPERTROPHY
Row 11 (cont) Screening 1
Row 12 (cont) Screening 1

INCORRECT
ELECTRODE
PLACEMENT
ABNORMAL,
CLINICALLY
INSIGNIFICANT

EGSEQ EGGRPID EGREFID EGTESTCD
1
2
3
4
5
6
7
8
9
10
11
12

1
1
1
1
1
1
1
1
1
1
1
1

334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89
334PT89

EGORRESU

EGSTRESC

bpm
sec
sec
sec
sec
sec

62
150
103
406
469
446
ATRIAL
FIBRILLATION
ATRIAL FLUTTER
QT
PROLONGATION
LEFT
VENTRICULAR
HYPERTROPHY
INCORRECT
ELECTRODE
PLACEMENT
ABNORMAL,
CLINICALLY
INSIGNIFICANT

VRATE
PR
QRS
QT
QTCB
QTCF
RHYRATE
RHYRATE
QTABN
VCABN
TECHPROB
INTP

EGTEST

EGXFN

EGNAM

EGPOS

Ventricular Rate
PR Interval
QRS Interval
QT Interval
QTc - Bazett
QTc - Fridericia
Rhythm and Rate
Rhythm and Rate
QT Abnormalities
Ventricular Conduction Abnormalities
Technical Problems
Interpretation

PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07
PQW436789-07

Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab
Test Lab

SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE
SUPINE

EGSTRESN EGSTRESU
62
150
103
406
469
446

EGEVAL

bpm
msec
msec
msec
msec
msec

PRINCIPAL
INVESTIGATOR

VISITNUM

EGDTC

EGDY

1
1
1
1
1
1
1

2003-04-15T11:58
2003-04-15T11:58
2003-04-15T11:58
2003-04-15T11:58
2003-04-15T11:58
2003-04-15T11:58
2003-04-15T11:58

-36
-36
-36
-36
-36
-36
-36

1
1

2003-04-15T11:58
2003-04-15T11:58

-36
-36

2003-04-15T11:58

-36

2003-04-15T11:58

-36

2003-04-15T11:58

-36

Page 145
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

ECG Example 2:
Example 2 shows results for one subject across multiple visits where only the overall assessment was collected. In addition the ECG done at Visit 4 was read by
the principal investigator and a cardiologist. In this example the EGGRPID is the same number and the EGSEQ increments by one.
Row 2 - The only one selected as Baseline.
Row 3 - Shows a date/time in ISO 8601 representation where both the date and time were collected.
STUDYID DOMAIN

USUBJID

EGSEQ EGGRPID EGTESTCD EGTEST EGPOS EGORRES EGSTRESC

Row 1

ABC

ABC-99-CA-456

ECGINT

ECG Result SUPINE

Row 2

ABC

ABC-99-CA-456

ECGINT

ECG Result SUPINE ABNORMAL ABNORMAL

Row 3

ABC

ABC-99-CA-456

ECGINT

ECG Result SUPINE ABNORMAL ABNORMAL

Row 4

ABC

ABC-99-CA-456

ECGINT

ECG Result SUPINE ABNORMAL ABNORMAL

Row 5

ABC

ABC-99-CA-456

ECGINT

ECG Result SUPINE ABNORMAL ABNORMAL

EGSTRESN EGBLFL EGEVAL

NORMAL

VISIT

VISITNUM

VISITDY

EGDTC

EGDY

SCREEN I

-2

2003-11-26

-2

SCREEN II

-1

2003-11-27

-1

Row 3 (cont)

DAY 10

2003-12-07T09:02

Row 4 (cont)

DAY 18

2003-12-12

Row 5 (cont)

Cardiologist

DAY 18

2003-12-12

Row 1 (cont)
Row 2 (cont)

Page 146
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.2

IE Example

This example shows records for four subjects, each of whom had a single inclusion/exclusion exception. Subject XYZ-0007 met exclusion criteria number 17,
but was included in the trial. The other three subjects each failed to meet inclusion criteria number 3, but were included in the trial.
STUDYID DOMAIN

USUBJID

IESEQ

IETESTCD

IETEST

IECAT

IESPID

IEORRES

IESTRESC

Row 1

XYZ

XYZ-0007

EXCL17

Ventricular Rate

EXCLUSION

Row 2

XYZ

XYZ-0023

INCL03

Acceptable mammogram from local INCLUSION
radiologist?

Row 3

XYZ

XYZ-0047

INCL03

Acceptable mammogram from local INCLUSION
radiologist?

Row 4

XYZ

XYZ-0096

INCL03

Acceptable mammogram from local INCLUSION
radiologist?

VISIT

VISITNUM

VISITDY

IEDTC

IEDY

Row 1 (cont)

WEEK-8

-63

1999-01-10

-58

Row 2 (cont)

WEEK-8

-63

1999-01-06

-62

Row 3 (cont)

WEEK-8

-63

1999-01-12

-56

Row 4 (cont)

WEEK-8

-63

1999-01-13

-55

Page 147
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.3

LB Examples

Example 1:
Row 1

- Shows a value collected in one unit, but converted to selected standard unit.

Rows 2, 3, 4 - Rows 2 and 3 show two records for Alkaline Phosphatase done at the same visit, one day apart. Row 4 shows how to create a derived record
(average of the records 2 and 3) and flagged derived and as the one to use as baseline.
Rows 6, 7

- Show a suggested use of the LBSCAT variable. It could be used to further classify types of tests within a laboratory panel (i.e.,
“DIFFERENTIAL”).

Row 9

- Shows the proper use of the LBSTAT variable to indicate "NOT DONE", where a reason was collected when a test was not done.

Row 10

- Shows one subject's data collected at two different visits. For Visit 1 the subject had cholesterol measured. The normal range for this test is
<200 mg/dL. The value <200 may not be used in the normal range variables LBORNRHI or LBSTNRHI; however, a sponsor may decide, for
example, to enter '0' into LBORNRLO and '199' in LBORNRHI. The sponsor must define the appropriate value for all of the normal range
variables.

STUDYID DOMAIN
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11

ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC

LB
LB
LB
LB
LB
LB
LB
LB
LB
LB
LB

USUBJID
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001

LBSEQ LBTESTCD
1
2
3
4
5
6
7
8
9
10
11

ALB
ALKP
ALKP
ALKP
WBC
LYMPH
NEUT
PH
ALB
CHOL
WBC

LBTEST
Albumin
Alkaline Phosphatase
Alkaline Phosphatase
Alkaline Phosphatase
WBC Count
Lymphocytes
Neutrophils
pH
Albumin
Cholesterol
WBC Count

LBCAT

LBSCAT

LBORRES LBORRESU LBORNRLO LBORNRHI

Chemistry
Chemistry
Chemistry
Chemistry
Hematology
Hematology DIFFERENTIAL
Hematology DIFFERENTIAL
Urinalysis
Chemistry
Chemistry
Hematology

34
398
350
5.9
6.7
5.1
7.5
229
5.9

g/L
IU/L
IU/L
IU/L
10^9/L
%
10^9/L

mg/dL
10^9/L

LBSTRESC LBSTRESN LBSTRESU LBSTNRLO LBSTNRHI LB STAT LBREASND LBBLFL LBFAST LBDRVFL
Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Page 148
August 26, 2005

3.4
398
350

g/dL
units/L
units/L

3.5
40
40

5
160
160

Y
Y
Y

VISIT
BASELINE
BASELINE
BASELINE

35
40
40

50
160
160

4
25
2
5.0

11
40
8
9.0

0
4

199
11

VISITNUM LBDTC
1
1
1

1999-06-19
1999-06-19
1999-06-20

CDISC SDTM Implementation Guide (Version 3.1.1)
LBSTRESC LBSTRESN LBSTRESU LBSTNRLO LBSTNRHI LB STAT LBREASND LBBLFL LBFAST LBDRVFL
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)
Row 8 (cont)
Row 9 (cont)
Row10 (cont)
Row11 (cont)

374
5.9
0.4
5.1
7.5

374
5.9
0.4
5.1

units/L
10^3/uL
10^9/L
10^9/L

40
4
1.2
2
5.00

160
11
3
8
9.00

Y
Y
Y
Y
Y

NOT INSUFFICIENT
DONE
SAMPLE
229
5.9

229
5.9

mg/dL
10^3/uL

0
4

5.85
11

VISIT

VISITNUM LBDTC

BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
VISIT 1

1
1
1
1
1
2

1999-06-19
1999-06-19
1999-06-19
1999-06-19
1999-06-19
1999-07-21

VISIT 1
VISIT 1

2
2

1999-07-21
1999-07-21

Page 149
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Example 2:
This is an example of three sequential timed urine collections measuring glucose.
Rows 1

- Shows an example of a pre-dose urine collection interval (from 4 hours prior to dosing until 15 minutes prior to dosing) with a negative value for
LBELTM that reflects the end of the interval in reference to the fixed reference LBTPTREF, the date of which is recorded in LBRFTDTC.
--RFTDTC is a new timing variable added to version 1.1 of the SDTM, and is incorporated in SDTM 3.1.1 to meet this purpose.

Rows 2, 3 - Show an example of post-dose urine collection intervals with values for LBELTM that reflect the end of the intervals in reference to the fixed
reference LBTPTREF, the date of which is recorded in LBRFTDTC.

STUDYID DOMAIN

USUBJID

LBSEQ LBTESTCD

LBTEST

LBCAT

LBORRES LBORRESU LBORNRLO LBORNRHI

Row 1

ABC

ABC-001-001

GLUCOSE Glucose

Urine

mg/dL

Row 2

ABC

ABC-001-001

GLUCOSE Glucose

Urine

mg/dL

Row 3

ABC

ABC-001-001

GLUCOSE Glucose

Urine

mg/dL

LBSTRESC

LBSTRESN LBSTRESU

LBSTNRLO

LBSTNRHI

VISIT

VISITNUM

Row 1 (cont)

0.38

mmol/L

0.1

0.8

BASELINE

Row 2 (cont)

0.61

mmol/L

0.1

0.8

BASELINE

Row 3 (cont)

0.5

mmol/L

0.1

0.8

BASELINE

LBDTC

LBENDTC

LBTPT

LBTPTNUM

LBELTM

LBTPTREF

LBRFTDTC

Row 1 (cont)

1999-06-19T04:00

1999-06-19T07:45

Pre-dose

-P15M

Dosing

1999-06-19T08:00

Row 2 (cont)

1999-06-19T08:00

1999-06-19T16:00

0-8 hours after dosing

P8H

Dosing

1999-06-19T08:00

Row 3 (cont)

1999-06-19T16:00

1999-06-20T00:00

8-16 hours after dosing

P16H

Dosing

1999-06-19T08:00

Page 150
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.4

PE Example

The example shows data for one subject collected at two different visits. In all of the records except 6 and 11 the data comes from the general physical
examination. In this case PECAT is "General". Additional data collected on about an ophthalmologic examination is also added to this domain, refer to rows
eight and thirteen.
Row 1

- Shows how PESTRESC is populated if result is 'NORMAL'.

Row 2

- Shows the proper use of the STAT variable to indicate "NOT DONE", and when PEREASND is used to indicate why a body system (PETEST) was
not examined.

Row 4-6

- Show how PESPID is used to show the sponsor-defined identifier, which in this case is a sequence number used for identifying abnormalities
within a body system.

Row 4-7

- Show how PESTRESC is populated if abnormality is dictionary coded.

Rows 8, 13 - Show how the PECAT variable can be used to indicate a different type of physical examination. In this case, the ophthalmologic examination may
have been collected in a separate dataset in the operational database.

Page 151
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
STUDYID DOMAIN USUBJID PESEQ PETESTCD
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11
Row 12
Row 13

ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC

PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PE
PESTRESC

Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)
Row 8 (cont)
Row 9 (cont)
Row 10 (cont)
Row 11 (cont)
Row 12 (cont)
Row 13 (cont)

Page 152
August 26, 2005

ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
PESEV

1
2
3
4
5
6
7
8
9
10
11
12
13

PETEST

PEREASND

NORMAL

NORMAL
ACNE NOS
MILD
DERMATITIS MODERATE
RASH
SEVERE
CARDIAC
NORMAL
NORMAL
NORMAL
NORMAL
NORMAL
NORMAL

PELOC

PEBODSYS

PEORRES

NORMAL
HEAD
Head
GENERAL
RESP
Respiratory
GENERAL
NORMAL
ENT
Ear/nose/throat
GENERAL
SKIN
Skin
GENERAL
FACE
SKIN AND
ACNE
SKIN
Skin
GENERAL
HANDS
SKIN AND
ALLERGIC REACTION
SKIN
Skin
GENERAL
LEFT ARM
SKIN AND
SKINRASH
CARDIO Cardiovascular
GENERAL
INVESTIGATIONS SYSTOLIC
NORMAL
FUNDOSCP Fundoscopic OPHTALMOLOGIC
NORMAL
RESP
Respiratory
GENERAL
NORMAL
ENT
Ear/nose/throat
GENERAL
NORMAL
NECK
Neck
GENERAL
NORMAL
CARDIO Cardiovascular
GENERAL
NORMAL
FUNDOSCP Fundoscopic OPHTALMOLOGIC

PESTAT
NOT
DONE

PECAT

INVESTIGATOR
ERROR

PESPID

VISIT

VISITNUM VISITDY

1
1

BASELINE
BASELINE

1
1

1
1
2
3
1
1
1
1
1
1
1

BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
VISIT 1
VISIT 1
VISIT 1
VISIT 1
VISIT 1

1
1
1
1
1
1
2
2
2
2
2

PEDTC

PEDY

1
1

1999-06-06
1999-06-06

-3
-3

1
1
1
1
1
1
45
45
45
45
45

1999-06-06
1999-06-06
1999-06-07
1999-06-08
1999-06-06
1999-06-06
1999-07-21
1999-07-21
1999-07-21
1999-07-21
1999-07-21

-3
-3
-2
-1
-3
-3
45
45
45
45
45

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.5

QS Examples

Example 1:
This is an example of data from a questionnaire from one subject at one visit with standard text answers that have an associated score. In this example the subject
answered all of the questions in Rows 1-4 and Rows 7-9. The standard text (e.g., very good) translates to a score of 4.4. The value of 4.4 is populated in both
QSSTRESN and QSSTRESC. Since this is the baseline data there is a flag in all records in QSBLFL. The values in Rows 5, 6, 10, and 11 are derived from previous
records and are flagged with a Y in QSDRVFL. The example shows how the textual answer is handled in the QSORRES Variable, while the QSSTRESC and
QSSTRESN contain the standardized score value.
Rows 5, 6, 10, 11 - Show derived records. Notice how QSORRES is blank for derived records because there is no corresponding text value for the numeric
value shown (see section 4.1.5.1).

Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11

STUDYID

DOMAIN

USUBJID

QSSEQ

QSTESTCD

QSTEST

QSCAT

QSSCAT

STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX

QS
QS
QS
QS
QS
QS
QS
QS
QS
QS
QS

P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001

1
2
3
4
5
6
7
8
9
10
11

GH1
GH11A
GH11B
GH11C
GH
GHINDEX
RP4A
RP4B
RP4C
RP
RPINDEX

Heath
Sick a litter easier
Healthy as anybody
Expect health to get worse
SF-36 General health perceptions
SF-36 General health perceptions (0-100)
Phys. Health-cut down time spent
Phys. Health-accomplished less
Phys. Health-limit kind of work
SF-36 Role-physical
SF-36 Role-physical (0-100)

SF36
SF36
SF36
SF36
SF36
SF36
SF36
SF36
SF36
SF36
SF36

GENERAL HEALTH
GENERAL HEALTH
GENERAL HEALTH
GENERAL HEALTH
GENERAL HEALTH
GENERAL HEALTH
ROLE-PHYSICAL
ROLE-PHYSICAL
ROLE-PHYSICAL
ROLE-PHYSICAL
ROLE-PHYSICAL

Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)
Row 8 (cont)
Row 9 (cont)
Row 10 (cont)
Row 11 (cont)

QSORRES

QSSTRESN

QSSTRESC

QSBLFL

VERY GOOD
MOSTLY FALSE
MOSTLY TRUE
DEFINITELY FALSE

4.4
4
4
5
21.4
82
2
2
2
8
100

Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y

NO
NO
NO

QSDRVFL

Y
Y

VISITNUM

VISIT

QSDTC

QSDY

2
2
2
2
2
2
2
2
2
2
2

BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE

2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28
2001-03-28

-2
-2
-2
-2
-2
-2
-2
-2
-2
-2
-2

Page 153
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

Example 2:
This example show data from one subject collected at one visit for a questionnaire with standard text answers. These answers cannot be converted to numeric
type, so only QSSTRESC is populated. The derived record, however, does have a derived value in QSSTRESN. Notice how QSTPTNUM is used to organize
the same question being asked at various time points on the same date where no time was collected. In rows 1-3 QSTEST is ARM and QSTPTNUM is
incremented 1,2,3. When QSTEST changes to BUTTER the number in QSTPTNUM start again at 1.
Row 11 - Shows derived records. Notice how QSORRES is blank for derived records because there is no corresponding text value for the numeric value shown
(see section 4.1.5.1).

Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11

STUDYID

DOMAIN

USUBJID

QSSEQ

QSTESTCD

QSTEST

QSCAT

QSSCAT

QSORRE
S

QSSTRES
C

STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX
STUDYX

QS
QS
QS
QS
QS
QS
QS
QS
QS
QS
QS

P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001
P0001

1
2
3
4
5
6
7
8
9
10
11

COG01T02
COG01T02
COG01T02
COG01T03
COG01T03
COG01T03
COG01T04
COG01T04
COG01T04
COG01T09
COG01X

ARM
ARM
ARM
BUTTER
BUTTER
BUTTER
CABIN
CABIN
CABIN
GRASS
WORD RECALL

ADAS
ADAS
ADAS
ADAS
ADAS
ADAS
ADAS
ADAS
ADAS
ADAS
ADAS

WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL
WORD RECALL

NO
NO
NO
NO
NO
NO
NO
NO
NO
NO

NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
9

QSSTRESN
Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)
Row 8 (cont)
Row 9 (cont)
Row 10 (cont)
Row 11 (cont)

Page 154
August 26, 2005

QSBLFL

QSDRVFL

VISIT

VISITNUM

VISITYDY

QSDTC

QSDY

QSTPTNUM

SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING
SCREENING

1
1
1
1
1
1
1
1
1
1
1

-14
-14
-14
-14
-14
-14
-14
-14
-14
-14
-14

2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20
2001-03-20

-10
-10
-10
-10
-10
-10
-10
-10
-10
-10
-10

1
2
3
1
2
3
1
2
3
1
99

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.6

SC Example

The example below shows data that is collected once per subject that does not change during the trial and does not fit into the demographics domain. For this
example the eye color and initials were collected.
Rows 1, 4 Illustrate use of an additional Race response. In this case, the value of RACE in DM would be 'OTHER'.

STUDYID DOMAIN

USUBJID

SCSEQ SCTESTCD

SCTEST

Row 1

ABC

ABC-001-001

Row 2

ABC

ABC-001-001

Row 3

ABC

ABC-001-001

SUBJINIT Subject Initials

ABC

ABC-001-002

RACEOTH Race Other

Row 5

ABC

ABC-001-002

Row 6

ABC

ABC-001-002

Row 7

ABC

ABC-001-003

Row 8

ABC

ABC-001-003

Row 9

ABC

ABC-002-001

Row 10

ABC

ABC-002-001

Row 4

RACEOTH Race Other
EYECD

EYECD

Eye Color

SUBJINIT Subject Initials
EYECD

Eye Color

SUBJINIT Subject Initials
EYECD

Eye Color

SUBJINIT Subject Initials

SCORRES SCSTRESC

VISIT

VISITNUM

SCDTC

JAPANESE JAPANESE

Baseline

1999-06-19

BROWN

Baseline

1999-06-19

HLT

Baseline

1999-06-19

ALASKA
NATIVE

Baseline

1999-03-19

BLUE

Baseline

1999-03-19

BAM

Baseline

1999-03-19

GREEN

Baseline

1999-05-03

ALM

Baseline

1999-05-03

HAZEL

Baseline

1999-06-14

CQH

Baseline

1999-06-14

Page 155
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.4.7

VS Example

The example below shows one subject with two visits, Baseline and Visit 1, including examples of both collected and derived baseline measurements.
Rows 1-2, 4-5, 8, 9 -VSTPT and VSTPTNUM are populated since more than one measurement was taken at this visit.
Rows 3, 6 - Show an example of a derived value that was not considered to be an original result. In this case the sponsor derived the value in a different variable
in the operational database. VSTPT and VSTPTNUM are not populated for these derived records.
Rows 8, 9 - Show two temperatures taken at the baseline visit. Row 9 has a "Y" in the VSBLFL to indicate it was used as the baseline measurement.
Row 14

- Shows a value collected in one unit, but converted to selected standard unit.

Row 15

- Shows the proper use of the STAT variable to indicate "NOT DONE" where a reason was collected when a test was not done.

Page 156
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

STUDYIDDOMAIN
Row 1
Row 2
Row 3
Row 4
Row 5
Row 6
Row 7
Row 8
Row 9
Row 10
Row 11
Row 12
Row 13
Row 14
Row 15

ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC
ABC

VS
VS
VS
VS
VS
VS
VS
VS
VS
VS
VS
VS
VS
VS
VS

USUBJID

VSSEQ VSTESTCD

ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001
ABC-001-001

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

SYSBP
SYSBP
SYSBP
DIABP
DIABP
DIABP
PULSE
TEMP
TEMP
WEIGHT
HEIGHT
SYSBP
DIABP
TEMP
WEIGHT

VSTEST

154
152
153
44
48
46
72
34.7
36.2
90.5
157
95
44
36.2

Row 15 (cont)

mmHg
mmHg
mmHg
mmHg
mmHg
mmHg
bpm
C
C
kg
cm
mmHg
mmHg
C

Y
Y
Y
Y
Y
Y

NOT
DONE

Subject
refused

VSLOC

VSORRES VSORRESU VSSTRESC

Systolic Blood Pressure
SITTING LEFT ARM
Systolic Blood Pressure
SITTING LEFT ARM
Systolic Blood Pressure
SITTING LEFT ARM
Diastolic Blood Pressure SITTING LEFT ARM
Diastolic Blood Pressure SITTING LEFT ARM
Diastolic Blood Pressure SITTING LEFT ARM
Pulse
SITTING LEFT ARM
Temperature
MOUTH
Temperature
MOUTH
Weight
STANDING
Height
STANDING
Systolic Blood Pressure
SITTING LEFT ARM
Diastolic Blood Pressure SITTING LEFT ARM
Temperature
MOUTH
Weight

VSSTRESN VSSTRESU VSSTAT VSREASND VSBLFL VSDRVFL
Row 1 (cont)
Row 2 (cont)
Row 3 (cont)
Row 4 (cont)
Row 5 (cont)
Row 6 (cont)
Row 7 (cont)
Row 8 (cont)
Row 9 (cont)
Row 10 (cont)
Row 11 (cont)
Row 12 (cont)
Row 13 (cont)
Row 14 (cont)

VSPOS

Y
Y

154
152

mmHg
mmHg

44
48

mmHg
mmHg

72
34.7
36.2
90.5
157
95
44
97.16

bpm
C
C
kg
cm
mmHg
mmHg
F

VISIT

VISITNUM

VSTPT

BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
BASELINE
VISIT 1
VISIT 1
VISIT 1

1
1
1
1
1
1
1
1
1
1
1
2
2
2

BASELINE 1
BASELINE 2

1
2

BASELINE 1
BASELINE 2

1
2

BASELINE 1
BASELINE 2

1
2

VISIT 1

154
152
153
44
48
46
72
34.7
36.2
90.5
157
95
44
36.2

VSTPTNUM VISITDY
1
1
1
1
1
1
1
1
1
1
1
35
35
35
35

Page 157
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.5

TRIAL DESIGN EXAMPLES

9.5.1

Defining Epochs - a How-to Example Using the Example Crossover Study

This example is based on the crossover study shown in Figure 4 of Section 7.4.2.
Users may find it useful to construct a "study design matrix" like the following.
P-5-10
5-P-10
5-10-P

Trial Screen

1st Treatment

1st Rest

2nd Treatment

2nd Rest

3rd Treatment

Trial Follow-up

Screen
Screen
Screen

Placebo
5 mg
5 mg

Rest
Rest
Rest

5 mg
Placebo
10 mg

Rest
Rest
Rest

10 mg
10 mg
Placebo

Follow-up
Follow-up
Follow-up

This table is not submitted as part of the SDTM. It, like the figure in Section 7, is purely an aid to the user in working out the trial design datasets. Note that the
row labels (in bold type) are the names of the Arms. The column headers (also in bold type) are the names of the trial Epochs. The contents of the cells are
Elements (plain type). In many cases, the user will fill in the column headers first, then place the Elements in the cells of the table. In other cases, the user may
find it easier to work out the Elements in each Arm, then to fill in the names of the Epochs.
The Trial Arms table contains a record for each Element in each Arm (row of the study design matrix). TAETORD gives the order of the Elements within the
Arm. The study design matrix table does not explicitly record the branch – a diagram is better for displaying that feature of the trial design.

Page 158
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Example of a full Trial Arms dataset for a crossover study:
ARM

TAETORD

ELEMENT

TABRANCH

P-5-10
P-5-10
P-5-10
P-5-10
P-5-10
P-5-10
P-5-10
5-P-10
5-P-10
5-P-10
5-P-10
5-P-10
5-P-10
5-P-10
5-10-P
5-10-P
5-10-P
5-10-P
5-10-P
5-10-P
5-10-P

1
2
3
4
5
6
7
1
2
3
4
5
6
7
1
2
3
4
5
6
7

Screen
Placebo
Rest
5 mg
Rest
10 mg
Follow-up
Screen
5 mg
Rest
Placebo
Rest
10 mg
Follow-up
Screen
5 mg
Rest
10 mg
Rest
Placebo
Follow-up

Randomized to Placebo - 5 mg - 10 mg

Randomized to 5 mg/Placebo/10 mg

Randomized to 5 mg/10 mg/Placebo

Page 159
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
The Trial Elements dataset has a record for each unique Element. The properties of the Elements are not recorded in the trial design matrix, but the trial design
matrix can be used to check that all Elements have been included in the Trial Elements dataset. The following information may be helpful in working out the start
and end rules of the Elements:
•

TESTRL answers the question, "What happens that marks the start of the Element?" or, "How do you know the subject has entered this Element?"

•

TEENRL answers the question, "When should the subject leave this Element?" Note that this rule concerns when the subject should leave the Element.
The subject actually leaves the Element when they enter the next Element.

•

TEDUR is used when the element end rule says the subject should leave the Element after a fixed period of time. TEDUR records this fixed period of
time as a duration using ISO 8601 notation. If the element end rule is of some different form, for example if it involves satisfying certain conditions,
then TEDUR is left blank.

Example of the Trial Elements dataset for the same crossover study:
ELEMENT

TESTRL

TEENRL

TEDUR

Screen
Placebo
5 mg
10 mg
Rest
Follow-up

Informed consent
First dose of placebo
First dose of 5 mg drug
First dose of 10 mg drug
48 hrs after last dose drug
48 hrs after last dose drug

2 weeks after start of element
2 weeks after start of element
2 weeks after start of element
2 weeks after start of element
1 week after start of element
3 weeks after start of element

P14D
P14D
P14D
P14D
P7D
P21D

The Trial Elements dataset contains information on timing (the start and end rules), while the Trial Arms dataset contains information on how the Elements are
assembled to make the Arms. Users may find it useful to join the two datasets (merge on Element) to display all this information in one table.
The table below shows such a join of Trial Arms and Trial Elements. A column for EPOCH has been included in this table. Sorting this dataset by TAETORD,
then ARM, makes it easy to check for consistency of the start and end rules of the Elements within an Epoch, across different Arms. Note that in this example,
for each group of records with the same value of TAETORD and EPOCH, the Start Rules are the same or similar. For the Treatment Epochs, the start rules are
"similar" in that they differ only in the specific dose (Placebo, 5 mg or 10 mg) that starts the element. The end rules for the Treatment Epochs are the same. For
all the other Epochs in this trial, all the Elements within the Epoch are identical, so the start and end rules are also identical.
If a group of Elements that have been labeled as belonging to the same Epoch do not have similar start and end rules, then they probably do not really constitute a
valid Epoch.
For a blinded trial, it may be useful to think about a "blinded start rule" or "epoch start rule." While the trial is still blinded, participants will not really know
whether they have entered a particular treatment Element, only that they have entered a particular Epoch. For example, the element start rules for the 1st Trt
Epoch specify receiving a particular dose (placebo, 5 mg or 10 mg), but during the trial, participants will know only that they have received the dose for that
Epoch. Un-blinding the study reveals which treatment the subject received, and therefore which Element they passed through.

Page 160
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Join of Trial Arms and Trial Elements datasets (merged by Element), sorted by TAETORD, then ARM:
ARM

TAETORD

ELEMENT

TASTRL

TAENRL

TADUR

EPOCH

TABRANCH

5-P-10

Screen

Informed consent

2 weeks after start of element

P14D

Trial Screen

Randomized to 5 mg/Placebo/10 mg

P-5-10

Screen

Informed consent

2 weeks after start of element

P14D

Trial Screen

Randomized to Placebo/5 mg/10 mg

5-10-P

Screen

Informed consent

2 weeks after start of element

P14D

Trial Screen

Randomized to 5 mg/10 mg/Placebo

5-P-10

5 mg

First dose of 5 mg drug

2 weeks after start of element

P14D

1st Trt

P-5-10

Placebo

First dose of placebo

2 weeks after start of element

P14D

1st Trt

5-10-P

5 mg

First dose of 5 mg drug

2 weeks after start of element

P14D

1st Trt

5-P-10

Rest

48 hrs after last dose drug

1 week after start of element

P7D

1st Rest

P-5-10

Rest

48 hrs after last dose drug

1 week after start of element

P7D

1st Rest

5-10-P

Rest

48 hrs after last dose drug

1 week after start of element

P7D

1st Rest

5-P-10

Placebo

First dose of placebo

2 weeks after start of element

P14D

2nd Trt

P-5-10

5 mg

First dose of 5 mg drug

2 weeks after start of element

P14D

2nd Trt

5-10-P

10 mg

First dose of 10 mg drug

2 weeks after start of element

P14D

2nd Trt

5-P-10

Rest

48 hrs after last dose drug

1 week after start of element

P7D

2nd Rest

P-5-10

Rest

48 hrs after last dose drug

1 week after start of element

P7D

2nd Rest

5-10-P

Rest

48 hrs after last dose drug

1 week after start of element

P7D

2nd Rest

5-P-10

10 mg

First dose of 10 mg drug

2 weeks after start of element

P14D

3rd Trt

P-5-10

10 mg

First dose of 10 mg drug

2 weeks after start of element

P14D

3rd Trt

5-10-P

Placebo

First dose of placebo

2 weeks after start of element

P14D

3rd Trt

5-P-10

Follow-up

48 hrs after last dose drug

3 weeks after start of element

P21D

Trial FU

P-5-10

Follow-up

48 hrs after last dose drug

3 weeks after start of element

P21D

Trial FU

5-10-P

Follow-up

48 hrs after last dose drug

3 weeks after start of element

P21D

Trial FU

Page 161
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

9.5.2

Trial Summary Example

Trial Summary Example1:
Rows 1 and 2: This trial is of two different types so there are 2 records for the type of trial
Rows 1,2,5,6,7 and 12 use controlled terminology for TSVAL
STUDYID

DOMAIN

TSSEQ

TSPARMCD

TSPARM

TSVAL

Row 1

XYZ

TYPE

Type Of Trial

EFFICACY

Row 2

XYZ

TYPE

Type Of Trial

SAFETY

Row 3

XYZ

TITLE

Trial Title

A 24 Week Study of Daily Oral Investigational
Drug vs. Placebo in Subjects with Asthma

Row 4

XYZ

OBJPRIM

Primary Objective Of Trial

Reduce the incidence of exacerbations of asthma

Row 5

XYZ

RANDOM

Trial Is Randomized

Row 6

XYZ

MASK

Trial Blinding Schema

DOUBLE BLIND

Row 7

XYZ

DESIGN

Description of Trial Design

PARALLEL

Row 8

XYZ

TRT

Reported Name Of Test Product

Investigational New Drug

Row 9

XYZ

INDIC

Trial Indications

Asthma

Row 10

XYZ

AGEMIN

Planned Minimum Age Of Subjects

Row 11

XYZ

AGEMAX

Planned Maximum Age Of Subjects

Row 12

XYZ

SEX

Sex Of Participants

BOTH

Row 13

XYZ

COMPTRT

Comparative Treatment Name

Placebo

Page 162
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

10 Appendices
10.1

CDISC SDS TEAM
Role

Name

Company

Team Lead

Wayne Kubick

Lincoln Technologies, CDISC

Team Co-Leads

Fred Wood

Procter and Gamble

Mary Lenzen

Pfizer

Tom Guinter

Octagon Research

Technical Manager

Julie Evans

CDISC

Sub-team Leads

Randall Austin

GlaxoSmithKline

Chris Tolk

Bayer Healthcare

Madhavi Vemuri

Johnson and Johnson PRD

Diane Wold

GlaxoSmithKline

Karen Alexander

Boehringer-Ingelheim

Gayle Amato

Bayer Healthcare

Jane Boone

Webclin

Gary Cunningham

AstraZeneca

Kathleen Giordano

Merck

Dan Godoy

AstraZeneca

Andreas Gromen

Schering AG

Joyce Hernandez

IBM

Sandy Lei

Johnson and Johnson PRD

Musa Nsereko

Cephalon

Bill Qubeck

Pfizer

Robert Sarate

Merck

Sarah Shiue

Merck

Gail Stoner

Centocor

Mike Walega

Covance

Gary Walker

Quintiles

Yuguang Zhao

Sanofi-Aventis

Randy Levin

FDA

Norman Stockbridge

FDA

Steve Wilson

FDA

Team Participants

FDA Participants

CDISC SDTM Implementation Guide (Version 3.1.1)

10.2

GLOSSARY OF TERMS

The following abbreviations and terms are used in this document. Additional definitions can be found in the CDISC
Glossary available at http://www.cdisc.org/glossary/index.html.
CDISC

Clinical Data Interchange Standards Consortium

CRT

Case Report Tabulation

Dataset

A collection of structured data in a single file

Domain

A collection of observations with a topic-specific commonality about a subject

FDA

Food and Drug Administration

HL7

Health Level 7

SDS

Submission Data Standards (Team)

SDTMIG

"Study Data Tabulation Model Implementation Guide for Human Clinical Trials
(this document)

SEND

Standard for Exchange of Non-clinical Data

SDSIG

SDS Implementation Guide V. 3.1, now referred to as SDTMIG.

SDTM

Study Data Tabulation Model

V3.x

Refers to Version 3.1 of the SDSIG and all subsequent versions of the SDTMIG

Page 164
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

10.3

STANDARDIZED AND RESERVED CODES

This appendix includes a preliminary list of standard codes that have been defined by the CDISC SDS Team for use
with the SDTM. It includes a set of reserved domain codes, test codes for two findings domains, and an initial set of
name codes for use in the Supplemental Qualifiers (SUPPQUAL) special-purpose dataset.
Since a robust set of controlled terminology is so essential for effective use of the SDTM and other CDISC models,
CDISC has assigned a new "Controlled Terminology" team. Beginning in March 2005, CDISC will be publishing
sets of proposals for controlled terminology in separate documentation packages that will be available through the
CDISC website for review and comment. The set of controlled terminology will be expanded over time and will
eventually be available through online search tools provided by the National Cancer Institute of the United States
National Institutes of Health.

10.3.1

Reserved Domain Codes

The following domain codes have been reserved for use with the domain topicalities listed. CDISC will be
preparing additional domain models to describe many of these over time.
Code

Domain

Class

AE
AU

Adverse Events
Autopsy

Events
Findings

Findings

BR
CM
CO
DA

Bone Mineral Density
(BMD) Data
Biopsy
Concomitant Meds
Comments
Drug Accountability

Findings
Interventions
Special Purpose
Findings

Disease Characteristics

Findings

Demographics

Special Purpose

DS
DV
EE

Disposition
Protocol Deviations
EEG

Events
Events
Findings

ECG

Findings

EX
HU

Exposure
Healthcare Resource
Utilization

Interventions
Findings

Inclusion / Exclusion

Findings

Description
See 6.2.1.1, assumption 1.
Additional data about deaths, specific to findings
from autopsies.
Findings resulting from evaluations of bone mineral
density.
Findings resulting from biopsies.
See 6.1.1.1, assumption 1.
See 5.1.2.
Data regarding the accountability of study drug,
such as information on the receipt, dispensing,
return, and packaging.
Data related to the characteristics of a specific
disease state under study for a subject.
Demographics includes a set of essential standard
variables that describe each subject in a clinical
study. It is the parent domain for all other
observations for human clinical subjects. See
SDTM 2.2.6.
See 6.2.2.1, assumption 1.
See separate DV domain model, assumption 1.
Findings resulting from electroencephalogram
(EEG) tests.
Findings related to the collection of ECG data,
including position of the subject, method of
evaluation, all cycle measurements and all findings
from the ECG including an overall interpretation if
collected or derived.
See 6.1.2.1, assumption 1.
Healthcare resource utilization data such as subject
visits to physicians, hospitalizations, and nursing
home stays.
See 6.3.2.1, assumption 1.
Page 165
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
Code

Domain

Class

Imaging

Findings

Laboratory Data

Findings

Microbiology Specimens

Findings

MH
ML

Medical History
Meal Data

Events
Interventions

Microbiology Susceptibility

Findings

OM
PC

Organ Measurements
PK Concentration

Physical Exam

PK Parameters

Pharmacogenomics

QS
SC
SE
SG
SK
SL

Questionnaires
Subject Characteristics
Subject Elements
Surgery
Skin Test
Sleep (Polysomnography)
Data
Signs and Symptoms

ST
SU
SV
TA
TE
TI

Stress (Exercise) Test Data
Substance Use
Subject Visits
Trial Arms
Trial Elements
Trial Inclusion/Exclusion
Criteria
Trial Summary
Trial Visits
Vital Signs

TS
TV
VS

Page 166
August 26, 2005

Description
Findings resulting from diagnostic medical imaging
tests such as X-ray or MRI.
Laboratory test findings including, but is not
limited to hematology, clinical chemistry and
urinalysis data. Does not include microbiology or
PK data, which are stored in separate domains.
Microbiology Specimen findings, including gram
stain results, and organisms found.
See 6.2.3.1, assumption 1
Information regarding the subject's meal
consumption, such as fluid intake, amounts, form
(solid or liquid state), frequency, etc., typically used
for PK analysis.

Microbiology Susceptibility Test results, plus
results of any other organism-related tests.
Findings
Findings from organ measurement evaluations.
Findings
Concentrations of drugs/metabolites in fluids or
tissues as a function of time.
Findings
Findings collected during a physical examination of
the subject. It has findings that are discovered that
are related to body systems. Does not include vital
signs measurements, which are stored in the VS
domain.
Findings
Pharmacokinetic parameters derived from
pharmacokinetic concentration-time (PC) data.
Findings
Pharmacogenomics findings initially focusing on
Genotype and Gene Expression data.
Findings
See 6.3.5.1, assumption 1
Findings
See 6.3.6.1, assumption 1
Study Design
See SDTM 3.3.
Interventions
Surgical information.
Findings
Findings from diagnostic skin tests.
Findings
Findings from diagnostic sleep tests
(polysomnography).
Findings/Events Evidence of disease or condition, including
objective signs and subjective symptoms that are
typically observed by a physician or described to
the investigator by the subject.
Findings
Interventions
Trial Design
Trial Design
Trial Design
Trial Design

Findings from exercise stress tests.
See 6.1.3.1, assumption 1
See SDTM 3.3.
See SDTM 3.2.
See SDTM 3.2.
See SDTM 3.4.

Trial Design
Trial Design
Findings

See SDTM 3.5.
See SDTM 3.2.
Measurements including but not limited to blood
pressure, temperature, respiration, body surface
area, BMI, height and weight.

CDISC SDTM Implementation Guide (Version 3.1.1)

10.3.2

Electrocardiogram Test Codes (for measured or calculated parameters)

The following table contains the test codes suggested by CDISC for use in Electrocardiogram data domains.
EGTESTCD
HR
INTP
PR
QRS
QT
QTCB
QTCF
RR
VRATE

10.3.3

EGTEST
Heart Rate
ECG Interpretation
PR Interval
QRS Interval
QT Interval
QTc Interval Bazett
QTc Interval Fridericia
RR Interval
Ventricular Rate

Vital Signs Test Codes

The following table contains the test codes suggested by CDISC for use in Vital Signs domains.

VSTESTCD
BMI
BODYFAT
BSA
DIABP
FRMSIZE
HEIGHT
HR
MAP
PULSE
RESP
SYSBP
TEMP
WEIGHT

VSTEST
Body Mass Index
Body Fat
Body Surface Area
Diastolic Blood Pressure
Frame Size
Height
Heart Rate
Mean Arterial Pressure
Pulse Rate
Respiratory Rate
Systolic Blood Pressure
Temperature
Weight

Page 167
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)

10.3.4

Supplemental Qualifiers Name Codes

The following table contains an initial set of standard name codes suggested by CDISC for use in the Supplemental
Qualifiers (SUPPQUAL) special-purpose dataset.

QNAM
AESOSP
AETRTEM
COMPLT
FULLSET
ITT
PPROT
SAFETY

Page 168
August 26, 2005

QLABEL
Other Medically Important SAE (includes
the descriptive text, not a flag)
Treatment Emergent Flag
Completers Population Flag
Full Analysis Set Flag
Intent to Treat Population Flag
Per Protocol Set Flag
Safety Population Flag

CDISC SDTM Implementation Guide (Version 3.1.1)

10.3.5

Trial Summary Codes

The following table contains proposed controlled terminology for use in the Trial Summary domain. Although this
is the most current set of terminology available as of this writing, it is likely to grow or change as it undergoes
further review by the CDISC Controlled Terminology team.
TSPARMCD

TSPARM

TSVAL

ADDON

TEST PRODUCT IS ADDED ON TO
EXISTING TREATMENT

AEDICT

ADVERSE EVENT DICTIONARY

AGESPAN

AGE SPAN

AGEMAX

PLANNED MAXIMUM AGE OF
SUBJECTS
PLANNED MINIMUM AGE OF
SUBJECTS
TRIAL BLINDING SCHEMA

Y
N
MedDRA
WHOART
SPONSOR DEFINED
IN UTERO
PRETERM NEWBORN INFANTS
NEWBORN (0-27 DAYS)
INFANT AND TODDLER (28 DAYS - 23 MONTHS)
CHILDREN (2-11 YEARS)
ADOLESCENT (12-17 YEARS)
ADULT (18-65)
ELDERLY (> 65)
No controlled terminology.

AGEMIN
BLIND

COMPTRT
CONTROL

DIAGGRP
DOSE
DOSFRQ
DOSU
DRUGDICT
INDIC
INDICTYP

COMPARATIVE TREATMENT
NAME
TYPE OF CONTROL

DIAGNOSIS GROUP
TEST PRODUCT DOSE PER
ADMINISTRATION
TEST PRODUCT DOSING
FREQUENCY
TEST PRODUCT DOSE UNITS
DRUG DICTIONARY
TRIAL INDICATIONS
TRIAL INDICATION TYPE

No controlled terminology.
OPEN LABEL
SINGLE BLIND
DOUBLE BLIND
No controlled terminology.
PLACEBO
ACTIVE
NONE
HEALTHY SUBJECTS
Use controlled terminology for interventions (DOSE).
Use controlled terminology for interventions (DOSFRQ).
Use controlled terminology for interventions (DOSU).
WHODRUG
No controlled terminology.
DIAGNOSIS
CURE
MITIGATION [Note: used narrowly to mean mitigate
adverse effect of another treatment]
TREATMENT
PREVENTION
Page 169
August 26, 2005

CDISC SDTM Implementation Guide (Version 3.1.1)
TSPARMCD

TSPARM

TSVAL

LENGTH
MHDICT

LENGTH OF TRIAL
MEDICAL HISTORY DICTIONARY

OBJPRIM

TRIAL PRIMARY OBJECTIVE

OBJSEC

TRIAL SECONDARY OBJECTIVE

PHASE

TRIAL PHASE

PLANSUB

PLANNED NUMBER OF
SUBJECTS
TRIAL IS RANDOMIZED

No controlled terminology.
MedDRA
SPONSOR DEFINED
No controlled terminology however, the objective should
be described in terms of the desired statement in labeling.
No controlled terminology however the objective should
be described in terms of the desired statement in labeling.
1
1-2
2
2A
2B
2-3
3
3A
3B
3-4
4
5
NA
No controlled terminology.

RANDOM

ROUTE
SEXPOP

SPONSOR
TITLE
TRT
TYPE

Page 170
August 26, 2005

TEST PRODUCT ROUTE OF
ADMINISTRATION
SEX OF PARTICIPANTS

SPONSORING ORGANIZATION
TRIAL TITLE
REPORTED NAME OF TEST
PRODUCT
TYPE OF TRIAL

Y
N
Use controlled terminology for interventions (ROUTE).
M
F
BOTH
No controlled terminology.
No controlled terminology.
No controlled terminology.
SAFETY
EFFICACY
BIO-EQUIVALENCE
BIO-AVAILABILITY
CONFIRMATORY
EXPLORATORY
PHARMACOECONOMIC
PHARMACOGENOMICS
PHARMACOKINETICS
PHARMACODYNAMICS

CDISC SDTM Implementation Guide (Version 3.1.1)

10.4

CDISC VARIABLE-NAMING FRAGMENTS

The CDISC SDS group has defined a standard list of fragments to use as a guide when naming variables in
SUPPQUAL (QNAM) or assigning TESTCD values that could conceivably be treated as variables in a horizontal
listing derived from a V3.x dataset. In some cases, more than one fragment is used for a given keyword. This is
necessary when a shorter fragment must be used for a TESTCD or QNAM that incorporates several keywords that
must be combined while still meeting the 8-character variable naming limit of SAS transport files. When using
fragments, the general rule is to use the fragment(s) that best conveys the meaning of the variable within the 8character limit; thus, the longer fragment should be used when space allows. If the combination of fragments still
exceeds 8 characters, a character should be dropped where most appropriate (while avoiding naming conflicts if
possible) to fit within the 8-character limit.
In other cases the same fragment may be used for more than one meaning, but these would not normally overlap for
the same variable.
Keyword(s)

Fragment

Keyword(s)

Fragment

ACTION

ACN

ETHNICITY

ETHNIC

ADJUSTMENT

ADJ

EXTERNAL

ANALYSIS DATASET

EVALUATOR

EVAL

BASELINE

EVALUATION

EVL

BIRTH

BRTH

FASTING

FAST

BODY

BOD

FILENAME

CANCER

CAN

FLAG

SDTM 3.1.1 Implementation Guide

Navigation menu

Versions of this User Manual:

Views

Navigation