Cdash Draft Post Version

CDISC CDASH (Draft Version 1.
0)
Clinical Data Acquisition

Standards Harmonization: Basic Data Collection Fields for
Case Report Forms
Prepared by the CDISC CDASH Team
Notice to Reviewers
• This is the CDASH draft posted for public comment.
Revision History
Date Version Summary of Changes
2008-04-03 Draft 1.0
CDISC © 2008. All rights reserved Page 1

DRAFT 2008-04-03
CDISC CDASH (Draft Version 1.0)
Table of Contents
Section Page
1. Orientation .................................................................................................................... 5
2. Introduction .................................................................................................................. 6
2.1. Terminology ............................................................................................................................................7
3. Best Practice (General Recommendations and Observations Applicable to all

Domains)....................................................................................................................... 8
3.1. Implementation of CDASH Recommendations........................................................................................8
3.2. Core Designations for Basic Data Collection Variables ...........................................................................8
3.3. Introduction to Best Practices..................................................................................................................8
3.4. Recommended Methodologies for Creating Data Collection Instruments................................................9
3.5. FAQs on Best Practices for Creating CRF Content and Structure.........................................................12
3.6. Common Identifier Variables .................................................................................................................15
4. CDASH Domain Tables.............................................................................................. 17

4.1. Introduction ...........................................................................................................................................17
4.2. Explanation of Table Headers ...............................................................................................................17
4.3. Adverse Event – AE (Events) ................................................................................................................18
4.4. Comments – CO (Special Purpose) ......................................................................................................24
4.4.1. Solicited Comments..................................................................................................................24
4.4.2. Unsolicited Comments..............................................................................................................24
4.4.3. Considerations Regarding Usage of a General Comments CRF ..............................................24
4.4.4. Rationale ..................................................................................................................................24
4.4.5. Conclusion................................................................................................................................25
4.5. Concomitant Medications – CM (Interventions) .....................................................................................26
4.5.1. General Medications.................................................................................................................26
4.5.2. Medications of Interest .............................................................................................................26
4.6. Demography – DM (Special Purpose) ...................................................................................................34
4.6.1. Collection of Age vs. Birth Date ................................................................................................34
4.7. Disposition – DS (Events) .....................................................................................................................39
4.8. Drug Accountability – DA (Findings)......................................................................................................43
4.9. ECG Test Results – EG (Findings)........................................................................................................47
4.9.1. Scenario 1: Central Reading.....................................................................................................47
4.9.2. Scenario 2: Local Reading........................................................................................................49
4.9.3. Scenario 3: Central Reading (includes site assessment of clinical significance).......................52
4.10. Exposure – EX (Interventions)...............................................................................................................55
4.11. Inclusion / Exclusion – IE (Findings)......................................................................................................60
4.11.1. Adaptive Trial Design ...............................................................................................................60
4.11.2. Collecting IE Data and Mapping to the SDTM ..........................................................................60
4.12. Laboratory Test Results – LB (Findings) ...............................................................................................63
4.12.1. Scenario 1: Central Processing ................................................................................................63
4.12.2. Scenario 2: Local Processing ...................................................................................................65

DRAFT 2008-04-03
Table of Contents
Section Page
4.12.3. Scenario 3: Central Processing (includes site assessment of clinical significance) ..................68
4.13. Medical History – MH (Events) ..............................................................................................................70
4.14. Physical Examination – PE (Findings)...................................................................................................74
4.14.1. Best Practice Approach ............................................................................................................75
4.14.2. Traditional Approach ................................................................................................................76
4.15. Protocol Deviations – DV (Findings)......................................................................................................78
4.15.1. Considerations Regarding Usage of a Protocol Deviations CRF ..............................................78
4.15.2. Rationale ..................................................................................................................................78
4.16. Subject Characteristics – SC (Findings) ................................................................................................81
4.17. Substance Use – SU (Interventions) .....................................................................................................83
4.18. Vital Signs – VS (Findings)....................................................................................................................87
Appendices............................................................................................................................ 90
APPENDIX A: Process.......................................................................................................... 90
APPENDIX A1: Process and Deliverables .........................................................................................................90
APPENDIX A2: Volunteers ................................................................................................................................92
APPENDIX B: Data Collection Variables Generally Considered Not Necessary

to Collect on the CRF................................................................................... 93
APPENDIX B1: Identifier & Timing Variables .....................................................................................................94
APPENDIX B2: Adverse Events.........................................................................................................................95
APPENDIX B3: Concomitant Medications..........................................................................................................96
APPENDIX B4: Demography .............................................................................................................................98
APPENDIX B5: Disposition ................................................................................................................................99
APPENDIX B6: Drug Accountability .................................................................................................................100
APPENDIX B7a: ECG Test Results, Scenario 1 ..............................................................................................101
APPENDIX B7b: ECG Test Results, Scenario 2 ..............................................................................................102
APPENDIX B7c: ECG Test Results, Scenario 3 ..............................................................................................103
APPENDIX B8: Exposure ................................................................................................................................104
APPENDIX B9: Inclusion / Exclusion ...............................................................................................................106
APPENDIX B10a: Laboratory Test Results, Scenario 1 ...................................................................................107
APPENDIX B10b: Laboratory Test Results, Scenario 2 ...................................................................................108
APPENDIX B10c: Laboratory Test Results, Scenario 3 ...................................................................................109
APPENDIX B11: Medical History .....................................................................................................................110
APPENDIX B12: Protocol Deviations ...............................................................................................................111
APPENDIX B13: Substance Use .....................................................................................................................112
APPENDIX C: Regulatory References .............................................................................. 113

APPENDIX C1: Adverse Events (AE) ..............................................................................................................114

DRAFT 2008-04-03
Table of Contents
Section Page
APPENDIX C2: Concomitant Medications (CM)...............................................................................................118
APPENDIX C3: Demography (DM) ..................................................................................................................119
APPENDIX C4: Disposition (DS)......................................................................................................................120
APPENDIX C5: Drug Accountability (DA) ........................................................................................................121
APPENDIX C6: ECG Test Results (EG) ..........................................................................................................122
APPENDIX C7: Exposure (EX) ........................................................................................................................123
APPENDIX C8: Inclusion / Exclusion (IE) ........................................................................................................124
APPENDIX C9: Laboratory Test Results (LB) ..................................................................................................125
APPENDIX C10: Medical History (MH) ............................................................................................................126
APPENDIX C11: Physical Examination (PE) ...................................................................................................127
APPENDIX C12: Protocol Deviations (DV) ......................................................................................................128
APPENDIX C13: Substance Use (SU) .............................................................................................................129
APPENDIX C14: Vital Signs (VS) ....................................................................................................................130
APPENDIX D: CDASH Project Team ................................................................................. 131

APPENDIX D1: CDASH Core Team ................................................................................................................131
APPENDIX D2: Participating Companies.........................................................................................................132
APPENDIX E: List of Abbreviations.................................................................................. 134
APPENDIX F : Acknowledgements ................................................................................... 135
APPENDIX G: Revision History......................................................................................... 136
APPENDIX H: Representation and Warranties; Limitations of Liability,

and Disclaimers.......................................................................................... 137

DRAFT 2008-04-03
1. Orientation
The aim of this document is to describe recommended basic standards for the collection of clinical trial data.
This document is intended to be used by those functions involved in the planning, collection, management and
analysis of clinical trials and clinical data, for example, Clinical Investigators, Medical Monitors, Clinical
Research Associates (Monitors), Clinical Research Study Coordinators, Clinical Data Managers, Clinical Data
and Statistical Programmers, Biostatisticians, Drug Safety, Case Report Form designers and other functions
tasked with the responsibility to collect, clean and ensure the integrity of clinical trial data.
The CDASH standards are one part of a comprehensive package of CDISC standards that seeks to provide an
end-to-end solution for the management of clinical data from capture to submission.

DRAFT 2008-04-03
2. Introduction
The Clinical Data Acquisition Standards Harmonization (CDASH) project seeks to address FDA’s Critical Path
Opportunity (#45) whose purpose is to facilitate standardized collection of clinical research data at investigative
sites.
#45 Consensus on Standards for Case Report Forms. Clinical trial data collection, analysis, and submission can
be inefficient and unnecessarily expensive. A wide array of different forms and formats are used to collect clinical
trial information, and most data are submitted to the FDA on paper. Differences in case report forms
across sponsors and trials creates opportunities for confusion and error. Standardization of the look and feel of
case report forms could reduce these inefficiencies and also help accelerate progress toward electronic data
capture and submission.1
Standards can substantially reduce time and resource needs for clinical research studies, particularly when they are
implemented in the start-up stage.2 In addition, they have been reported to improve project team
communication and resulting data quality.
Although the CDASH project does not address “look and feel” (referenced above in C-Path opportunity #45),
through standardization of basic data collection variables, efficiencies can be achieved that will result in less
confusion across sponsors, investigators and research sites and will require less data cleaning and facilitate more
efficient monitoring, audit, submission and review procedures.
The CDASH project continues the CRF standardization work initiated by the Association of Clinical Research
Organizations (ACRO). It was recommended that CDISC take the leadership role during the January 2006 -
DIA Open Forum “Creating Clinical Trial Efficiencies through Standard Data Collection” organized by CDISC,
FDA and ACRO. CDISC has expertise in standards development demonstrated by former CDISC work, such as in
the development of the Study Data Tabulation Model (SDTM) for reporting results in regulatory submissions to
FDA that can be leveraged in the CDASH project.
In June 2006 the initial Collaborative Group was announced by Dr. Woodcock at the Annual DIA Meeting in
Philadelphia “Human Subject Protection/Bioresearch Monitoring Initiative and Critical Path Update”.
Developing the CDASH project strategy and providing volunteer resources are the responsibilities of the
Collaborative Group, which is comprised of the following organizations:
• American Medical Informatics Association (AMIA)
• Association of Clinical Research Organizations (ACRO)
• Association of Clinical Research Professionals (ACRP)
• Baylor College of Medicine
• Biotechnology Industry Organization (BIO)
• Clinical Data Interchange Standards Consortium (CDISC)
• Clinical Research Forum
• Critical Path Institute
• Duke Clinical Research Institute (DCRI)
• Food and Drug Administration (FDA)
1
Critical Path Opportunities List (Innovation/Stagnation) link:
http://www.fda.gov/oc/initiatives/criticalpath/opportunities06.html
2
Applied Clinical Trials, June 2007
DRAFT 2008-04-03
• National Institutes of Health (NIH)

Clinical Research Policy Analysis and Coordination Program
National Center for Research Resources (NCRR)
National Cancer Institute (NCI); caBIG
National Institute of Child Health and Human Development (NICHD)
National Library of Medicine (NLM)
• Pharmaceutical Research and Manufacturers Association (PhRMA)
• Society for Clinical Data Management (SCDM)
A CDISC Project Kick-off meeting was held in October 2006 during which 3 teams were formed and work was
commenced on CDASH Package-3 (Adverse Events, Concomitant Medication, Demographics and Subject
Characteristics.
The primary goal of the CDASH project is the development of ‘content standards’ for a basic set of
global data collection variables that will support clinical research studies. These “content standards”
consist of data collection variables, definitions, completion instructions for the clinical site, and implementation
instructions and rationale for sponsors.
Basic data collection variables identified by CDASH project teams are mapped into the Study Data Tabulated
Model (SDTM) and are compliant with the SDTM Implementation Guide (SDTM IG). SDTM “required” data
collection variables have been addressed in the CDASH recommendations.
The initial scope of the project is the development of 16 CRF content safety data domains. These safety
domains are common to all therapeutic areas. As mentioned above, the initial scope is limited to CRF content, not
the physical layout of CRFs.
Domains
Adverse Events (AE) Inclusion and Exclusion Criteria (IE)
Comments (CO) Lab (LB)
Concomitant Medications (CM) Medical History (MH)
Demographics (DM) Physical Examination (PE)
Disposition (DS) Protocol Deviations (DV)
Drug Accountability (DA) Subject Characteristics (SC)
ECG (EG) Substance Use (SU)
Exposure (EX) Vital Signs (VS)
2.1. Terminology
Terminology applicable to CDASH data collection variables is either in production or being developed by the
CDISC Terminology Team. Production terminology is published by the National Cancer Institute’s Enterprise
Vocabulary Services (NCI EVS) and can be assessed via the following link:
http://www.cancer.gov/cancertopics/terminologyresources/page6. For coded variables, the CDASH final
document will only list the name of the code list stored in NCI’s EVS. Terminology proposed by CDASH
teams has been forward to the CDISC terminology team to be vetted via the CDISC consensus process.

DRAFT 2008-04-03
3. Best Practice (General Recommendations and Observations

Applicable to all Domains)
3.1. Implementation of CDASH Recommendations
The CDASH project seeks to identify the basic data collection fields needed from a clinical, scientific and
regulatory data collection perspective to enable efficient data collection at the investigative sites. Clearly, the
more data fields that are collected, the greater the chances of introducing and/or not identifying errors and the
greater the resources needed for monitoring, auditing, conducting and managing the project. While the Study
Data Tabulated Model (SDTM) provides a standard for a ‘superset’ of data that could potentially be collected or
derived, CDASH goes a step further and intentionally identifies from this ‘superset’ a basic set of highly
recommended and recommended variables or data collection fields that are expected to be present on the
majority of case report forms (CRFs). Although it is assumed that additional data fields will be needed to
address study-specific requirements, this approach forces a thought process among sponsors to determine
specifically which fields, if any, should be added to these CDASH recommendations based upon the protocol
and the business practices of the sponsor. Specifically, until therapeutic area (TA) specific data fields have
been standardized, these fields will need to be added to the CDASH recommendations to fulfill the protocol-
specific requirements.
While SDTM and CDASH are clearly related, there are instances where they do not exactly match due to their
differing purposes, i.e., submission vs. data collection. For example, the SDTM standard may contain derived
data while CDASH variables should not be derived at the data acquisition stage. Basic data collection fields
identified by CDASH project teams are mapped into the SDTM and are compliant with the SDTM IG. As part
of this mapping to the SDTM, SDTM variable names have been provided where applicable as an aide to
reviewers. All SDTM “required” variables have been addressed in the CDASH recommendations. The CDASH
teams have intentionally not reproduced other sections of the SDTM standard, and reviewers are asked to refer
to the CDISC SDTM Implementation Guide.
3.2. Core Designations for Basic Data Collection Variables
In order to facilitate classification of the different types of data collection variables, the following categories
were used:
Highly Recommended = A data collection field that should be on the CRF (e.g., a regulatory requirement).
Recommended/Conditional = A data collection field that should be collected on the CRF for specific cases or
to address TA requirements (may be recorded elsewhere in the CRF or from
other data collection sources).
Optional = A data collection variable that is available for use if needed (may be recorded elsewhere in the CRF
or from other data collection sources).
Highly recommended and recommended/conditional data collection variables are expected to be present on the
majority of CRF. It is assumed that sponsors will determine what other data collection variables will be
collected based on TA-specific data requirements, protocol and other considerations.
It is strongly recommended that standards are defined at the sponsor level, taking into consideration the
requirements of the stage of clinical development and the individual therapeutic area requirements,
and NOT on a trial-by-trial basis within the sponsor organization.
3.3. Introduction to Best Practices
“There is arguably no more important document than the instrument that is used to acquire the data from the
clinical trial, with the exception of the protocol, which specifies the conduct of that trial. The quality of the data
collected relies first and foremost on the quality of that instrument. No matter how much time and effort go into

DRAFT 2008-04-03
conducting the trial, if the correct data points were not collected, a meaningful analysis may not be possible. It
follows, therefore, that the design, development and quality assurance of such an instrument must be given the
utmost attention.” 3
3.4. Recommended Methodologies for Creating Data Collection Instruments
Ref Methodology Rationale
1 NECESSARY DATA ONLY: CRFs should avoid • It is very costly and time-consuming to collect data that are not
collecting redundant data and focus on collecting addressing a specific protocol requirement or used in the product
only the data needed to answer the protocol submission. Usually, only data that will be used for analysis should
questions and to provide adequate safety data. be collected on the CRF. Data that is collected should generally be
reviewed and cleaned.
• When available, the Statistical Analysis Plan needs to be reviewed
to ensure that the parameters needed for analysis are collected and
can be easily analyzed.
2 CONTROL: Control the process of designing, • The CRF development lifecycle should be a controlled process,
printing, distributing CRFs, and accounting for using a formalized, documented process that incorporates design,
unused CRFs. review, approval and versioning steps.
• The CRF development process should be controlled by SOPs
covering, at a minimum, design, development, QA, approvals,
version control and site training.
3 ADEQUATE REVIEW: The team that designs the • Staff involved in CRF design should review the protocol to ensure
data collection instruments for a study needs to be that it is possible to collect the proposed data.
involved in the development of the protocol, and
have appropriate expertise represented on the CRF • Statisticians should review the CRF against their planned analyses
design team (e.g., statistics, programming, data to make sure all required data will be collected in an appropriate
management, clinical operations, science, form for those analyses.
regulatory, pharmacovigilance). • Clinical Operations staff should review the CRF to make sure the
Ideally, the CRF should be developed in questions are unambiguous and that it is possible to collect the data
conjunction with the Protocol and SAP. being requested.
All research-related data on the CRF should be • Scientific experts should provide input on the efficacy and/or safety
addressed in the protocol to specify how and when data collection fields, and educate the CDM staff on the type and
it will be collected. methods of collecting those data.
• Regulatory experts should review the CRF for compliance with all
applicable regulations.
• Data Entry is an important “user” of the CRF and their perspective
should be included in the review.
4 SITE WORKFLOW: The team developing the data • The CRF needs to be quick and easy for site personnel to complete.
collection instruments needs to consider the
workflow at the site and the standard of care. • The CRF should be designed so that it mirrors the order of
assessments performed by the site personnel. Clinical Operations
staff should review the CRF for compatibility with site workflow.
• Although Clinical Data Management should make the final
decisions about CRF design, those decisions should be informed by
study and user requirements.
3
Good Clinical Data Management Practices, Version 4, October 2005, Society for Clinical Data Management
DRAFT 2008-04-03
Ref Methodology Rationale
5 STANDARDS: Within the data collection • Using data collection standards across compounds and therapeutic
environment, standards should be employed to areas saves time and money at every step of drug development.
collect consistent data across compounds and
therapeutic areas. Industry standards should be • Using standards:
used wherever possible, and in-house standards • reduces production time for CRF design, and reduces review and
developed as needed. approval time.
• reduces site re-training and queries, and improves compliance and
data quality at first collection.
• facilitates efficient monitoring, reducing queries.
• improves the speed and quality of data entry, and reduces the
training burden in-house.
• enables easy reuse and integration of data across studies, and
facilitates ‘data mining’ and the production of integrated
summaries.
• reduces the need for new clinical and statistical programming
with each new study.
• reduces global library maintenance in the database.
• addresses FDA Critical Path Opportunities (#44 and 45).
6 CLARITY: CRF Questions and completion Questions should be clear and unambiguous. This includes making sure
instructions should not “lead” the site. that the options for answering the question are complete (e.g., “Other”,
“None”). Data needs to be collected in a way that does not introduce
bias or errors into the study data.
7 TRANSLATIONS: Translations of CRFs into other Cultural and language issues should be addressed appropriately during
languages should be a parallel process following the process of translating CRFs to ensure the CRF questions have
the same set of steps with separate reviews and consistent meaning in all language versions.
approvals by the appropriate experts.
8 CRF COMPLETION GUIDELINES: Putting short instructions and prompts on the CRF increases the
probability that they will be read and followed, and can reduce the
CRF questions should be as self-explanatory as number of queries and the overall data cleaning costs.
possible, thereby reducing the need for instructions.
Well designed Completion Guidelines will also enhance the flow of the
Prompts and short instructions may be placed on CRF. Providing short instructions and prompts on the CRF, and
the CRF page. More detailed instructions may be moving long instructions to a separate instruction booklet, facing page
presented in a CRF Completion Guideline for paper or checklist will decrease the number of pages in the CRF, with the
CRFs, or in a context-sensitive help file for eCRFs. following benefits:
All instructions should be concise. For studies
which require extensive, detailed instructions • Decreased Data Management costs (e.g., decreased Data Entry
explaining conditional actions, use a brief prompt costs)
on the CRF page to reference the appropriate
location for the detailed instructions. • Allows CRF to be formatted so that the reader can easily identify the
fields to be completed.
Instructions should be standardized along with the
CRF as much as possible. • The format of the page is less cluttered which makes it easier for site
personnel and monitors to identify fields with missing responses.
These also promote standardization, in that all sites
will use the same conventions for completing the
fields.

DRAFT 2008-04-03
Start planning Suggested CRF Development Workflow

new study Standards3
Yes
Draft
Protocol
Protocol
Create draft Review with changes Review
Draft
based on cross functional needed? design against
CRF1
protocol/standards team2 No standards
Yes
Approved
New CRF Protocol
Version? Cross functional Finalize Adjust as
Approved Approval2 draft CRF necessary
No CRF
Process complete
High Level Overview of CRF Development Best Practices: No Yes
•1Develop along with the Protocol (and Statistical Analysis Need to add
Plan if available) to standards?
•2Develop as a cross-functional team
•All data for analysis collected?
•Possible to collect this way at the site?
•Appropriate data to address safety?
•3Implement and/or develop standards

DRAFT 2008-04-03
3.5. FAQs on Best Practices for Creating CRF Content and Structure
Ref Question CRF Type Best Practice Recommendation Rationale
1 Should “Yes/No” questions Paper and • If an assessment can have composite responses (e.g., presence or absence of • Yes/No questions provide a definite answer. The absence of
be preferred over electronic two or more symptoms), 'Yes/No' questions for each component response (e.g., a response is ambiguous as it can mean “no” or that the
“Tick/Check all that apply” symptom) are preferred to 'Tick/Check all that apply' questions. response is missing.
questions?
• Exceptions to this recommendation might include assessments where the • 'Tick/Check all that apply' questions are occasionally
majority of options would be answered 'No'. An example would be the needed where the number of options is high.
collection of ECG abnormality data where approximately 45 abnormalities
may be listed but only a few will apply.
2 Should there be a standard Paper and • It is recommended that a consistent order of Yes/No responses be used. • A standard order of Yes/No response boxes facilitates the
order for YES/NO response electronic use of the CRF.
boxes and other standardized
lists? • Presenting Yes/No responses in a standard order is ‘one
tool’ that can be used to reduce bias, but questions should
also be carefully worded so they don’t introduce bias or lead
the investigator to a desired response.
3 What date format should be Paper and • CDASH is recommending an unambiguous date format. • Using the international date format (DD-MMM-YYYY)
used for subject and site electronic will provide unambiguous dates and will be seen as the
completed CRF data? • For paper CRFs, or electronic studies in which the date is manually entered, same date by anyone who reads them. For example, the date
CDASH recommends the format of DD-MMM-YYYY for all date collection 06/08/02, can be interpreted as June 8, 2002 or August 6,
fields (whether the components are collected as a group or as separate 2002.
components of day, month and year).
• Note: If subject-completed CRF pages are translated into a
• For non-English study data, use a character-based month abbreviation that is local language, the international date may make it easier to
recognized in that language. translate the documents.
• For electronic data capture, the user may be able to select a date from a • Dates are collected in a user-friendly format and then
calendar, and this would also meet the recommendation for an unambiguous converted to the ISO 8601 format for submission.
date.
4 What time format should be Paper and CDASH recommends the use of a 24 hour clock using the HH:MM:SS format for • As many of the HH:MM:SS elements should be used as are
used for subject and site electronic recording times. 00:00:00 would indicate midnight with the next day’s date. needed for a particular field.
completed CRF data?
• Subject completed times may be recorded using a 12 hour
clock and an A.M. or P.M. designation. The time would
then be transformed to a 24 hour clock in the system.
• Times are collected in a user-friendly format and then
converted to the ISO 8601 format for submission.

DRAFT 2008-04-03
5 Should calculated data items Paper and • Calculated fields should not typically be recorded within the CRF when the • Data items which can be calculated from other data captured
be recorded on the CRF? electronic raw data on which the calculation is based are recorded in the CRF. within the CRF are more accurately reported if they are
calculated programmatically in-house using validated
• An exception is when a treatment and/or study conduct decision needs to be algorithms.
made based on those calculations. In those cases it may be useful for the
calculated field to be recorded within the CRF. • Capturing both the source data items and the calculated field
would be a duplication of data.
• It may also be useful to provide the site a step-by-step worksheet to record this
data. • If the calculated field is used to make a treatment and/or
study conduct decision, the results of the calculation would
be required on the CRF to explain the decision made.
6 Should all data collected on Paper • Data that are collected on CRFs should usually be databased. • Although the data recorded on worksheets are supporting
CRFs be databased? documentation for key information collected elsewhere in
• If data are not required for reporting or analysis, but collecting the data aids the CRF, these data are not needed in the clinical database
the investigator or monitor, it is recommended that data be collected on a and do not need to be recorded on the CRF.
worksheet. Worksheets used at the investigator’s site are not typically brought
in-house and will not subsequently be databased. (e.g., an entry criteria • All such worksheets should be considered source documents
worksheet, or a dose titration worksheet.) or monitoring tools, and should be maintained at the site
with the study files.
• Some fields, such as “Were there any Adverse Events – Yes/No” may need to
be databased, but will not be reported in submission data.
• Some fields, such as Investigator’s Signature, can be verified by the data entry
staff, but cannot actually be databased.
7 Should “Was assessment x Paper and • The database should contain an indication that an assessment was not • This will provide a definitive indicator to both clinical and
performed?” questions be electronic performed. The mechanism for this may be different from system to system, statistical programmers that a data field has missing data
collected and/or databased? or from paper to EDC. and has not been overlooked.
And • In some cases this might be a “Yes/No – assessment completed” question, or • This will prevent unnecessary data queries to clarify
“check if not done” box; in others it might be a blank flag or list of values to whether an assessment has been performed.
Should “Yes/No” exam
indicate why data are missing.
completed be preferred over
“Check if not done”
questions?

DRAFT 2008-04-03
8 Should free text be an option Paper and • The general recommendation from CDASH is that the collection of free text • The collection and processing of free text requires
for a response to a specific electronic comments and general comments pages should be discouraged. Collection of significant resources, and is of limited use when analyzing
question? free text should be limited to cases of specific safety or therapeutic need in and reporting clinical data.
reporting or analysis, such as Adverse Events, Concomitant Medications or
(Also refer to the Comments
Medical History. • Sites may enter data into free text fields that should be
Domain for additional recorded elsewhere.
information.) • CDASH recommends that questions be specific and clear, rather than open-
ended. Instead of free text, or solicited comments fields, CDASH recommends • Entering text from these fields into the database is time
a thorough review of the CRF by the protocol development team to maximize consuming for data entry and requires Data Management
the use of pre-defined lists of responses. resources to review the text for safety information and
inconsistencies with other recorded data.
9 Should data be pre-populated Paper or • The CRF should be used as a tool to collect unknown study data. • In general, study data should be collected and recorded by
in the CRF? electronic the site, not pre-populated.
• Fields in the database or on the CRF may be pre-populated
if the data are known to be the same for all subjects (e.g.,
MH CRF collects data for specific body systems - body
systems may be pre-populated), or if the data are assigned to
the subject (e.g., subject ID, site ID).
10 Should location of Paper and • Location data should be collected only when multiple possibilities are present, • Location options are only used when the protocol specifies.
measurement and position of electronic and the location is required to make a meaningful analysis of the data (e.g., a
subject (e.g., oral comparison of blood pressures collected supine, right arm and left arm).
temperature, blood pressure
from right arm, etc.) be
collected for each
assessment?
11 Should location of Paper and • CDASH recommends not providing actual coding dictionaries to the site for • CDASH recommends that guidance be provided to the sites
measurement and position of electronic adverse events, concomitant medications or medical history reported terms, as to ensure clear reporting of adverse events, concomitant
subject (e.g., oral this may bias responses. medications or medical history.
temperature, blood pressure
from right arm, etc.) be • For medications, this may include defining, for example,
collected for each whether generic or trade names are permissible.
assessment? • For medical history and adverse events, this may include
providing an understanding of the level of detail needed for
accurate medical coding - for example 'Diabetes' should not
be reported without providing the Type and sites may be
encouraged to record specific, medically correct
terminology on the forms - for example, "hyperglycemia,
not "high blood sugar".

DRAFT 2008-04-03
3.6. Common Identifier Variables
The following variables apply across all of the data collection domains.4
CDASH CRF Label/ Clinical Database Definition Instruction to Clinical Site Implementation / CDASH Core
Question Variable Name Rationale to Sponsors
(CDASH variables
shaded)
1 Protocol/Study STUDYID Unique Identifier for a study within a This is typically pre-printed in the header Highly
Identifier submission. of each CRF page. Recommended
In an EDC study, this would be hard-
coded into the study design.
For data received from electronic data
providers (e.g., central lab) this
information should be provided to the e-
data provider and verified during test and
production receipts of the e-data receipts.
2 Site Identifier SITEID Unique identifier for the site. Record your clinical site’s identifier as This is typically pre-printed in the header Highly
defined by the sponsor. of each CRF page for single site studies. Recommended
For studies with multiple sites, this field
is typically left blank so that the number
can be assigned per site.
In an EDC study, this should be pre-
populated in the screens provided to the
site.
data provider and verified during testing
of the e-data receipts.
4
SCDM’s GCDMP (v.4 2005) and GlaxoSmithKline CRF Principles
DRAFT 2008-04-03
(CDASH variables
shaded)
3 Subject SUBJID Subject identifier. Record the identifier for the subject. This is typically recorded in the header of Highly
each CRF page. Recommended
In an EDC study the subject identifiers
may be provided to the site using a pre-
populated list in the system.
data provider and verified during testing
of the e-data receipts.
The subject identifier recorded in the
CRF may be combined with other
identifiers to produce the SUBJID, or
may map directly to the SUBJID.
4 Investigator INVID Investigator identifier. Record the sponsor defined identifier for Study level – Not needed if SITEID is Optional
your site investigator. equivalent to INVID.
5 Visit Identification VISIT Visit Name. Protocol defined description of clinical This may be pre-printed in the header of Optional
encounter. each CRF page.
In an EDC study the VISIT may be pre-
populated or associated with particular
CRFs.
The VISIT, which is an alpha-numeric
data field, may be used to derive other
visit level data to the SDTM datasets.

DRAFT 2008-04-03
4. CDASH Domain Tables

4.1. Introduction
The following CDASH domain tables are arranged in alphabetical order. As mentioned previously in the
document, CRF layout was not within the scope of the CDASH project. As an alternative, the data collection
variables listed are presented in the order they commonly appear on a basic case report form.
The term “Case Report Form” used throughout this document refers to both paper and electronic formats. The
term data collection “fields” refers to fields that are commonly seen on the CRF. The term data collection
“variables” refers to what is seen in a clinical database.
4.2. Explanation of Table Headers
1 2 3 4 5 6
CDASH CRF Label/ Clinical Database Definition Instructions to Implementation/ CDASH Core
Question Variable Name Clinical Site Rationale for Sponsors
(CDASH variables
shaded)
1. CDASH CRF Label/Question - Provides descriptive text on the type of data to be collected on the CRF.
2. Clinical Database Variable Name - Lists the SDTM conforming variable name defined in the SDTM IG.
(CDASH variables shaded) - This column provides suggested data collection field names (e.g., CMONG
and CMTTM). These variable names are “SDTM-like variables” and can be
used as a tool for deriving the SDTM variable needed for reporting.
3. Definition – Describes the purpose of the data collection field. The text may or may not mirror the text in
the SDTM IG (under variable label or CDISC notes).
4. Instructions to Clinical Site - Contains information for the clinical site on how to enter collected
information onto the CRF.
5. Implementation/Rationale for Sponsors - Contains further information on how to implement the CRF data
collection variables.
Note: “Instructions for the Clinical Site” and “Implementation/Rationale for Sponsors” are provided only
for those data collection variables that are considered “Highly Recommended” and “Recommended/
Optional”.
6. CDASH Core: Contains the CDASH core designations for Basic Data Collection Variables. (See
Section 3.2 for definitions of core designations)

DRAFT 2008-04-03
4.3. Adverse Event – AE (Events)
These recommendations are for non-solicited or pre-specified adverse events. As with all the data collection variables recommended in the CDASH draft document, it
is assumed that Sponsors will add other data variables as needed to meet protocol specific and other data collection requirements (e.g. therapeutic area specific data
elements and others as required per protocol, business practice and operating procedures).
CDASH CRF Label/ Clinical Database Definition Instructions to Clinical Site Implementation/ CDASH Core
Question Variable Name Rationale for Sponsors
(CDASH variables
shaded)
1 Were any Adverse AEYN General prompt question to aid in Indicate if the subject experienced any The intent/purpose of collecting this field is Optional
Events Experienced? monitoring and data cleaning. adverse event. If yes, include the to help with data cleaning and monitoring.
appropriate details were indicated.
Note: AEYN will not be included as part of
the SDTM AE Domain for submission.
2 AE Number AESPID A sponsor-defined reference number. None. Optional Sponsor-defined reference Optional
number. Perhaps pre-printed on the CRF as
an explicit line identifier or defined in the
sponsor’s operational database (derived)
(e.g., line number on an Adverse Event
page).
For paper AE CRFs, it can be beneficial to
use a sequence number in a data query to
clearly communicate to the site the specific
record in question.

DRAFT 2008-04-03
(CDASH variables
shaded)
3 Adverse Event AETERM Verbatim (i.e., investigator reported Using accepted medical terminology, enter In most cases, the verbatim term (i.e., Highly
term) description of the adverse event. the diagnosis (if known); otherwise enter a investigator reported term) will be coded to Recommended
sign or symptom. If a diagnosis a standard dictionary such as MedDRA,
subsequently becomes available, then this WHO ART, after the data has been
diagnosis should be entered on the AE collected on the CRF.
form, replacing the original entries, where
appropriate.
Death should not be recorded as an event
but should be recorded as the outcome of
the event. The condition that resulted in the
death should be recorded as the event.
Record only one diagnosis, sign or
symptom (e.g., nausea and vomiting should
not be recorded in the same entry, but as 2
separate entries).
Do not use abbreviations.
4 Serious Event AESER Indicates whether or not the adverse Assess if an adverse event should be This field is related to ‘Serious Event type’ Highly
event is determined to be “serious” classified as serious according to serious field, which may or may not be reported on Recommended
according to the protocol. criteria. the CRF.
5 Serious Event Type AESERTP ** Captures the criteria required by Indicate the category of the adverse event This field can be used with ‘Serious Event’ Optional
protocol for determining why an event that classified the event as "serious". Select field to classify which serious criteria were
Or is “Serious”. all that apply. used to determine that the event was
AESCAN serious.
AESCONG Select all that apply implies that a field
exists for each corresponding SDTM
AESDISAB variables.
AESDTH "Serious Event Type" variable may be
AESHOSP optionally on CRF or in external collection
document (SAE Form). Capture of this data
AESLIFE would be conditional on the occurrence of a
serious event.
AESOD
**A sponsor can choose to database this
AESMIE
with a single variable AESERTP or as
(see below) separate variables.

DRAFT 2008-04-03
(CDASH variables
shaded)
5a Serious Event Type – AESCAN Captures the criteria required by Was the event associated with cancer? See above, the sponsor may choose to Optional
Cancer protocol for determining why an event database as a single variable AESERTP or
is “Serious”. as separate variables.
5b Serious Event Type – AESCONG Captures the criteria required by Was the event associated with congenital Optional
Congenital anomaly protocol for determining why an event anomaly?
is “Serious”.
5c Serious Event Type – AESDISAB Captures the criteria required by Did the event result in persistent or Optional
disability/incapacity protocol for determining why an event significant disability/incapacity?
is “Serious”.
5d Serious Event Type – AESDTH Captures the criteria required by Did the event result in death? Optional
Death protocol for determining why an event
is “Serious”.
5e Serious Event Type – AESHOSP Captures the criteria required by Did the event require or prolong Optional
Hospitalization protocol for determining why an event hospitalization?
is “Serious”.
5f Serious Event Type – AESLIFE Captures the criteria required by Was the event life threatening? Optional
Life threatening protocol for determining why an event
is “Serious”.
5g Serious Event Type – AESOD Captures the criteria required by Did the event occur with an overdose? Optional
Overdose protocol for determining why an event
is “Serious”.
5h Serious Event Type – AESMIE Captures the criteria required by Do additional categories of seriousness Optional
Additional categories protocol for determining why an event apply?
for seriousness is “Serious”.
6 Start Date AESTDTC Date when the adverse event started. Record the date that the AE began using the For the SDTM dataset, the SDTM Highly
international date format. For more detail Variable AESTDTC is derived by Recommended
see the Best Practice section. concatenating CDASH Start Date and Time
(if time is collected) into AESTDTC using
the ISO 8601 format.

DRAFT 2008-04-03
(CDASH variables
shaded)
7 Start Time AESTTM Time when the adverse event started. If appropriate, record the time (as complete Collecting the time an AE was started is Recommended/
(Note: If collected, as possible) that the AE began. For more only appropriate if it can be realistically Conditional
will be derived into detail see the Best Practice section. determined and if there is a scientific reason
AESTDTC.) for needing to know this level of detail.
Typically, it is not recommended that a start
time be collected unless the subject is under
the direct care of the site at the time the
event started.
For the SDTM dataset, the SDTM
Variable AESTDTC is derived by
concatenating CDASH Start Date and Time
(if time is collected) into AESTDTC using
8 End/Stop Date AEENDTC Date when the adverse event resolved. Record the date that the AE ended using the For the SDTM dataset, the SDTM Highly
international date format. For more detail Variable AEENDTC is derived by Recommended
see the Best Practice section. concatenating CDASH End/Stop Date and
Time (if time is collected) into AEENDTC
If the AE is ongoing, leave the field blank. using the ISO 8601 format.
9 Ongoing/Continuing AEENRF Indicates AE is ongoing when no If the adverse event has not stopped at the This field will be checked to indicate that Optional
End/Stop date is provided. time of data collection, check the ongoing/ the AE has not stopped at the time of data
AEONGO continuing box and leave the end/stop date collection. Upon study completion, it is
blank. expected that every reported AE should
have either End/Stop Date or be checked as
Ongoing/continuing, but not both.
This is not a direct mapping to AEENRF.
The date of data collection in conjunction
with end/stop date and the
ongoing/continuing check box would
determine how AEENRF will be populated.

DRAFT 2008-04-03
(CDASH variables
shaded)
10 End/Stop Time AEENTM Time when the adverse event resolved. If appropriate, record the time (as complete Collecting the time an AE ended or stopped Recommended/
(Note: If collected, as possible) that the AE resolved. For more is only appropriate if it can be realistically Conditional
will be derived into detail see the Best Practice section.. determined and if there is a scientific reason
AEENDTC.) for needing to know this level of detail.
Typically, it is not recommended that a
End/Stop time be collected unless the
subject is under the direct care of the site at
the time the event resolved.
Variable AEENDTC is derived by
concatenating CDASH End/Stop Date and
Time (if time is collected) into AEENDTC
using the ISO 8601 format.
11 AE Severity AESEV Description of the severity of the Severity: The reporting Provide the appropriate controlled Highly
adverse event. physician/healthcare professional will terminology for AE Severity. Recommended
And/or assess the severity of the adverse
drug/biologic event using the established Either AESEV or AETOXGR must appear
AETOXGR on the CRF. Some studies may mandate the
categories. This assessment is subjective
and the reporting physician/ healthcare collection of both.
professional should use medical judgment Note: Completion of CTCAE grade is a
to compare the reported Adverse Event to mandatory field for cancer studies. In all
similar type events observed in clinical other types of studies this is an optional
practice. Severity is not equivalent to field.
seriousness.
And/or
Severity CTCAE Grade: The reporting
physician/healthcare professional will
assess the severity of the adverse event
using the toxicity grades.

DRAFT 2008-04-03
(CDASH variables
shaded)
12 Relationship AEREL Indication of whether the investigational Indicate if the cause of the adverse event is Provide the appropriate controlled Highly
product had a causal effect on the related to the investigational product and terminology for indication of the Recommended
adverse event, as reported by the cannot be reasonably explained by other relationship between the AE and the
clinician/investigator. factors (e.g., subject’s clinical state, investigational product.
concomitant therapy, and/or other
interventions) OR if the cause of the
adverse event is unknown.
13 Relationship Type AERELTP Captures a category for an Record the relationship category for adverse Provide the appropriate controlled Recommended/
investigational product to which an events to the investigational product. One or terminology for AE Relationship Type. Conditional
adverse event is related. more relationship type may be indicated. Relationship Type might be captured and
For example, the Adverse Event might be the relationship (AEREL) derived. One or
related to both study treatment more relationship type may be captured.
(investigational product) and study device.
14 Action Taken AEACN Action(s) taken with the investigational Record the action(s) taken with the Provide the appropriate controlled Highly
product in response to the adverse investigational product resulting from the terminology for action taken with the Recommended
event. adverse event. investigational product in response to the
AE.
15 Other Action Taken AEACNOTH Describes Other Action(s) taken in Action Other: Record all other action(s) Provide the appropriate instructions for Optional
response to the adverse event. (Does not taken. capture of this field. (Note: The CDISC
include investigational products) controlled terminology team is reviewing
controlled terminology for Other Action
Taken.)
16 Outcome AEOUT Description of the subject’s status Record the appropriate outcome. Provide the appropriate controlled Highly
associated with an event. terminology for Outcome. Recommended
Note: Regarding study discontinuations caused by Adverse Events: Some companies capture this information on the AE CRF, usually as a Y/N question; others
capture this information on the Study Summary or Study Discontinuation page.

DRAFT 2008-04-03
4.4. Comments – CO (Special Purpose)
4.4.1. Solicited Comments
Solicited comments are defined as those entered in free-text fields intentionally included on the CRFs. These fields provide the site with a pre-defined space to further
explain or clarify an associated variable within the CRF. For example, the Adverse Events CRF may include a Comments field which enables recording of free text.
Solicited comments have also previously been collected using a General Comments CRF. Of the companies represented within the CDASH Comments sub-team, only
one company indicated that they continue to collect free text on a General Comments CRF; all others are discontinuing or have discontinued such practices.
4.4.2. Unsolicited Comments
Unsolicited comments are those comments entered outside of pre-defined fields (also referred to as “marginal” comments as they are often written in margins). These
may include marginal CRF comments entered by site staff, written by the subject on patient diaries, or EDC capability to capture comments that are not generally
included in any clinical domain. Although such comments may be intended to avoid queries, in practice they often lead to data not being entered into the correct field
and cause additional work in the review process.
4.4.3. Considerations Regarding Usage of a General Comments CRF
Solicited comments have also previously been collected using a General Comments CRF. Of the companies represented within the CDASH Comments sub-team, only
one company indicated that they continue to collect free text on a General Comments CRF; all others are discontinuing or have discontinued such practices.
The Comments sub-team decided there should be no mandatory data elements for inclusion in a separate Comments CRF. The sub-team suggests avoiding the creation
of a General Comments CRF. This does not pertain to solicited free-text comment fields that may appear within another established domain.
4.4.4. Rationale
Clinical data must be entered in appropriate fields; otherwise, there is a potential for hidden safety events. For example, if an unsolicited general comment of “subject
visit was delayed as he had the flu” was captured, this would necessitate that “flu” be entered in the Adverse Event CRF and not left as a comment.
The Comments sub-team encourages CRF development teams to strive for better data collection methods rather than relying on a General Comments CRF. If there is
no mechanism for recording general comments (not related to specific data points), it will be incumbent upon teams to design data collection tools capable of capturing
all required data for analysis purposes in dedicated fields. The Comments sub-team suggests that CRF development teams consider what additional information may be
needed within a specific CRF. It is better to ask specific questions through creation of well-defined variables that will be more meaningful for analysis rather than
inconsistently capturing this information within general comments fields.

DRAFT 2008-04-03
General comments are inefficient to program against due to inconsistent wording and frequent misspellings and therefore offer limited or no value for statistical
analysis, as they cannot be tabulated. An additional concern is the potential for inappropriate, or sensitive, information to be included within general comments fields.
For example, a comment could contain a name or may have unblinding information.
Unsolicited comments which may have been intended to avoid queries, for example “subject visit was delayed due to his holidays”, are not regarded as clinical data.
The Investigative site or monitor should be trained to enter the contents of the comments in the appropriate field rather than making marginal notes on the CRF. There
is a higher time/cost consideration associated with unsolicited comments and they should be discouraged, as they are labor intensive to data-enter, review and act upon.
4.4.5. Conclusion
There does not appear to be an ICH E3 requirement to include unsolicited comments in the datasets that are submitted to the regulatory parties. The Comments sub-
team consensus and recommendation is that only the parameters captured in appropriate CRF fields are considered clinical study data that is submitted to regulatory
parties in datasets; all other comments are considered unsolicited comments.
Individual sponsor companies must determine their own path in handling the situation should unsolicited comments appear on CRFs.

DRAFT 2008-04-03
4.5. Concomitant Medications – CM (Interventions)
The same basic data collection variables should be collected for both General Medications and Medications of Interest. It is assumed that additional fields will be added
as applicable for each specific Medication of Interest. For the purposes of this effort, General Medications were considered the primary focus, not Medications of
Interest. The term “Prior” refers to medications that were started prior to study participation.
4.5.1. General Medications
General Medications are defined as any medications spontaneously reported by a subject when asked if they have taken any medications in an open-ended way that
does not ask about any specific drug.
4.5.2. Medications of Interest
Medications of Interest are defined as any medications or classes of drugs specifically mentioned in the protocol, (e.g. excluded medications, drugs requiring a washout
period prior to dosing in study, or rescue medications.
Medications of Interest were excluded from this document due to the fact that by definition, the collection of data for drugs specifically mentioned in the protocol is
likely to change from protocol to protocol and data collection will be at a higher degree of detail and those details can change significantly depending on the exact
nature of the Medications of Interest. Among the many reasons for this are:
• Identification of unanticipated drug-drug interaction signals.
• To assess the use of medications that may mask or enhance efficacy.
• To provide details regarding the possible cause or course of adverse events.
As with all the data collection variables recommended in the CDASH draft document, it is assumed that Sponsors will add other data variables as needed to meet
protocol specific and other data collection requirements (e.g. therapeutic area specific data elements and others as required per protocol, business practice and operating
procedures).

DRAFT 2008-04-03
(CDASH variables
shaded)
1 Were any Medications CMYN General prompt question to aid in Indicate if the subject took any medications. The intent/purpose of collecting this field is Optional
Taken? monitoring and data cleaning. If yes, include the appropriate details where to help with data cleaning and monitoring.
indicated.
Note: CMYN will not be included as part of
the SDTM CM Domain for submission.
2 Medication Number CMSPID A sponsor-defined reference number. None. Optional Sponsor-defined reference Optional
number. Perhaps pre-printed on the CRF as
an explicit line identifier or defined in the
sponsor’s operational database (derived)
(e.g., line number on an concomitant
medication page).
For paper Prior & Concomitant Medication
CRFs, it can be beneficial to use a sequence
number in a data query to clearly
communicate to the site the specific record
in question.
3 Reported Name of CMTRT Verbatim drug name that is either pre- Provide the full trade or proprietary name of In most cases, the verbatim drug names will Highly
Drug, Medication or printed or collected on a CRF. the drug; otherwise the generic name may be coded to a standard dictionary such as Recommended
Therapy be recorded. WHO DRUG after the data has been
collected on the CRF.
For the collection of verbatim drug name,
the recommendation is to ask the sites to
provide the full trade name or proprietary
since it is more exact then the generic. The
full trade name provides the base generic
and the appropriate salt for that particular
drug. In addition, for coding purposes it
helps with ATC selection.
For example the medication Tylenol with
codeine #1 has a different ATC code from
Tylenol with codeine #3.

DRAFT 2008-04-03
(CDASH variables
shaded)
4 Active Ingredient CMINGRD Medication Ingredients. Record all active ingredient(s) for the This may be collected in addition to the Optional
reported name of drug medication or reported name of Drug Medication or
therapy taken Therapy.
Collecting this provides more detailed
information when coding to a medication
dictionary like WHO Drug Enhanced
format C which now codes to the ingredient
level for many trade named medication.
For example, the medication Dolmen,
depending on the country where it is
manufactured, the active ingredients may be
different.
Spain: Acetylsalicylic Acid, Ascorbic acid,
codeine phosphate
Italy and Czech Republic: contains
Tenoxicam
Estonia and Latvia: contains Dexketoprofen
trometamol
5 Indication CMINDC The reason for administration of a Record the reason the medication was This additional information is collected on Recommended/
concomitant (non-study) medication. taken. the CRF when the sponsor would want to Conditional
(e.g., Nausea, Hypertension) capture the reason(s) why a subject took a
If taken to treat a condition, and a diagnosis medication.
This is not the pharmacological/ was made, the diagnosis is what should be
therapeutic classification of an agent reported (the symptoms may be inferred or This information can then be used as
(e.g., antibiotic, analgesic, etc.), but the they may be recorded separately). deemed appropriate for coding, analysis
reason for its administration to the (i.e., in the classification of medications),
subject. If taken to treat a condition, and no for reconciling the medications taken by a
diagnosis was made, record the symptoms. subject with their provided medical history
If taken as prophylaxis, we recommend and/or AEs/SAEs as part of the data clean-
reporting as “Prophylaxis for…”. up and monitoring process, etc.

DRAFT 2008-04-03
(CDASH variables
shaded)
6 AE Number AESPID Identifier for the adverse event that is None. Intent is to establish a link between the Optional
the indication for this medication. adverse event and the medication taken for
the adverse event, but there may be other
ways to collect this type of information.
Utilizing this variable to maintain a link to a
sequence number associated with an AE
may result in unnecessary data cleaning
work. For example, if the AE number gets
reassigned or deleted due to a query
response or a correction by the clinical site.
Note: AESPID will not be included in the
SDTM CM domain in submissions.
7 Total Daily Dose CMDOSTOT Total daily dose taken. None. In some clinical trials (such as Phase I), Recommended/
individual doses are more likely to be Conditional
collected and total daily dose calculated, but
in later phase trials (such as Phase IV/post
marketing trials), the total daily dose my be
all that is collected.
With the exception of later phase trials, for
general medication, it is not recommended
to use “Total Daily Dose”. Instead, this can
be calculated or derived from other fields
such as Dosage Units, Dosage Amount and
Dosage Interval to avoid confusion and
calculation by the clinical site.

DRAFT 2008-04-03
(CDASH variables
shaded)
8 Dose Form CMDOSFRM Name of the pharmaceutical dosage None. We recognize that some drugs have Optional
form (e.g., tablets, capsules, syrup) of multiple forms and this field may be needed
delivery for the drug. to code the drug to an ATC level.
However, in general, this level of detail
should not be necessary except for
medications of interest.
If this field is not on the CRF, but a
medication that happens to need the
formulation for coding purposes is
recorded, the site could be queried to add
the formulation as part of the drug name.
Where possible it is recommended that
Sponsor provide the appropriate
controlled terminology for dose form.
9 Dosing Frequency per CMDOSFRQ How often the medication was taken None. When collected, the recommendation is to Optional
Interval (e.g., BID, every other week, PRN). collect dosing information in separate fields
for specific and consistent data collection.
See below for the rest of the dosing
information components (Dose per
administration, and dose unit.)
10 Dose per CMDSTXT The dose of medication taken per None. Where this level of dosing information is Optional
Administration (Note: If collected, administration. required by a sponsor, this field may be
will be derived into included.
CMDOSTXT or
CMDOSE.) Defining this data collection field as a dose
text field allows for flexibility in capturing
text entry (e.g., range of dosing 200-400).
CMDSTXT is not a direct mapping to the
SDTM variable CMDOSTXT. The data
collected in this dose text-format field need
to be separated or mapped to either SDTM
CMDOSE if numeric or CMDOSTXT.
11 Dose Unit CMDOSU Within structured dosage information, None. Where this level of dosing information is Optional
the unit associated with the dose (e.g., required by a sponsor, this field may be
"mg" in "2mg three times per day). included.

DRAFT 2008-04-03
(CDASH variables
shaded)
12 Intended Dose CMDOSRGM Within structured dosage information, None. Where this level of dosing information is Optional
Regimen the number of units for the interval (e.g., required by a sponsor, this field may be
in oncology where drug is given 1 week included.
on, and 3 weeks off).
13 Route of CMROUTE Identifies the route of administration of Provide the route of administration for the This additional information may be Recommended/
Administration the drug. drug. important to collect on the CRF when the Conditional
sponsor would want to capture a
medication’s route of administration for
purposes such as coding and the medication
may have more than one route. Some
companies may use route in coding
medications to be able to choose a precise
preferred name and ATC code.
14 Start Date CMSTDTC Date when the medication was first (If collecting the date) Record the date the The preferred method is to collect a Start Highly
taken. medication was first taken using the Date. Partial dates (i.e., YY) for medications Recommended
Or international date format. For more detail started prior to the study are acceptable.
see the Best Practice section.
If the subject has been taking the Variable CMSTDTC is derived by
medication for a considerable amount of concatenating CDASH Start Date and Time
time prior to the start of the study, it is (if time is collected) into CMSTDTC using
acceptable to have an incomplete date. the ISO 8601 format.
Medications started during the study are
expected to have a complete date.
For Prior medications that are protocol
defined as excluded medications, these
medications need to be recorded as stopped
prior study start (study start is a sponsor
defined reference period.)
15 Start Relative to CMSTRF Relative time frame that the medication (If collecting the relative time frame) If instead of Start Date, information such as
Reference Period was first taken with respect to the Indicate if this medication was started BEFORE or DURING is collected, this
sponsor-defined reference period. before the study or during the study. information is derived in the CMSTRF
variable.

DRAFT 2008-04-03
(CDASH variables
shaded)
16 Start Time CMSTTM Time the medication was started. If appropriate, record the time (as complete Collecting the time a medication was started Recommended/
(Note: If collected, as possible) that the medication was started. is only appropriate if it can be realistically Conditional
will be derived into For more detail see the Best Practice determined and if there is a scientific reason
CMSTDTC.) section. for needing to know this level of detail.
Typically, it is not recommended that a start
time be collected unless the subject is under
the direct care of the site at the time a
medication is taken.
Variable CMSTDTC is derived by
concatenating CDASH Start Date and Time
(if time is collected) into CMSTDTC using
17 End/Stop Date CMENDTC Date that the subject stopped taking the Record the date the subject stopped taking The assumption is that sponsors should Highly
medication. the medication using the international date either have a complete stop date or will Recommended
format. For more detail see the Best indicate that the medication was ongoing at
Practice section. the end of the study.
If the subject has not stopped taking the For the SDTM dataset, the SDTM
medication leave this field blank. Variable CMENDTC is derived by
If the Ongoing/Continuing box is also Time (if time is collected) into CMENDTC
collected, check the Ongoing/Continuing using the ISO 8601 format.
box and leave the End/Stop Date blank.
18 Ongoing/Continuing CMENRF Indicates medication is ongoing when If subject has not stopped taking the This box should be checked to indicate that Optional
no End/Stop Date is provided. medication at the time of data collection, the medication has not stopped at the time
CMONGO check the Ongoing/Continuing box and of data collection.
(Note: If collected, leave the End/Stop Date blank.
will be derived into At study completion, it is expected that
CMENRF.) every reported medication should have
either End/Stop Date or be checked as
Ongoing/continuing, but not both.
This is not a direct mapping to CMENRF.
The date of data collection in conjunction
with stop date and the ongoing/continuing
check box would determine how CMENRF
will be populated.

DRAFT 2008-04-03
(CDASH variables
shaded)
19 End/Stop Time CMENTM Time when the subject stopped taking If appropriate, record the time (as complete Collecting the time a medication was Recommended/
(Note: If collected, the medication. as possible) that the medication was stopped is only appropriate if it can be Conditional
will be derived into stopped. For more detail see the Best realistically determined and if there is a
CMENDTC.) Practice section. scientific reason for needing to know this
level of detail. Typically, it is not
recommended that a stop/end time be
collected unless the subject is under the
direct care of the site when the subject
stopped taking the medication.
Variable CMENDTC is derived by
Time (if time is collected) into CMENDTC

DRAFT 2008-04-03
4.6. Demography – DM (Special Purpose)
The team noted that many of the variables collected have a one-to-one mapping to SDTM variables for delivery. Privacy concerns surrounding the DM & SC data have
been noted and discussed by the team. Some of the variables collected may map in a many-to-one fashion (i.e. many collected components map to one SDTM variable).
This perspective provided flexibility in categorizing some variables to help solve thorny “regulatory” (privacy) issues.
4.6.1. Collection of Age vs. Birth Date
The CDASH DM/SC team recognizes that sponsors could collect the age or birth date of the subject, or both. We recognize that knowing the age at a given date leaves
the sponsor with a window of uncertainty of, at most, 366 days if the age needs to be recalculated for a date which is different than the date the age was collected. We
recognize that knowing the precise birth date provides the ability to accurately calculate an age for any date. We further recognize that a precise (and complete) birth
date may be seen as too identifying for some privacy oversight boards or governmental regulators. In looking for a solution, we recognize that SDTM allows for the
reporting of dates with the amount of precision that was collected (e.g. year only, year + month, year + month + day, year + month + day + time) and that if we treat the
components of the birth date separately we could provide the mechanism to collect data that would leave a smaller window of uncertainty. This solution requires the
collection of the year and month of birth, makes the collection of day conditional and the collection of birth time as optional (such as when needed for infant, neonatal
or pediatric studies). This approach would minimally collect sufficient data about the birth date which would give a window of uncertainty of, at most, 31 days for all
age calculations.
The DM team concluded that, by identifying the component parts of a complete SDTM variable BRTHDTC (year + month + day +/- time of birth), we could provide a
solution which balances the collection of meaningful analytical source data with meeting privacy requirements.
The CDASH DM/SC team’s preference is to collect the date of birth (minimally birth year and birth month) and derive age, rather than collecting age, even when there
are privacy concerns with collecting the complete birth date. This approach does not disallow the collection of age; it merely makes age an optionally collected
variable.
The DM team recommends collecting the components of a full birth date as follows: Year + Month +/- Day +/- Time of birth. The design of the CRF should place the
variables that are to be collected together, but they may be electronically stored together or separately, however the entry and storage is best managed. If entered or
stored separately, the birth date values that are collected may be concatenated into a reportable date, with possibly a lesser degree of precision than a complete date, and
the sponsor should be able use this as meaningful data for analysis. This imprecision should also obscure the personal information enough to protect the privacy of the
trial participant, and should satisfy regulatory or privacy boards that oversee the collection of these data.
When the mandatory “birth year” and “birth month” components are collected but the conditional “birth day” is not collected the sponsor may report the date in ISO
8601 structure (compliant with SDTM) and the BRTHDTC variable would be created by populating the year and month components of ISO 8601, but omitting the day.

DRAFT 2008-04-03
(CDASH variables
shaded)
1 Year of Birth BRTHYR Year of subject’s birth. Record the subject’s year (e.g., YYYY, a A collected variable used for recording the Highly
four digit year, or collect only the last two year component of the “Date of Birth”. Recommended
digits) of birth as required for the form.
(See Section 4.6.1 Collection of Age vs.
Birth Date.)
2 Month of Birth BRTHMO Month of subject’s birth. Record the subject’s month MMM (JAN- A collected variable used for recording the Highly
DEC) of birth. month component of the “Date of Birth”. Recommended
Birth Date.)
3 Day of Birth BRTHDY Day of subject’s birth. Record the subject’s day of birth A collected variable used for recording the Recommended/
(DD, 01-31). day component of the “Date of Birth”. Conditional
The day of birth should be collected unless
an Ethics Committee or local Data
Protection Authorities (DPA) disagrees with
the collection of the complete Date of Birth
due to privacy concerns. In this case it
might be best to omit this component of the
“Date of Birth” to assuage those concerns.
Birth Date.)
4 Time of Birth BRTHTM Time of subject’s birth, Optionally, if appropriate, record the time This level of detail may be necessary for Optional
of birth (as complete as possible). analysis for some pediatric, natal or
neonatal studies.
For more detail see the Best Practice
section. (See Section 4.6.1 Collection of Age vs.
Birth Date.)
5 Sex SEX The assemblage of physical properties Record the appropriate sex (e.g., female, As reported by subject or caretaker. Highly
or qualities by which male is male) as required on this form. Recommended
distinguished from female; the physical
difference between male and female; the
distinguishing peculiarity of male or
female. (NCI – CDISC Definition).

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Age AGE Numeric Age of Subject. Age needs to be collected as a number and, Optional
to be correctly interpreted, the age value
needs to be associated to a variable for the
Age Unit. It is also helpful to know when
the age was collected as an age may need to
be recalculated for analysis, such as
deriving age at a reference start time
(RFSTDTC for SDTM).
7 Age Units AGEU Age units. Record the appropriate age unit (e.g., years, If Age is captured on the CRF, the site must Optional
months, etc.) as required on the form. also record age unit(s) to make the “Age”
value meaningful.
Birth Date.)
8 Date of Collection DMDTC Date of collection. Record the date the demographics data was The date of collection may be derived from Recommended/
collection in the international date format. the date of visit and if so, a separate date Conditional
field is not required.
For more detail see the Best Practice
section. For the SDTM data set, the SDTM
variable DMDTC is derived by
concatenating CDASH Date and Time of
collection (if time is collected) into
DMDTC using the ISO 8601 format.
(See AGE Implementation / Rationale.)
9 Time of Collection DMTM Time of collection. Record the time of collection (as complete For the SDTM data set, the SDTM Optional
(Note: If collected, as possible). For more detail see the Best variable DMDTC is derived by
will be derived into Practice section. concatenating CDASH Date and Time of
DMDTC.) collection (if time is collected) into
DMDTC using the ISO 8601 format.
Only record if this level of detail is
necessary for analysis. The time of
collection may be derived from the time of
visit, and if it is so collected, a separate
collection time field is not required.

DRAFT 2008-04-03
(CDASH variables
shaded)
10 Ethnicity ETHNIC A social group characterized by a Study participants should self-report race If more detailed characterizations of race or Optional
distinctive social and cultural tradition and ethnicity whenever feasible, with ethnicity are collected to enhance data
maintained from generation to ethnicity being asked about before race. quality and consistency, it is recommended
generation, a common history and origin that they be “collapsible” up to the five
and a sense of identification with the minimum designations for race, as well as
group; members of the group have the two categories for reportable ethnicity,
distinctive features in their way of life, as needed for reporting to FDA under its
shared experiences and often a common guidance. When more detailed
genetic heritage; these features may be categorizations are desired, the use of race
reflected in their experience of health and vocabulary tables located within Health
and disease. Level Seven’s Reference Information
(NCI – CDISC Definition) Model Structural Vocabulary Tables is
recommended, as they are designed to
collapse up in this manner.
Other regulatory bodies may expect the
reporting of ethnicity values (different
than the US FDA) which more
appropriately reflect the population of
their areas (e.g., Japanese ancestry for
MHLA reporting to Japan). These may
be collected as an extension to the
suggested NCI-CDISC code list.

DRAFT 2008-04-03
(CDASH variables
shaded)
11 Race of Subject RACE An arbitrary classification based on Study participants should self-report race The categories listed in the FDA Guidance Highly
physical characteristics; a group of and ethnicity whenever feasible. If both are as follows: Recommended
persons related by common descent or race and ethnicity are collected it is
heredity. recommended, by the FDA guidance, that -American Indian or Alaska Native
ethnicity be asked about before race. -Asian
-Black or African American*
(The FDA guidance suggests “that -Native Hawaiian or Other Pacific Islander
individuals be permitted to designate a -White
multiracial identity/”. “Check all that apply”
at the time of collection.) *For studies where data are collected
outside the US, the recommended
categories are the same except for Black
instead of Black or African American
If more detailed characterizations of race or
ethnicity are collected to enhance data
quality and consistency, it is recommended
that they be “collapsible” up to the five
minimum designations for race, as well as
the two categories for reportable ethnicity,
as needed for reporting to FDA under its
guidance. When more detailed
categorizations are desired, the use of race
and vocabulary tables located within Health
Level Seven’s Reference Information
Model Structural Vocabulary Tables is
recommended, as they are designed to
collapse up in this manner.

DRAFT 2008-04-03
4.7. Disposition – DS (Events)
The team took as its remit the extensive consideration of only disposition events, but was also requested to consider protocol milestones. We note that the DS domain
allows for the documentation (and submission) of the completion of protocol milestones (e.g. informed consent obtained, randomized). The team has not considered
the specification of CRF questions (or “mini CRF modules”) to capture this information, but accepts that such questions may be included in appropriate places in the
CRF (e.g. the date of informed consent is typically collected on the same CRF page as demography data but is mapped for submission to the DS domain) for those
sponsors who desire to formally document the completion of protocol milestones.
The team held extensive discussions around the vocabulary to be used in a controlled terminology list for ‘Reason for discontinuation’, basing these discussions on the
list already published by the CDISC Terminology group. The team will continue to work to agree upon recommendations to be discussed at a later date with the
Terminology group.
CDASH CRF Label/ Clinical Database Definition Instruction to Clinical Site Implementation/ CDASH Core
(CDASH variables
shaded)
1 Trial Epoch EPOCH Trial epoch (e.g., trial cycle, phase, end (Typically, the trial epoch will be pre-printed Typically, the trial epoch will be pre- Recommended/
of study, etc.) for which subject on the CRF as the title of the page; however, printed on the CRF as the title of the page; Conditional
disposition is being collected for those companies whose standard CRF however, some companies have a standard
module includes a “pick-list” of epochs, the CRF module that includes a “pick-list” of
following instruction is given) epochs
Check the <epoch, or insert more
appropriate wording> for which disposition
is being recorded
2 Subject Status DSDECOD Standardized Disposition Term Document the subject’s status at <insert text Highly
corresponding to the selected trial epoch>. If Recommended
And And the subject discontinued prematurely, record
DSTERM Reported term for the Disposition Event the primary reason for discontinuation.
of the subject at a selected trial epoch

DRAFT 2008-04-03
(CDASH variables
shaded)
3 Date of Completion or DSSTDTC The date that the subject completed the Record the date that the subject completed Define in the protocol and/or CRF Recommended /
Discontinuation selected trial epoch, or the date that the the <epoch, or insert more appropriate Completion Instructions the criteria for Conditional
subject discontinued from the selected wording> as defined in the protocol and/or completion of each trial epoch for which a
trial epoch, using the international date CRF Completion Instructions using the disposition CRF will be provided
format. international date format. If the subject did
not complete the <epoch, or insert more Only collect the date of completion or
appropriate wording>, record the date using discontinuation on the disposition CRF
the international date format that they module if the same information is not
discontinued to the best of your knowledge. being collected on another CRF module.
For example, if the date of the last dose is
For more detail see the Best Practice section. defined to mark the end of the Treatment
Phase epoch, and is collected on the Drug
Exposure form, then this field would not
be collected on the Disposition CRF
module.

Variable DSSTDTC is derived by
Completion or Discontinuation (if time is
collected) into DSSTDTC using the ISO
8601 format.

DRAFT 2008-04-03
(CDASH variables
shaded)
4 Time of Completion or DSSTTM The time that the subject completed the Record the time (as complete as possible) Define in the protocol and/or CRF Optional
Discontinuation (Note: If collected, selected trial epoch, or the time that the that the subject completed the selected trial Completion Instructions the criteria for
will be derived into subject discontinued from the selected epoch as defined in the protocol and/or CRF completion of each trial epoch for which a
DSSTDTC.) trial epoch. Completion Instructions. If the subject did disposition CRF will be provided
not complete the selected trial epoch, record
the time (as complete as possible) that they Collecting the time of completion or
discontinued to the best of your knowledge. discontinuation is only appropriate if it can
be realistically determined and if there is a
For more detail see the Best Practice section. scientific reason for needing to know this
level of detail. Typically, it is not
recommended that a time be collected
unless the subject is under the direct care
of the site at the time of the event.
Only collect the time of completion or
discontinuation on the disposition CRF
module if the same information is not
being collected on another CRF module.
For example, if the time of the last dose is
defined to mark the end of the Treatment
Phase epoch, and is collected on the Drug
Exposure form, then this field would not
be collected on the Disposition CRF
module.
Variable DSSTDTC is derived by
Completion or Discontinuation (if time is
collected) into DSSTDTC using the ISO
8601 format.
5 Was treatment DSUNBLND Identifies in a blinded trial whether or Was the subject’s treatment assignment None. Optional
unblinded by the site? not the subject’s blind was broken by unblinded by the site?
the site.
6 Will the subject DSCONT Plan for subject continuation to the next To the best of your knowledge, record if the Sponsor should specify what the next Optional
continue? phase of the trial or another related trial subject will be continuing to the next phase phase of the trial or the related trial is.
at the time of completion of the CRF. of this trial or another related trial?

DRAFT 2008-04-03
(CDASH variables
shaded)
7 Next trial epoch or DSNEXT Identifies the trial epoch or new trial in Record the trial epoch or trial identifier if the None. Optional
new trial subject will which the subject will participate. subject is continuing.
be entering

DRAFT 2008-04-03
4.8. Drug Accountability – DA (Findings)
The aim of the CDASH Drug Accountability proposal is to define the variables needed to assess drug accountability for clinical trial subjects. The Drug Accountability
variables may be used to calculate the subject’s compliance with the investigational product.
This proposal includes the Study Data Tabulation Model variables that appear in the SDTM Implementation Guide 3.1.1. DATEST values can be pre-specified on the
CRF if the data is collected in a horizontal format. SDTM states "1 record per drug accountability finding per subject". The combined use of SDTM variables
provides the ability to uniquely identify findings.
The inclusion of a Drug Accountability CRF/eCRF is optional. The team recommends that this data collection instrument is not used for single dose studies. The team
discussed various drug accountability scenarios for single dose studies. The team concluded that this standard would be of limited value for studies with a single dose.
The proposal for Drug Accountability does not include recommendations for devices. However, it is our understanding that the following information is typically
collected:
• Model number B
• Serial, Lot or Batch Number
• Receipt date
• Name of person receiving shipment
• Date used
• Subject ID
• Date returned to sponsor
• Reason for return to sponsor
• Date of disposal (if permitted)
• If disposed, method of disposal
• Person returning or disposing of method

DRAFT 2008-04-03
(CDASH variables
shaded)
1 Date Investigational DADTC Date the Investigational Product was Record the exact date the investigational The date investigational product dispensed Optional
Product Dispensed dispensed. product was dispensed, using the should be recorded for each dispensation
international date format. For more detail see for a study with multiple periods or
the Best Practice section. multiple products dispensed.
Variable DADTC is derived by putting the
CDASH Date Investigational Product
Dispensed into DADTC using the ISO
8601 format.
2 Investigational Product DAORRES Result of the Drug Accountability Record the actual amount of investigational For a study with multiple periods or Highly
Dispensed assessment as originally received or product dispensed. multiple products dispensed, drug Recommended
collected (e.g., actual amount). accountability should be assessed for each
dispensation. In this case, a sequence
DATEST Verbatim name, number or a group ID should be used to tie
corresponding to the topic variable, of together a block of related records and to
the test or examination used to obtain the link dispensed product to returned product.
drug accountability assessment (e.g., Note: DATEST must be used in concert
dispensed). with DAORRES and DAORRESU to
describe these distinct pieces of data.
3 Units of Investigational DAORRESU Unit for DAORRES (e.g., tablets). Record the units in which the investigational Unit of Product dispensed. (e.g., tablets). Highly
Product Dispensed product was dispensed. Recommended
The unit will need to be pre-printed on the
DATEST Verbatim name, corresponding to the CRF or a field provided on the CRF to
topic variable, of the test or examination capture it.
used to obtain the drug accountability
assessment (e.g., dispensed). Note: DATEST must be used in concert
with DAORRES and DAORRESU to

DRAFT 2008-04-03
(CDASH variables
shaded)
4 Date Investigational DADTC Date that the Investigational Product Record the exact date the investigational The date investigational product returned Optional
Product Returned was dispensed. product was returned, using the international should be recorded for each dispensation
date format. For more detail see the Best for a study with multiple periods or
Practice section. multiple products dispensed. If there is
only one drug which was dispensed on one
occasion, the collection of this data is not
applicable.
Variable DADTC is derived by putting the
CDASH Date Investigational Product
Returned into DADTC using the ISO 8601
format.
5 Investigational Product DAORRES Result of the Drug Accountability Record the actual amount of investigational Drug accountability should be assessed for Highly
Returned assessment as originally dispensed product returned. each dispensation for a study with multiple Recommended
(e.g., actual amount). periods or multiple products dispensed. A
sequence number or a group ID should be
DATEST Verbatim name, corresponding to the None. used to tie together a block of related
topic variable, of the test or examination records and to link returned product to
used to obtain the drug accountability product dispensed.
assessment (e.g., returned.). Note: DATEST must be used in concert
6 Units of Investigational DAORRESU Unit for DAORRES (e.g., tablets). Record the unit of investigational product Unit of Investigational Product returned Highly
Product Returned returned. (e.g., tablets). Recommended
DATEST Verbatim name, corresponding to the The unit will need to be pre-printed on the
topic variable, of the test or examination CRF or a field provided on the CRF to
used to obtain the drug accountability capture it
assessment (e.g., returned).
Note: DATEST must be used in concert
7 Investigational Product DACAT Used to define a categorization level for Record the type of investigational product None. Optional
Category a group of related records. dispensed/returned (e.g., Study Medication,
Comparator, Placebo).

DRAFT 2008-04-03
(CDASH variables
shaded)
8 Investigational Product DASCAT Used to define a further categorization Record the name of the investigational None. Optional
Sub-category level for a group of related records. product dispensed/returned (e.g., Drug A,
Drug B, Placebo).

DRAFT 2008-04-03
4.9. ECG Test Results – EG (Findings)
The ECG Team opted to not specify which ECG measurements should be collected as this is a medical and scientific decision that should be based on the needs of the
protocols.
The tables below are provided for three different scenarios.
Scenario 1: Central reading: In this scenario, results are captured directly by an electronic device and transmitted separately, or read by a central vendor – not
recorded on the CRF.
Scenario 2: Local reading: In this scenario, patient ECGs are performed and analyzed, and then the results are reported directly on the CRF
Scenario 3: Central reading (as in Scenario 1): But in addition, the CRF includes a site assessment of clinical significance
4.9.1. Scenario 1: Central reading: ECG results are captured directly by an electronic device and transmitted separately or read
centrally – not recorded on the CRF.
(CDASH variables
shaded)
1 ECG Status EGSTAT Status of whether or not ECG was done. Indicate whether or not ECG was done. This is intended to be used as a data Highly
management tool to verify that results Recommended
missing from the electronic transfer were
intentional.
2 Reason Not Done EGREASND Describes why the ECG was not done Record the reason that the ECG was not May be included if required by the Optional
(e.g., BROKEN EQUIPMENT, done. protocol. Examples of when this may be
SUBJECT REFUSED). necessary are cardiac studies or thorough
QT studies.
3 Date of ECG EGDTC Date of ECG. Record the date ECG occurred using the Key data collected. Especially important Highly
international date format. For more detail when multiple assessments are collected Recommended
see the Best Practice section. on more than one day.
A complete date is expected for ECGs that
occur during the study. May be collected For the SDTM dataset, the SDTM
elsewhere, such as a study visit date. Variable EGDTC is derived by
ECG (if time is collected) into EGDTC

DRAFT 2008-04-03
(CDASH variables
shaded)
4 Time of ECG EGTM Time of ECG. Record the time the ECG was done (as Especially important when multiple Recommended /
(Note: If collected, complete as possible). For more detail see assessments are done on one day. Conditional
will be derived into the Best Practice section.
EGDTC.) For the SDTM dataset, the SDTM
Variable EGDTC is derived by
5 Planned Time Point EGTPT Text description of planned time point Record the time point labels for when the Planned Time point would be needed to Recommended /
when measurements should be taken for ECG test should be taken, if not pre-printed differentiate for multiple sequential Conditional
use when multiple sequential on the CRF. assessments
assessments are done.
6 ECG Reference ID EGREFID Internal or external identifier. Record the identifier number assigned. This can be used to confirm that the Optional
appropriate data record is present in the
electronic transfer (e.g., UUID for external
waveform file).
7 Protocol-defined EGPOS, Condition for testing defined in the Record whether protocol defined conditions Results may be affected by whether Optional
testing conditions met EGMETHOD (for protocol. were met. conditions for ECG were properly met.
example)
Example:
-Subject position during ECG (e.g.,
supine, standing, sitting)
-ECG Method (e.g., 12-Lead or 1-Lead)
If the protocol requires this type of
information, then these questions may be
included to confirm that the condition for
testing as defined by the protocol were
met.

DRAFT 2008-04-03
4.9.2. Scenario 2: Local reading: ECGs are performed and analyzed and results are reported directly on the CRF
(CDASH variables
shaded)
1 ECG Status EGSTAT Status of whether or not ECG was done. Indicate whether or not ECG was done. This may be implemented for an entire Highly
ECG, or on a test-by-test basis. This is Recommended
intended to be used as a data
management tool to verify that missing
results are intentionally missing.
QT studies.
international date format. For more detail see when multiple assessments are collected Recommended
the Best Practice section. on more than one day.
concatenating CDASH Start Date and
Time (if time is collected) into EGDTC
when measurements should be taken ECG test should be taken, if not pre-printed differentiate for multiple sequential Conditional
for use when multiple sequential on the CRF assessments
assessments are done

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Test Name EGTESTCD Verbatim name of the test or Record the wording of the ECG test, if not Required to identify the result. May be Highly
examination used to obtain the pre-printed on the CRF. preprinted. Recommended
And/or measurement or finding.
EGTEST
7 Test Result EGORRES Result of the measurement or finding as Record test results. Key data collected. Highly
originally received or collected. Recommended
8 Units EGORRESU Original units in which the data were (If units are not pre-printed on the CRFs) May be included if quantitative results Recommended /
collected. are recorded. Because units for Conditional
Record the original units in which this data quantitative ECG results are limited to
were collected. seconds or milliseconds, units should be
pre-printed on the CRF rather than
having the sites record the units.
9 Clinical Significance EGCLSG Whether ECG results were clinically Record whether ECG results were clinically May be included if required by the Optional
(Note: If collected significant. significant. protocol.
will be mapped to
SUPPQUAL
domain.)
10 Protocol-defined EGPOS, Condition for testing defined in the Record whether protocol defined conditions Results may be affected by whether Optional
testing conditions met EGMETHOD (for protocol. were met. conditions for ECG were properly met.
example)
Example:
met.

DRAFT 2008-04-03
(CDASH variables
shaded)
11 Evaluator EGEVAL Role of the person who provided the Record the role of the person evaluating the May be included if required by the Optional
evaluation. This should only be used results. protocol.
for results that are subjective (e.g.,
assigned by a person or a group) and
do not apply to quantitative results (i.e.
ADJUDICATION COMMITTEE,
INVESTIGATOR).
12 ECG Reference ID EGREFID Internal or external identifier. Record the identifier number assigned. This can be used to confirm that the Optional
appropriate data record is present in the
electronic transfer (e.g., UUID for
external waveform file).

DRAFT 2008-04-03
4.9.3. Scenario 3: Central Reading (as in Scenario 1) But in addition, the CRF includes site assessment of clinical significance
(CDASH variables
shaded)
1 ECG Status EGSTAT Status of whether or not ECG was done. Indicate whether or not ECG was done. This may be implemented for an entire Highly
ECG, or on a test-by-test basis. This is Recommended
intended to be used as a data management
tool to verify results provided.
QT studies.
international date format. For more detail when multiple assessments are collected Recommended
see the Best Practice section. on more than one day.
when measurements should be taken for ECG test should be taken, if not pre-printed differentiate for multiple sequential Conditional
use when multiple sequential on the CRF. assessments
assessments are done.

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Test Name EGTEST Verbatim name of the test or Record the description of the ECG result, if Required to identify the test. May be Highly
examination used to obtain the not pre-printed on the CRF. preprinted. Recommended
measurement or finding.
7 Units EGORRESU Original units in which the data were (If units are not pre-printed on the CRFs) May be included if quantitative results are Recommended /
collected. recorded. Because units for quantitative Conditional
Record the original units in which this data ECG results are limited to seconds or
were collected. milliseconds, units should be pre-printed
on the CRF rather than having the sites
record the units.
8 Clinical Significance EGCLSG Whether ECG results were clinically Record whether ECG results were clinically Key data collected in this scenario. Highly
(Note: If collected, significant. significant. Recommended
will be mapped to
SUPPQUAL
domain.)
9 Test Result EGORRES Result of the measurement or finding as Record test results. Optional if already provided from central Recommended /
originally received or collected. ECG data. Conditional
10 Units EGORRESU Original units in which the data were (If units are not pre-printed on the CRFs) May be included if quantitative results are Recommended /
collected. recorded. Because units for quantitative Conditional
Record the original units in which this data ECG results are limited to seconds or
were collected. milliseconds, units should be pre-printed
on the CRF rather than having the sites
record the units.
11 Vendor Name EGNAM Name of vendor providing ECG data. Record the vendor name. May be included on CRF if not Recommended /
standardized by clinical trial site. Conditional
This information may be used for
reconciliation purposes.

DRAFT 2008-04-03
(CDASH variables
shaded)
12 Protocol-defined EGPOS, Conditions for testing defined in the Record whether protocol defined testing Results may be affected by whether Optional
testing conditions met EGMETHOD (for protocol. conditions were met. conditions for ECG were properly met.
example)
Example:
met.
13 ECG Reference ID EGREFID Internal or external ECG identifier. Record the ECG Reference ID assigned. May be included for linking back to Optional
external data file.

DRAFT 2008-04-03
4.10. Exposure – EX (Interventions)
This proposal includes the Study Data Tabulation Model variables that appear in the SDTM Implementation Guide 3.1.1. The SDTM implementation Guide defines
the Exposure domain model as follows.
“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 medications (CM) domain.”
The dose variables in this proposal refer to the collection of the ‘actual dose’ rather than the ‘planned dose’.
(CDASH variables
shaded)
1 Start Date EXSTDTC Start date of treatment. Record the exact date of the investigational Date when investigational product Highly
product administration using the international ‘constant dosing interval’ started. Recommended
date format. For more detail see the Best
Practice section. For the SDTM dataset, the SDTM
Variable EXSTDTC is derived by
Time of treatment (if time is collected)
into EXSTDTC using the ISO 8601
format.
2 Start Time EXSTTM Start time of treatment. Record the time (as complete as possible) Time when investigational product period Optional
(Note: If collected, when administration of investigational started.
will be derived into product started. For more detail see the Best
EXSTDTC.) Practice section. For the SDTM dataset, the SDTM
Variable EXSTDTC is derived by
into EXSTDTC using the ISO 8601
format.

DRAFT 2008-04-03
(CDASH variables
shaded)
3 Stop Date EXENDTC End date of treatment. Record the stop date or last date of Date when investigational product period Recommended /
administration of investigational product stopped. Conditional
using the international date format. For more
detail see the Best Practice section. If start date and stop date are not expected
to be on the same date, the stop date is
required. If the trial design indicates that
the start and stop date are on the same
day, the stop date is not required since it
can be assigned to be equal to the start
date.
Variable EXENDTC is derived by
concatenating CDASH Stop Date and
into EXENDTC using the ISO 8601
format.
4 Stop Time EXENTM End time of treatment. Record the time, (as complete as possible) Time when investigational product Optional
(Note: If collected, when investigational product administration ‘constant dosing interval’ ended/stopped.
will be derived into stopped (e.g., for infusions this is the time
EXENDTC.) when the infusion ended). For the SDTM dataset, the SDTM
Variable EXENDTC is derived by
For more detail see the Best Practice section. concatenating CDASH Stop Date and
into EXENDTC using the ISO 8601
format.
5 Dose Amount EXDOSE Dose per Administration. Record the dose or amount of investigational Dose or amount taken per ‘constant Recommended /
product that was administered to/taken by the dosing interval’ recorded. Conditional
subject in the period recorded. Capture of dose is conditional because it
may be possible to obtain dose by other
methods (e.g., derived from
randomization data).

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Dose Unit EXDOSU Units for EXDOSE Record the unit of dose or amount taken per Unit of dose or amount taken per Recommended /
period recorded (e.g., ng, mg, or mg/kg). ‘constant dosing interval’ recorded. Conditional
Capture of dose unit is conditional
because it may be possible to obtain dose
by other methods (e.g., derived from
randomization data).
The unit will need to be pre-printed on the
CRF or a field provided on the CRF to
capture it.
7 Investigational EXLOT EXLOT = Lot Number of the EXTRT Record the reference number that appears on Reference number that appears on the Optional
Product Identification product. the container holding the investigational container holding the investigational
Number Or product (e.g., Lot Number). product.
EXSPID EXSPID = Sponsor defined reference Investigational Product Identification
number. Perhaps pre-printed on the Number is a unique number, which
(Note: Either can CRF as an explicit line identifier or
store investigational defined in the sponsor’s operational provides mapping to Lot Number and
product possibly the randomization schema.
database.
identification
number)
8 Investigational EXTRT Name of the intervention treatment — Record the name of investigational product. Name of investigational product that was Optional
Product Name usually the verbatim name of the administered to the subject.
investigational treatment given during
the ‘constant dosing interval’ for the This must be collected if it cannot be
observation. derived.
Variable must always be present in the
underlying database.
9 Dose Adjusted? EXDOSADJ Confirmation of dose adjustment. Select either “Yes” or “No” to indicate Will provide a definitive response Optional
Yes/No (Note: If collected, whether there was a change in dosing. regarding dose changes.
will be mapped to
SUPPQUAL
domain.)

DRAFT 2008-04-03
(CDASH variables
shaded)
10 Reason for Dose EXADJ Describes reason or explanation of why If there was a change in dosing, record the Captures reason dose was changed / Optional
Adjustment a dose is adjusted – used only when an reason for change. modified. The reason may be chosen
adjustment is represented in from a select list or entered as free text.
EXPOSURE. May be used for
variations from protocol-specified doses,
or changes from expected doses.
11 Frequency EXDOSFRQ Usually expressed as the number of Record the frequency the investigational Number of doses given per a specific Optional
dosings given per a specific interval. product was administered for a defined interval.
period of time (e.g., BID, QID, TID).
12 Route EXROUTE Route of administration for EXTRT. Record the route of administration (e.g., IV, Route of investigational product Optional
oral or transdermal) or enter the appropriate administration.
code from the code list.
This will often be pre-printed on the CRF.
If it is not pre-printed, a field will need to
be provided on the CRF.
13 Formulation EXDOSFRM Dose form for EXTRT. Record the formulation (e.g., infusion, Formulation of investigational product. Optional
solution, tablet, lotion) or enter the
appropriate code from the code list. This must be collected if it can not be
derived.
Variable must always be present in the
underlying database.
14 Duration of DURINTP Duration of the treatment interruption. Record the duration of treatment interruption. Duration of treatment interruption. Optional
Interruption (Note: If collected,
(including units) will be mapped to In some situations, the duration of the
SUPPQUAL interruption may be calculated from the
domain.) administration start and stop times
recorded elsewhere in the CRF.
DURINTPU Unit for the duration of treatment Record the unit (e.g., minutes, hours, days) The unit (e.g., minutes, hours, days) needs Optional
interruption. for the duration of treatment interruption. to be collected as a qualifier to the number
for duration.

DRAFT 2008-04-03
(CDASH variables
shaded)
15 Body Location EXLOC Specifies anatomical location of Record the body location where the Location where the investigational Optional
administration. investigational product was administered product was administered.
(e.g., shoulder, hip, arm).
This may be pre-printed or collected.
16 Total Volume Infused EXVAMT Exposure volume amount. Record the total volume that was Infusion volume that was given to the Optional
(Note: If collected, administered/given to the subject. subject.
will be mapped to
SUPPQUAL
domain.)
17 Total Volume Infused EXVAMTU The unit of measure for the exposure Record the unit of total volume administered/ Unit of the infusion volume (e.g., mL). Optional
Unit (Note: If collected, volume amount. given to the subject (e.g., mL).
will be mapped to
SUPPQUAL
domain.)
18 Flow Rate EXFLRT Rate of infusion. Record the Rate of Infusion (e.g., 10 mL/min. Infusion rate can be used to derive dose. Optional
(Note: If collected, Record “10”as the infusion rate).
will be mapped to
SUPPQUAL
domain.)
18 Flow Rate Unit EXFLRTU The unit of measure for the flow rate. Record the unit for the infusion rate (e.g., Unit of the infusion rate (e.g., mL/min). Optional
(Note: If collected, mL/min).
will be mapped to
SUPPQUAL
domain.)
19 Planned Time Point EXTPT Planned time point name. Record the planned time point of Indicates the planned time point of Optional
investigational product administration (e.g., investigational product administration.
mornings, evening). (e.g., morning, evening).
20 Did subject complete EXMEDCMP Confirmation point for exposure. Select either “Yes” or “No” to indicate Depending on how the investigational Optional
full course of study (Note: If collected, whether subject has completed the full course product details are collected via the CRF/
med? will be mapped to of treatment. eCRF, it may be possible to derive this
SUPPQUAL data.
domain.)

DRAFT 2008-04-03
4.11. Inclusion / Exclusion – IE (Findings)
4.11.1. Adaptive Trial Design
The IE Team considered the potential for entry criteria to change over the life of a study or project, for example when adaptive trial design is used, and the
recommended approach is designed to more efficiently accommodate changing criteria as the study progresses. CDASH recommends the use of uniquely numbered
entry criteria within a submission to effectively manage protocol changes, and to facilitate both the collection and submission of IE data.
4.11.2. Collecting IE Data and Mapping to the SDTM
The IE Team noted that some of the CRF variables collected may have either a one-to-one mapping to SDTM variables, or a many-to-one mapping depending on a
particular Sponsor company’s data collection method. The IE CRF standard recommended in this document is flexible enough to allow a variety of data collection
methods that will all map to a single SDTM standard.
Since the SDTM variables served as the target for collected data, the IE Team referred to the current version of the CDISC SDTM Implementation Guide, and
incorporated the assumptions regarding the IE Domain from that Guide into the development of this data collection standard.
The first SDTM IG assumption is that the intent of the IE domain model is to only submit those criteria that cause the subject to be in violation of the
Inclusion/Exclusion criteria, not to submit a response to each criterion for each subject. The IE Team recommends that the site be given an entry criteria worksheet to
be used for each subject during screening. This worksheet should be considered a source document, used in monitoring activities, and maintained with the subject’s
site files. The worksheet should identify each entry criterion using a unique identifier which can be easily recorded on the CRF if a subject does not meet that criterion.
The second assumption is that the IE domain is intended to collect only eligibility information for the inclusion and exclusion criteria for entry into a study; not protocol
deviations or violations incurred during the course of the study. Any of the CRF fields that were reviewed by the IE Team and determined to be related to protocol
deviations or violations were deferred to the Protocol Deviation (DV) Team for consideration.
The last assumption that was used in the development of this standard was that enough data needs to be collected to satisfy safety concerns and regulatory requirements,
and to populate or derive the required SDTM submission variables. Thus all SDTM variables that are required for submission are either explicitly collected in the CRF,
or may be derived (e.g., IEORRES, IESTRESC) from the data collected using the Required and Expected CDASH variables presented in the table. Specific
recommendations for the collection and derivation of data are described in the Implementation / Rationale to Sponsors column in the table.

DRAFT 2008-04-03
(CDASH variables
shaded)
1 Met Eligibility IEYN Response for whether the subject met Yes/No: Record “yes” if all eligibility This is intended to be used primarily as a Highly
all the eligibility requirements for this criteria were met for the study. Record “No” monitoring and/or data management Recommended
study. if subject did not meet all criteria. If “No”, tool to verify that the investigator/site
enter the identifying code for each criterion reported any entry criteria that were not
not met. met.
Checkbox: Check here if the subject met all May be a “yes/no” question, or may be a
eligibility requirements for the study. checkbox.
May be used to derive data into

IEORRES.
Must be recorded on the CRF.
2 Criterion Identifier5 IETESTCD The identifier associated with the Record this only for the criterion / criteria This field is required to appear on the Highly
criterion that the subject did not meet. that this subject did not meet7. CRF, but may be null if all criteria are Recommended
This must be a unique identifier that met.
corresponds to a specific entry Paper: Record the criterion identifier from
criterion6. the list of inclusion/ exclusion criteria Multiple responses should be allowed on
provided by the Sponsor. CRF.
EDC: Select the criterion from the pick-list. CDASH recommends that the Sponsor
determine how many lines are needed
on the CRF based on their experience
and maximum allowed. This would
probably be only 2 or 3 for most studies.
Note: Consider modifying the criteria
rather than allowing subjects in who do
not meet the criteria.
5
This variable is only populated in SDTM for those criteria that are not met, and it will only be recorded on the CRF for those criteria that are not met. Note: The IE Team considered
the possibility of some organizations using criteria lists without unique identifiers (i.e. bulleted lists). After the Collaborative Group review of the IE standards, and on the
recommendation of the FDA reviewers, the Team decided to remove the alternative approach that was in the Harmonized Version of this document and present a single standard for IE
data collection. FDA reviewers recommended that organizations that currently use bulleted lists should move toward using unique identifiers for entry criteria.
6
If inclusion and exclusion criteria lists are independently numbered (e.g., inclusion 001-100, exclusion 001-100), then this identifier must include a means of identifying the TYPE of
criterion (e.g., I001-I100, E001-E100). The examples provided are only examples; your organization’s numbering scheme may be different.
7
This identifier may be used to derive values into IETEST and IECAT from a protocol definition or other source external to the clinical database, and into IEORRES.
DRAFT 2008-04-03
(CDASH variables
shaded)
3 Criterion IETEST The wording of an inclusion or EDC: Verify the wording of this criterion. The primary use would be in EDC. This Optional
exclusion criterion. field would be populated when the
Criterion Identifier is populated, and could
be verified by the PI.
Paper: The monitoring process should
include a cross-verification of entry
criteria against the medical records for
each subject.
4 Inclusion or IECAT Specifies whether the criterion is Record whether the criterion that this subject IECAT must be populated in SDTM Optional
Exclusion? inclusion or exclusion. did not meet was “Inclusion” or “Exclusion”. (only) for those criteria that are not met,
but does not necessarily have to be
collected on the CRF.
This category may be collected on the
CRF, or, it may be included as part of the
Criterion Identifier (e.g., I01, E01), or
derived from the Trial Inclusion (TI) trial
inclusion/exclusion criteria dataset, or
other protocol definitions external to the
clinical database when a unique criterion
identifier is recorded in the IETESTCD
variable.

DRAFT 2008-04-03
4.12. Laboratory Test Results – LB (Findings)
The tables below are provided for three different scenarios.
Scenario 1: Central processing: In this scenario, patient samples are taken at site, sent out for processing and results are provided directly to the sponsor. This
scenario also applies when results are captured directly via an electronic device – not recorded on the CRF.
Scenario 2: Local processing: In this scenario, patient samples are taken and analyzed, and then the results are reported directly on the CRF
Scenario 3: Central processing with Clinical Significance Assessment for abnormal values: In this scenario, patient samples are taken at site, sent out for
processing and results are provided directly to the sponsor and also to the investigator for assessment of clinical significance for any abnormal values to
be recorded on CRF. This scenario also applies when results are captured directly via an electronic device – not recorded on the CRF.
4.12.1. Scenario 1: Central processing: Where samples are taken at site, but sent out and results are provided separately or
where results are captured directly by an electronic device and transmitted separately – not recorded on the CRF. Lab
Data Collection Variables (CRF data captured at the site for tracking/ header reconciliation. The variables for test results
are not defined here, as this data is not part of the CRF).
(CDASH variables
shaded)
1 Date of Collection LBDTC Date of sample collection. Record the date when sample collection The date of collection may be derived Highly
occurred using the international date format. from the date of visit and if so, a separate Recommended
assessment date field is not required.
For more detail see the Best Practice section.
Variable LBDTC is derived by
LBDTC using the ISO 8601 format.

DRAFT 2008-04-03
(CDASH variables
shaded)
2 Time of Collection LBTM Time of collection. Record time of collection (as complete as Especially important when multiple Recommended/
(Note: If collected, possible). assessments are done on one day. Conditional
will be derived into
LBDTC.) For more detail see the Best Practice section.
3 Lab Status LBSTAT Status of whether or not lab was done. Indicate whether or not lab was done. This may be implemented for an entire Highly
panel, or on a test-by-test basis. This is Recommended
4 Panel Name LBCAT Type of draw / category / panel name. Record the lab test category, if not pre- To be included if "Not Done's" are Recommended/
Used to define a category of related printed on the CRF. collected for each panel (e.g., Conditional
LBSCAT records. HEMATOLOGY, URINALYSIS,
CHEMISTRY).
5 Planned Time Point LBTPT Relative time for use when multiple Record the planned time point labels for the Planned Time point would be needed to Recommended/
sequential assessments are done. lab test, if not pre-printed on the CRF. differentiate for multiple sequential Conditional
assessments.
6 Protocol-defined LBFAST (for Conditions for sampling defined in the The specific testing conditions required Results may be affected by whether Recommended/
testing conditions met example) protocol. should be pre-printed on the CRF, such as conditions for sample were properly met Conditional
“Did patient meet fasting requirements?”. (e.g., fasting).
Record whether protocol defined testing
conditions were met.
7 Accession Number LBREFID Internal or external specimen identifier. Record the sample or accession number (e.g., Specimen ID) Recommended/
assigned. Conditional

DRAFT 2008-04-03
4.12.2. Scenario 2: Local processing: When results of sample analysis are reported directly on the CRF
(CDASH variables
shaded)
LBDTC.) For more detail see the Best Practice section.
intended to be used as a data
management tool to verify results
provided.
4 Panel Name LBCAT Type of draw / category / panel name. Record the lab test category, if not pre- Included as needed for clarity (e.g., Recommended/
Used to define a category of related printed on the CRF. HEMATOLOGY, URINALYSIS, Conditional
LBSCAT records. CHEMISTRY).
sequential assessments are done. lab test, if not pre-printed on the CRF. differentiate for multiple sequential Conditional
assessments.

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Protocol-defined LBFAST (for Conditions for sampling defined in the Record whether protocol defined testing Results may be affected by whether Recommended/
testing conditions example) protocol. conditions were met. conditions for sample were properly met Conditional
met (e.g., fasting).
7 Sample Status LBSPCCND Free or standardized text describing the Record condition of sample. (e.g., HEMOLYZED, ICTERIC, Recommended/
condition of the specimen. LIPEMIC) Conditional
8 Test Name LBTESTCD Verbatim name of the test or Record the wording of the lab test, if not Required to identify the test. It is Highly
examination used to obtain the pre-printed on the CRF. recommended that the test names be pre- Recommended
And/or measurement or finding. Note any test
printed on the CRF.
LBTEST normally performed by a clinical
laboratory is considered a lab test.
9 Test Result LBORRES Result of the measurement or finding Record test results. Key data collected. Highly
as originally received or collected. Recommended
10 Units LBORRESU Original units in which the data were Record the units of the lab test, if not pre- May be included if not standardized. Highly
collected. printed on the CRF or captured in an Recommended
external ‘lab normal’ file.
11 Normal Range LBORNRLO Normal range for continuous Record the normal range of the lab test. LBORNRLO and LBORNRHI should be Recommended/
measurements in original units. populated only for continuous results; Conditional
LBORNRHI LBSTNRC should be populated only for
Normal values for non-continuous non-continuous results. This data may be
LBSTNRC measurements in original units. obtained from the central lab or the
electronic equipment.
Not required when lab data is not
recorded on CRF.
12 Abnormal Flag LBNRIND Reference Range Indicator Indicates Record whether sample was within range. May be included if not derived. Recommended/
where value falls with respect to Conditional
reference range defined by high and
low ranges.

DRAFT 2008-04-03
(CDASH variables
shaded)
13 Clinical Significance LBCLSG Whether lab test results were clinically Record whether lab results were clinically May be included if required by the Recommended/
(Note: If collected significant. significant. protocol. Conditional
will be mapped to
SUPPQUAL
domain.)
14 Lab Name LBNAM Name of lab analyzing sample. Record the laboratory name. May be included on CRF if not Recommended/
15 Accession Number LBREFID Internal or external specimen Record the sample or accession number May be included for linking back to Recommended/
identifier. assigned. samples (e.g., Specimen ID). Conditional

DRAFT 2008-04-03
4.12.3. Scenario 3: Central processing but CRF includes site assessment of clinical significance. In this scenario, data is sent for
central processing. Results are returned to the sites, and the sites complete a CRF page of clinical significance for any
abnormal / unexpected values. The actual testing results are transmitted electronically, as in scenario 1, but the CRF
includes the data necessary to identify and rate the clinical significance of the abnormal results.
(CDASH variables
shaded)
LBDTC.) For the SDTM dataset, the SDTM
4 Panel Name LBCAT Type of draw / category / panel name. Record the lab test category, if not pre-printed Optional if already provided from central Recommended/
Used to define a category of related on the CRF. lab (e.g., HEMATOLOGY, URINALYSIS, Conditional
LBSCAT records. CHEMISTRY).
sequential assessments are done, lab test, if not pre-printed on the CRF. differentiate for multiple sequential Conditional
assessments.

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Protocol-defined LBFAST (for Conditions for sampling defined in the Record whether protocol defined testing Results may be affected by whether Recommended/
testing conditions met example) protocol. conditions were met. conditions for sample were properly met Conditional
(e.g., fasting).
7 Test Name LBTEST Verbatim name of the test or Record the wording of the lab test if not pre- Required to identify the test. It is Highly
examination used to obtain the printed on the CRF. recommended that the test names be pre- Recommended
measurement or finding. Note: any test printed on the CRF.
normally performed by a clinical
laboratory is considered a lab test.
8 Test Result LBORRES Result of the measurement or finding as Record test results. Optional if already provided from central Recommended/
originally received or collected. lab. Conditional
9 Clinical Significance LBCLSG Whether lab test results were clinically Record whether lab results were clinically Key data collected in this scenario. Highly
(Note: If collected significant. significant. Recommended
will be mapped to
SUPPQUAL
domain.)
10 Lab Name LBNAM Name of lab analyzing sample. Record the laboratory name. May be included on CRF if not Recommended/
11 Accession Number LBREFID Internal or external specimen identifier. Record the sample or accession number May be included for linking back to Recommended/
assigned. samples (e.g., Specimen ID). Conditional

DRAFT 2008-04-03
4.13. Medical History – MH (Events)
For the purposes of this effort, only General Medical History was considered. Indication specific History such as Oncology though not expressly addressed, were
considered in the definitions of such variables as MHCAT. The rationale for addressing only General Medical History was that a higher degree of detail may be
required for the indication specific histories. It may well be possible to record indication specific history on these forms if the protocol does not require more
information than are addressed by the optional variables.
Example CRFs and Regulatory requirements for the recording and coding of Medical History were reviewed. Though varied, it was determined that not only relevant
Medical History, but additionally the disease under study may be recorded as General Medical History. Dependent upon protocol requirements, an exhaustive list of
conditions is not required, but rather focus should be on particular diseases or conditions of concern.
The Regulatory requirements affecting the coding of Medical History were also reviewed. Coding using MedDRA, though not required by the FDA, is recommended,
therefore no specific recommendation on what to code is being made. A strategy for classifying/organizing uncoded Medical History utilizing conditional variables is
being recommended. For un-coded Medical History, a sponsor defined categorization of Medical History Events will be required. This categorization will be achieved
using the MHSCAT variable. Sponsors who code Medical History will use the dictionary variables for the coded terms.
(CDASH variables
shaded)
1 Reported Term MHTERM Verbatim or preprinted CRF term for Record all past (or relevant) and / or Note that if Sponsors need to capture Highly
the medical condition or event. concomitant medical conditions and past more detailed surgery information (e.g., Recommended
surgeries. Record only one condition or VNS implantation for Epilepsy trials), an
surgery per line. When recording a additional CRF module should be used,
condition and surgery related to that modeled as an Interventions domain.
condition, use one line for the condition and
one line for the surgery. Ensure that any of
the conditions listed on the Medical History
page do not meet any of the exclusion
criteria.
2 Ongoing / Resolved MHONG Identifies the end of the event as being Select the most appropriate response. Note that MHONG is not defined in the Highly
ONGOING or RESOLVED. SDTM MH domain. If collected, it Recommended
should be used to derive to MHENRF.
The visit date or completion date
recorded in the CRF header, should be
used as a reference point.

DRAFT 2008-04-03
(CDASH variables
shaded)
3 Medical History Flag MHYN Lead prompt for the Medical History If the subject has experienced any past and / Note: MHYN is not defined in the SDTM Optional
(e.g., “Has the subject experienced any or concomitant diseases or has had any type MH domain. Some sponsors may find
past and / or concomitant diseases or of surgery, select Yes and provide the this data point useful from an
past surgeries?”). requested information. Otherwise, select No administrative perspective. It should not
and leave the page blank. be included in the submission.
4 Pre-printed row MHSPID Optional sponsor-defined reference Not applicable. Some sponsors may pre-number the rows Optional
number (e.g., 1, 2, 3) number (e.g., Preprinted line number). used to capture the data. If these
identifiers are submitted, MHSPID
should be used.
5 Type of Medical MHCAT Used to define a category of related Not applicable. The sponsor may or may not pre-print on Optional
History being records (e.g., CARDIAC or the CRF the type of medical history being
Collected GENERAL). captured. If specific medical history (e.g.,
disease diagnosis) is captured in addition
to the general medical history, it may be
helpful to pre-print the history type on the
CRF. Regardless, MHCAT may be
populated in the database.
Note: MHCAT must be in the database if
MHSCAT is used.

DRAFT 2008-04-03
(CDASH variables
shaded)
6 Category of Medical MHSCAT A categorization of the condition or Note: the CRF instructions will depend The pre-printed groupings should be used Optional
History being event pre-printed on the CRF or upon the format of the CRF. Some sponsors if the sponsor will not code medical
Collected instructions. ask the sites to use a numeric code (e.g., history. The categories should be
“123”) to designate a particular category sponsor-defined as sponsors may have
(e.g., “cardiovascular”) while other different needs. (Code “123” used in the
sponsors will simply pre-print the instructions is simply an example.) The
categories on the CRF and provide space MedDRA SOCs should not be used as
for the site to record the ailment, disease or categories on the CRF for several
surgery. reasons. Sites are probably not familiar
with the SOCs. It would be cumbersome
Instruction examples: to include the 26 organ classes on the
Use the (sponsor-defined) code list to group CRF, entry screen or completion
the past and / or concomitant medical instructions. The reviewers expect this
conditions or surgeries. For example, if the information to be stored in MHBODSYS.
subject has a history of high blood pressure, Finally, the sponsor may only wish to
use code “123” for “cardiovascular”. inquire about particular groupings or
specific diseases; not actual body systems.
Or
Note that “123” would not be stored in
Record the concomitant medical conditions MHSCAT. In this example,
or past surgeries under the appropriate “cardiovascular” is the MHSCAT.
category. For example, “high blood Numeric codes used on the CRF as an
pressure” should be recorded under operational tactic to facilitate data entry
“cardiovascular”. must be removed prior to submission as
they provide no meaning to the reviewer.
Also Note that MHCAT must be in the
database if MHSCAT is used.
7 Pre-printed prompt MHOCCUR A pre-printed prompt used to indicate Please indicate if “xyz” has occurred by MHOCCUR should only be used if the Optional
for a specific whether or not a medical condition has ticking “Yes” or “No”. condition pre-printed on the CRF elicits a
condition/surgery occurred. Yes or No response. MHOCCUR should
(e.g., Does the not be used if the conditions are collected
subject have high on the CRF in a manner that requires a
blood pressure?) free-flow text response.

DRAFT 2008-04-03
(CDASH variables
shaded)
8 Onset Date MHSTDTC Start Date of Medical History Event. Record the onset date using the international The sponsor may choose to capture a Optional
date format. For more detail see the Best complete date, or any variation thereof
Practice section. (month & year or year, etc.).
Variable MHSTDTC is derived by
concatenating CDASH Onset Date and
Time (if time is collected) into
MHSTDTC using the ISO 8601 format.
9 End Date MHENDTC End Date/Time of Medical History Record the end/resolution date. The sponsor may choose to capture a Optional
Event. complete date, or any variation thereof
(month & year or year, etc.).

DRAFT 2008-04-03
4.14. Physical Examination – PE (Findings)
The scope of the physical examination data collection tables is limited to general physical examinations as part of overall safety data collection. The data collection
fields defined in the following tables may not fit the needs of targeted body system evaluations as part of therapeutic area specific assessments. After reviewing the
different Physical Examination (PE) forms, the team organized them into 3 usage categories:
a. Use of a PE form at baseline and post baseline visits.
b. Use of a PE form at baseline, but not at post baseline visits. Sites are instructed to record any post baseline abnormalities or baseline conditions that worsened post
baseline on the Adverse Event (AE) form.
c. Use of a PE form only to record whether or not the exam was performed, and if so, the date of the examination. Sites are instructed to record baseline
abnormalities on medical history form, targeted medical history form (e.g. study specific form requesting assessment of a pre-defined set of medical and/or surgical
history events) or baseline conditions form. Sites are instructed to record any post baseline abnormalities or baseline conditions that worsened post baseline on the
Adverse Event (AE) form or other sponsor defined form.
In options a and b, similar variables were captured; date of exam, body system/code, normal/abnormal, and description of abnormality. As the team discussed the
options, factors supporting option c began to outweigh the traditional methods incorporated in options a and b. The primary factors leading to recommending option c
as the best practice include:
• Eliminates collection and reconciliation of duplicate data by capturing abnormal data in one central location. Abnormalities identified during a physical
examination must also be recorded on an AE form, a medical history form, or other similar form.
• Reduces number of queries, thus reducing workload for data managers and site personnel.
• Supports consistency/standardization for data reporting purposes. Team members polled their medical writing and biostatistics departments and it was found that
physical examination data is rarely summarized, only tabulated in listing format. Any trend analysis or summarization of abnormalities is performed on AE data,
and medical history data is available for reference.
• Reduces coding needs (if PE abnormalities are coded)
As option c represents a radical change from the more traditional approach for collection of physical examination data, two sets of variable definition tables
are being presented. The table/approach outlined in section 16.1 is being proposed by the team as an alternative to the traditional approach and
recommended as best practice. The table presented in section 16.3 reflects the traditional approach to physical examination data collection.

DRAFT 2008-04-03
4.14.1. Best Practice Approach

CDASH CRF Label/ Clinical Database Definition Instructions to Clinical Site Implementation / CDASH Core
(CDASH variables
shaded)
1 Overall Examination PESTAT Used to indicate if exam was not done If physical examination was not performed as BASELINE: If examination is performed, Optional
Status as scheduled. planned then select ‘Not Done’, otherwise no CRF and CRF Instructions will direct site
action is needed. to report all abnormal findings/conditions
on appropriate CRF (e.g., Medical History,
Baseline Findings, Adverse Events)
POST-BASELINE: If examination is
performed and abnormality is new or
worsened, CRF and CRF Instructions will
direct site to capture all changes on
appropriate CRF (e.g., Post-baseline
Assessment, Adverse Events).
2 Date of Examination PEDTC Date of examination. Record complete date of examination, day, The date of examination may be derived Optional
month and year using the international date from the date of visit and therefore a
format. For more detail see the Best Practice separate assessment date field is not
section. required.
Variable PEDTC is derived by
Examination (if time is collected) into
PEDTC using the ISO 8601 format.
3 Time of Examination PETM Time of examination. Record the time of examination (as complete For the SDTM dataset, the SDTM Optional
(Note: If collected, as possible). For more detail see the Best Variable PEDTC is derived by
PEDTC.) Examination (if time is collected) into
As specified via each study’s protocol, physical exams will be given to a subject based on protocol schedule. At the time of the exam, we propose to use the PE CRF
page to collect only the status of whether or not the exam was done and, if done, the date (and time, if collected) of the exam. Sites should be prompted to record any
abnormalities identified during the exam on appropriate CRF pages. For baseline visits, sites will be directed to report abnormal findings/conditions on a CRF such as
Baseline Assessment, Medical History or Adverse Event. For post-baseline visits, sites may be directed to use a CRF such as Post-Baseline Assessment or Adverse
Event.

DRAFT 2008-04-03
4.14.2. Traditional Approach
(CDASH variables
shaded)
1 Overall Examination PEDONE Used to indicate if exam was not done If physical examination was not performed as A subject/page level question can be used Optional
Status as scheduled. planned then select ‘Not Done’, otherwise no asking the site if the physical exam was
action is needed. performed at the specified time point.
If this field is used then the result should
only be mapped to PESTAT if the overall
examination, at the subject level, was not
performed. If the examination was
performed then the value PESTAT would
be null for the examined body systems and
Not Done for any body systems not
examined.
2 Date of Examination PEDTC Date of examination. Record complete date of examination, day, The date of examination may be derived Recommended/
month and year using the international date from the date of visit and therefore a Conditional
format. For more detail see the Best Practice separate assessment date field is not
section. required.
Variable PEDTC is derived by
Examination (if time is collected) into
3 Time of Examination PETM Time of examination. Record the time of examination (as complete For the SDTM dataset, the SDTM Optional
(Note: If collected, as possible).For more detail see the Best Variable PEDTC is derived by
PEDTC.) Examination (if time is collected) into
4 Sponsor Defined PESPID Sponsor defined reference number. None. May be pre-printed on the CRF as an Optional
Identifier explicit line identifier or defined in the
sponsor’s operational database.

DRAFT 2008-04-03
(CDASH variables
shaded)
5 Body System PETEST Verbatim term for the body system. Per protocol, perform physical examinations Sponsor should pre-populate CRF with all Highly
Examined of specified body systems. body systems to be examined. The use of Recommended
a complete list of body systems eliminates
the need for an other/specify category as
any abnormalities identified should fall
under one of the pre-specified categories.
Even if the sponsor does not require all
body systems to be examined at a given
time point, the complete list should still be
used. Instructions should be given to the
site to record ‘Not Done’ in Exam Result
field for any systems not examined.
6 Examination Result PERES Overall assessment of examined body For each body system listed, record the result For each body system listed on the CRF, Highly
system. of the examination (Normal or Abnormal). If provide the following options for results: Recommended
the examination is not performed or not Normal, Abnormal and Not Done. Sites
required select Not Done. should be directed to complete overall
assessment for each exam category/body
system listed.
If the examined body system is normal
then the value in PEORRES should be
NORMAL. If the body system is not
examined, then the value in PEORRES
should be Null and the value in PESTAT
should be Not Done. If the examined
body system is abnormal, then the value of
PEORRES should contain the text of the
abnormal findings.
7 Abnormal Findings PEDESC Text description of any abnormal Record all abnormal findings for the given Text entered under abnormal findings Highly
findings. body system in the space provided. (PEDESC) should be mapped to Recommended
PEORRES.
8 Evaluator PEEVAL Role of the person who provided the Enter the role of the person who provided the Used only for results that are subjective. Optional
evaluation. evaluation (e.g., investigator, adjudication Should be null for records that contain
committee, vendor). collected or derived data.

DRAFT 2008-04-03
4.15. Protocol Deviations – DV (Findings)
4.15.1. Considerations Regarding Usage of a Protocol Deviations CRF
The Protocol Deviations sub-team recommends avoiding the creation of a Protocol Deviations CRF (individual sponsors can determine whether it is needed for their
particular company). During sub-team deliberations, most sub-team participants emphasized that their companies did not utilize specific CRFs for collection of
protocol deviations. This information was derived from other CRF domains or system functionalities. The sub-team did, however, develop a CDASH data collection
standard for Protocol Deviations, which maps to the SDTM DV domain, but did not categorize any of the variables as highly recommended. The DV table was
developed as a guide that clinical teams could use for designing a Protocol Deviations CRF and study database should they choose to do so.
4.15.2. Rationale
If a sponsor decides to use a Protocol Deviations CRF, the sub-team felt the sponsor should not rely on this CRF as the only source of protocol deviation information
for a study. Rather, they should also utilize monitoring, data review and programming tools to assess whether there were protocol deviations in the study that may affect
the usefulness of the datasets for analysis of efficacy and safety. By utilizing this information a sponsor can then decide which method is best for their company.
(CDASH variables
shaded)
1 Were there any DVYN Indication of whether or not there was a Enter “Yes” if a protocol deviation occurred May be derived in the analysis Optional
protocol deviations? protocol deviation. and “No” if none occurred and subject has (submission) dataset.
completed treatment.
2 Protocol Deviation DVTERM Verbatim text of the variation from Record protocol deviation identified. This may be derived from clinical data or Optional
Term (text) processes or procedures defined in a captured in the clinical data management
protocol. system.
3 Protocol Deviation DVDECOD Controlled terminology for the name of Select appropriate code from list of protocol May capture this programmatically or Optional
Coded Term the protocol deviation. deviation terms. manually (manual may be a combination
of manual review and programmed
coding).
4 Category for Protocol DVCAT Category of the deviation criteria. Would not be entered by clinical site. May be derived by the sponsor. May be Optional
Deviation sponsor-defined (e.g., MAJOR or
MINOR.).

DRAFT 2008-04-03
(CDASH variables
shaded)
5 Start Date DVSTDTC Start date of the protocol deviation. Record complete date that the protocol This may be derived. Optional
deviation began using the International date
format. For more detail instructions see the For the SDTM dataset, the SDTM
Best Practice section. Variable DVSTDTC is derived by
This should be the start or occurrence of the Time (if time is collected) into DVSTDTC
protocol deviation and not the date it was using the ISO 8601 format.
discovered or reported.
6 Start Time DVSTTM Start time of the protocol deviation. If appropriate, record the time (as complete This may be derived. Optional
(Note: If collected, as possible) the protocol deviation began.
will be derived into For more detail instructions see the Best For the SDTM dataset, the SDTM
DVSTDTC.) Practice section. Variable DVSTDTC is derived by
This should be the start or occurrence of the Time (if time is collected) into DVSTDTC
protocol deviation and not the time it was using the ISO 8601 format.
discovered or reported.
7 End Date DVENDT End date of protocol deviation. Record the date that the Protocol deviation This may be derived. Optional
ended using the international date format.
For more detail see the Best Practice section. For the SDTM dataset, the SDTM
Variable DVSTDTC is derived by
This should be the date the protocol concatenating CDASH End Date and
deviation stopped and not the date it was Time (if time is collected) into DVSTDTC
discovered or reported. using the ISO 8601 format.
8 End Time DVENTM End time of protocol deviation. Optionally, if appropriate, record the time (as This may be derived. Optional
(Note: If collected, complete as possible) the protocol deviation
will be derived into ended. For the SDTM dataset, the SDTM
DVENDT.) Variable DVSTDTC is derived by
This should be the time the protocol concatenating CDASH End Date and
deviation stopped and not the time it was Time (if time is collected) into DVSTDTC
discovered or reported. using the ISO 8601 format.
9 Trial Epoch EPOCH Epoch associated with the start Record Epoch associated with the start May be derived in the analysis Optional
date/time of the protocol deviation. date/time of the protocol deviation (e.g., (submission) dataset.
TREATMENT PHASE, SCREENING and
FOLLOW-UP).

DRAFT 2008-04-03
(CDASH variables
shaded)
10 ID # DVSPID Sponsor-defined reference number. Can None. Optional

be pre-printed on the CRF as an explicit
line identifier or defined in sponsor’s
operational database (e.g., Line number
on a CRF page).
Note: The team recommended against collecting protocol deviations on a CRF since typically the information is already collected in the CRF or is derived from
available data. The SDS team has defined the DV domain within SDTM as collecting just protocol deviations information collected on a specific protocol
deviations CRF and that any derived protocol deviations information be reported within ADAM.

DRAFT 2008-04-03
4.16. Subject Characteristics – SC (Findings)

(CDASH variables
shaded)
1 Date of Collection SCDTC Date of collection. Record the date of collection of subject The date of collection may be derived Recommended/
characteristic data using the international from the date of visit and if so, a separate Conditional
date format. For more detail instructions see collection date field is not required.
the Best Practice section.
Variable SCDTC is derived by
Collection (if time is collected) into
SCDTC using the ISO 8601 format.
2 Time of Collection SCTM Time of collection. Record the time (as complete as possible) of Only record if this level of detail is Optional
(Note: If collected, collection of subject characteristic data. For necessary for analysis. The time of
will be derived into more detail instructions see the Best Practice collection may be derived from the time of
SCDTC.) section. visit, and if it is so collected, a separate
collection time field is not required.
Variable SCDTC is derived by
Collection (if time is collected) into
SCDTC using the ISO 8601 format.
3 Gestational Age at The age (in weeks) of the newborn A constant that may be useful for analysis Optional
Birth infant, counted from the first day of the in pediatric or neonatal studies.
woman’s last menstrual period (LMP)
or health status indicators / Clinical
Estimate (CE).
4 Eye Color SCTESTCD Natural eye color Record the subject’s eye color. Optional

DRAFT 2008-04-03
(CDASH variables
shaded)
5 Childbearing Potential SCTESTCD Subject’s childbearing potential Check the correct box to indicate the Optional
subject’s childbearing potential, or
postmenopausal or sterilized as required for
the form.
6 Education SCTESTCD Education level achieved at start of Optional

study (Reference date)
7 Sub-study SCTESTCD Sub-study participation information. For some Phase 1 studies sub-study Optional
Participation information is captured, such as “subject is
on fasting sub-study” or “subject is on PK
sub-study”.

DRAFT 2008-04-03
4.17. Substance Use – SU (Interventions)
The primary recommendation was to not limit by category the initial response to a Yes/No flag question, but rather use a more descriptive response for substance use.
The prompt variable, stored as SUPPSU QNAM SUNCF, would require a response to ‘Never, Current, or Former’. Again, based on the wide variability of protocol
definitions of use, the specific definitions for this response would be sponsor/protocol defined. By using these categories for usage, a number of questions about use
and frequency can be collapsed, in turn decreasing the number of data points required in the Substance Use Domain. More detailed information about duration,
amount, start and stop dates are optionally captured.
(CDASH variables
shaded)
1 Type of Substance SUTRT The type of substance (e.g., TOBACCO, Not applicable. Note that sponsors may require different Highly
ALCOHOL, CAFFEINE, etc. Or types of substance use data (e.g., illicit Recommended
CIGARETTES, CIGARS, COFFEE, drug use, dietary information, etc.); the
etc.). value for category may be pre-printed on
the CRF as a label for the Prompt for
Substance Use.
If a more detailed type of substance
appears on the CRF (e.g., cigarettes,
cigars, rather than tobacco), SUCAT
should be “tobacco” and SUTRT should
be “cigarettes”. If the sponsor does not
specify a type of tobacco on the CRF,
SUTRT should be “tobacco”.

DRAFT 2008-04-03
(CDASH variables
shaded)
2 Prompt for Substance SUNCF Substance Use Occurrence. Tick the appropriate box to indicate if the The team recommends the use of NEVER, Highly
Use subject has never used/consumed tobacco / CURRENT and FORMER as responses. Recommended
alcohol / caffeine, currently consumes
tobacco / alcohol / caffeine, or The three options, NEVER, CURRENT
used/consumed tobacco / alcohol / caffeine. and FORMER should be sponsor-defined.
If the sponsor has specific definitions for
the three, these definitions should be
detailed in the instructions to the site.
As this type of response does not easily
correspond to an SDTM variable. The
Team recommends using SUNCF as the
variable name in the clinical database.
Note that SUNCF is not defined in the
SDTM and, generally, should be dropped
prior to submission. If submitted, it should
be stored in SUPPSU.
Note that NEVER maps to SUOCCUR as
“N”. CURRENT and FORMER map to
SUOCCUR as “Y”.
3 Type of Substance SUCAT Used to define a category of related Not applicable. Note that sponsors may require different Optional
records (e.g., TOBACCO, ALCOHOL, types of substance use data (e.g., illicit
CAFFEINE, etc.). drug use, dietary information, etc.); the
value for category may be pre-printed on
the CRF as a label for the Prompt for
Substance Use.
If a more detailed type of substance
appears on the CRF (e.g., cigarettes,
cigars, rather than tobacco), SUCAT
should be “tobacco” and SUTRT should
be “cigarettes”. If the sponsor does not
specify a type of tobacco on the CRF,
SUTRT should be “tobacco”.

DRAFT 2008-04-03
(CDASH variables
shaded)
4 Amount SUDOSTXT Substance use consumption amounts or Tick the appropriate box to indicate the Where possible, the options for Optional
a range of consumption information amount of tobacco / alcohol / caffeine the dose/amount should be pre-printed on the
collected in text form [e.g., 1-2 (packs), subject consumes on a regular basis. CRF.
8 (ounces), etc.].
Note that in example given in the
Definition, “(packs)” and “(ounces)” have
been included as a point of reference. They
would, of course, be stored as SUDOSU.
If the dose is part of a planned analysis,
then the use of SUDOSE, a numeric
variable, should be considered.
5 Unit SUDOSU Units for SUDOSTXT (e.g., PACKS, Not applicable. Where possible, the options for Optional
OUNCES, etc.). dose/amount units should be pre-printed
on the CRF.
6 Frequency SUDOSFRQ Usually expressed as the number of uses Not applicable. Where possible, the options for Optional
consumed per a specific interval (e.g., dose/amount frequency should be pre-
PER DAY, PER WEEK, printed on the CRF.
OCCASIONAL).
7 Start Date SUSTDTC Date substance use started. Record the start date using the international The sponsor may choose to capture a Optional
date format. For more detail instructions see complete date, or any variation thereof
the Best Practice section. (month & year or year, etc.).
Variable SUSTDTC is derived by
Time (if time is collected) into SUSTDTC
8 Start Time SUSTTM Time substance use started. Record the start time (as complete as For the SDTM dataset, the SDTM Optional
(Note: If collected, possible). For more detail instructions see the Variable SUSTDTC is derived by
will be derived into Best Practice section. concatenating CDASH Start Date and
SUSTDTC.) Time (if time is collected) into SUSTDTC

DRAFT 2008-04-03
(CDASH variables
shaded)
9 End Date SUENDTC Date substance use ended. Record the end date using the international The sponsor may choose to capture a Optional
date format. For more detail instructions see complete date, or any variation thereof
the Best Practice section. (month & year or year, etc.).
. For the SDTM dataset, the SDTM
Variable SUENDTC is derived by
concatenating CDASH End Date and Time
(if time is collected) into SUENDTC using
10 End Time SUENTM Time substance use ended. Record the end time (as complete as For the SDTM dataset, the SDTM Optional
(Note: If collected, possible). For more detail instructions see the Variable SUENDTC is derived by
will be derived into Best Practice section. concatenating CDASH End Date and Time
SUENDTC.) (if time is collected) into SUENDTC using
. the ISO 8601 format.
11 Duration SUDUR The duration of the substance use. (e.g., Record how long the subject has This should only be collected on the CRF Optional
smoked) if this level of detail is needed and if
SUSTDTC & SUENDTC are not collected
on the CRF.
The sponsor-defined options (e.g., weeks,
months, years, etc.) should be pre-printed
on the CRF to avoid making this a free
text field. This will allow the response to
be translated into ISO 8601 format.

DRAFT 2008-04-03
4.18. Vital Signs – VS (Findings)
The review of vital signs data elements was more straightforward as all sponsor reviewed CRFs captured similar data and the items were consistent with the SDTM VS
domain. The key topic for discussion and consideration was how to link the collected elements to the SDTM-defined variables. For example, many VS CRFs collect
each unique result in its own field and the resulting values are stored as separate variables in the clinical data management system. The SDTM VS domain utilizes a
normalized data structure, i.e. one variable, VSTESTCD, is used to capture the test name and another variable, VSORRES, is used to capture the result. The team
thought of providing two options for the VS variable definition table; a normalized structure similar to that of SDTM and the other suggesting unique variables for each
test. The former format is being offered for consistency with other findings domains.
(CDASH variables
shaded)
1 Date of Vital Sign VSDTC Date of measurements Record date of measurements using the The date of measurement may be derived Recommended/
Measurements international date format. For more detail from the date of visit and therefore a Conditional
instructions see the Best Practice section. separate measurement date field is not
required.
Variable VSDTC is derived by
Vital Sign Measurements (if time is
collected) into VSDTC using the ISO 8601
format.
2 Sponsor Defined VSSPID Sponsor defined reference number None Pre-printed on the CRF as an explicit line Optional
Identifier identifier or defined in the sponsor’s
operational database.
3 Study Day of Vital VISITDY Study day of measurements, measured as None This may be a pre-printed field on the CRF, Optional
Signs integer days or more likely, a derived variable.
4 Planned Time Point VSTPT Text description of time when None If applicable, this will be pre-printed on Optional
measurement should be taken CRF when measurements are required at
multiple time points within a visit day.

DRAFT 2008-04-03
(CDASH variables
shaded)
5 Time of Vital Sign VSTM Time of measurements. Record time of measurement (as complete as For the SDTM dataset, the SDTM Optional
Measurements (Note: If collected, possible). For more detail instructions see the Variable VSDTC is derived by
will be derived into Best Practice section. concatenating CDASH Date and Time of
VSDTC.) Vital Sign Measurements (if time is
collected) into VSDTC using the ISO 8601
format.
6 Vital Sign Test Name VSTEST Verbatim name of the test or Record the name of the vital sign test if not It is recommended that the test names be Highly
examination used to obtain the pre-printed on the CRF. pre-printed on the CRF. Recommended
measurement or finding.
7 Vitals Status VSSTAT Used to indicate that a vital signs If measurement not taken please indicate on If CRF design provides for individual status Recommended/
measurement was not done. CRF by selecting Not Done. check boxes where site can indicate Not Conditional
Done for the given parameter, information
would be stored as Not Done in VSSTAT.
If value exists in VSORRES then the result
in VSSTAT is Null.
If CRF guidelines direct site to enter Not

Done (or similar text) in the result field,
then value of VSSTAT is Not Done,
otherwise if numeric value exists in result
variable (VSORRES) then value of
VSSTAT is Null.
8 Vital Sign Test Result VSORRES Result of the vital signs measurement as Record vital sign results. Key data collected. Highly
or Finding originally received or collected. Recommended
9 Original Units VSORRESU Original units in which the data were Record or select the unit of measure It is recommended that the units be pre- Highly
collected. associated with the test, if not pre-printed on printed on the CRF when possible. Recommended
the CRF.
10 Location of Vital Signs VSLOC Location on body where measurement Record or select location on body where Location may be pre-defined as part of Recommended/
Measurement was performed. measurement was performed, if not pre- CRF label. Conditional
printed on CRF.

DRAFT 2008-04-03
(CDASH variables
shaded)
11 Position of Subject VSPOS Position of the subject during a Record the position of subject at time of test. Position may be pre-defined as part of CRF Highly
measurement or examination. label or site may be given one or more Recommended
options to select from.

DRAFT 2008-04-03
Appendices
APPENDIX A: Process
APPENDIX A1: Process and Deliverables
The CDASH Project follows the CDISC Operating Procedure (COP-001) for Standards Development
(http://www.cdisc.org/about/bylaws_pdfs/CDISC-COP-001-StandardsDevelopment-Feb2006.pdf). Following
is flow diagram that describes Stage II: Standards Development/Revision/Release of Version 1.0.
The CDISC Standards Development Process calls for a minimum of three reviews to build consensus towards
the Version 1.0 standard (see section 2.0). The CDASH domain-specific recommendations from the teams are
first reviewed by an internal CDISC Technical Leadership Committee (TLC) to ensure that they do not diverge
from the other relevant CDISC standards. They are then combined into ‘review packages’ for external review
by the Collaborative Group, which acts as an external focus group in the case of the CDASH Project. The
entire set of domains will be reviewed together in a final open public review process prior to the release of
Version 1.0.
SDTM and CDASH

To develop the Reviewed Versions (RV) contained in this document, the CDISC SDTM variable tables served
as a starting and reference point. The CDASH and SDTM variables may differ in certain cases, however,
because SDTM variables are used for standardizing results for regulatory submissions whereas CDASH
variables are used in the collection of data. Another difference is that the CDASH project is designed to
encourage collection of a minimal or basic set of required and necessary data variables whereas SDTM
represents more of a ‘superset’ of variables for reporting results.
Project Deliverables
• agree on basic data collection variables,
• map these variables to SDTM, to add definitions
• write instructions for investigative sites and for study Sponsors
During the initial CDASH Kick-off meeting in October 2006, ACRO presented the following guiding
principles. These guiding principles were reviewed at the initiation of each team.
Variables identified should:

• Ensure that SDTM “required” elements are addressed directly or indirectly
• Be “standard” yet flexible to allow customization within defined limits
• Limit variables to required and necessary

DRAFT 2008-04-03
• Comply with regulatory requirements (see Appendix E)

• Reduce redundancies; do not duplicate information found elsewhere in CRFs
• Increase collection of meaningful data
• Facilitate use of standards by all users
• Be appropriate for use in both pre- and post- approval studies
• Allow consistent and efficient collection, transmission, analysis and archival of data
The teams then began by reviewing CRF samples supplied by ACRO (where available), as well as other CRF
samples collected that are currently used by industry. Teams were asked to document the data collection
variables reviewed along with a justification for including or excluding them in the CDASH recommendations.
For each variable, a CDASH Core category is assigned (Highly Recommended/Recommended/Conditional and
Optional), and variable labels and definitions were developed. The SDTM submission variables serve as a
target for deliverable data. Data collection variables were mapped to the SDTM variables as applicable.
Data collection variables that were reviewed and determined to be generally considered not necessary to collect
(e.g., can be derived collected elsewhere) are included in the document in Appendix D.
Within each team, sub-groups are assigned and given the action of reviewing CRF samples, making quality
control (QC) checks of CRF and establishing the administrative procedures to be used by the teams. Weekly or
bi-weekly teleconferences provided the communication forum to review and discuss the identification of basic
data collection variables for a given domain.
In addition, team members were encouraged to collected feedback from numerous functional areas within their
respective companies (including ex-US affiliates).

DRAFT 2008-04-03
APPENDIX A2: Volunteers
The CDASH project work is performed primarily by volunteers representing Pharmaceutical and
Biopharmaceutical companies (~50%), Contract Research Organizations (42%), Academia and
Government (~8).
The CDASH Core Team is comprised of a qualified, multidisciplinary team of 15 members. Each member
either led a safety domain team (each team was responsible for one or more domains) or was responsible for
some aspect of the final CDASH consolidated document. See Appendix 6 for a list of CDASH Core Team
members and their respective teams (domains) / responsibility areas.
The Core Team was responsible for executing the project plan, holding regular conference calls and face-to-
face meetings, as appropriate, to achieve the strategic objectives. Each Core Team member leads one or more
teams (or sub-groups) of volunteer participants.
Volunteers for each team were recruited via open invitation. Effort was made to ensure that representation on
each team is comprised of diverse companies representing a variety of functional areas and with multinational
representation whenever possible. Each team had between 10 - 40 members.

DRAFT 2008-04-03
APPENDIX B: Data Collection Variables Generally Considered Not Necessary to

Collect on the CRF
The following variable tables are included in this document to provide reviewers with additional information on
the thinking behind the development of the CDASH recommendations. These variables were reviewed and
determined by the teams to be ‘generally unnecessary to collect on the CRF” (not recommended for inclusion in
the CRF), the reason for this determination is included in the “rationale” column.
These data collection variables, and many others, were represented in the example CRFs provided by
volunteers. Further these tables are not intended to be an absolute list of possibilities, rather a sampling of
what was observed on CRFs.
There are no variables “Generally Considered Not Necessary for Collection on the CRF” listed for Comments,
Physical Exam, Subject Characteristics and Vital Signs domains.

DRAFT 2008-04-03
APPENDIX B1: Identifier & Timing Variables
Variable Label Definition Rationale
Study Identifier Unique identifier for a study within the submission. Collected in header or derived.
Domain Abbreviation Two-character abbreviation for the domain most relevant Derived.
to the observation.
Unique Subject Unique subject identifier within the submission. Collected in header or derived.
Identifier
Sequence Number Sequence number given to ensure uniqueness within a Derived.

dataset for a subject. Can be used to join related records.
Group ID Used to tie together a block of related records in a single Not needed.
domain to support relationships within the domain and
between domains.
Reference ID Optional internal or external identifier. Not needed.
Sponsor-Defined Optional Sponsor-defined reference number. Perhaps pre- In general, this is not needed. Some teams,
Identifier printed on the CRF as an explicit line identifier or defined however, have included this variable as
in the sponsor’s operational database. (e.g., line number optional when it would be useful.
on a Disposition page)
Visit Number 1. Clinical encounter number. Collected in header or derived.
2. Numeric version of VISIT, used for sorting.
Planned Study Day Derived.

of Visit
Date / Time of Not needed on the CRF.

collection
Study Day of 1. Study day of medical history collection, measured as Derived.

Collection 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.

DRAFT 2008-04-03
APPENDIX B2: Adverse Events
Adverse Event Used when the occurrence of specific adverse events is Considered redundant, can be addressed
Occurrence solicited to indicate whether an adverse event occurred or during analysis.
not.
Continuing Flag Identifies an event that is ongoing at the time of a subject’s Redundant field used for monitoring or
discontinuation from a study. cleaning
Expected Criteria Representation of the expectedness of the event. Handled in Clinical Investigative Brochure.
Value of investigator’s input.
Duration Collected duration and unit of an adverse event. Derived.
Event diagnosis Provides the sender with an opportunity to combine signs Considered a redundant field.
and symptoms that were reported into a succinct diagnosis.
Ongoing as of Date Gives reference to when the subject was last contacted to Considered a redundant field, captured in
determine if the AE was still ongoing. other fields: Blank Stop Date and Outcome.
Time Course Helps understand the nature of the AE Derived variable.
Is this AE the reason Captured elsewhere in the CRF (action taken).

for withdrawal from
the study?

DRAFT 2008-04-03
APPENDIX B3: Concomitant Medications
Generic Dispensed An indicator that the drug name provided is a generic Assuming drug names are coded to a
name. dictionary, this is redundant and should not
also be a field on the CRF.
Total Daily Dose Dose administered, standardized to amount per day, Should this level of detail be needed for a
regardless of dosing interval. (e.g., 200 mg BID would general medication, it is recommended that it
equate to a Total Daily Dose of 400 mg) be calculated or derived from other fields such
as Dosage Units, Dosage Amount and Dosage
Interval to avoid confusion and calculation by
the clinical site.
Response Did the condition for which the medication was taken Applies to Medications of Interest.
respond to treatment
Prescription or OTC Indicate whether the drug required a prescription or if the This level of detail not required for General
subject obtained it OTC Medications.
Device used to admin For some drugs, such as asthma medications, the delivery Applies to Medications of Interest.
drug device can affect the response
Was drug admin for Used to identify medications taken for a specific indication Applies to Medications of Interest.
exacerbation which has worsened
Was drug admin as a Used to identify medications taken for a specific indication Applies to Medications of Interest.
rescue Medication which has worsened
Cumulative dose Calculated total exposure over a specified duration Applies to Medications of Interest,
used alternatively, can be calculated from other
variables.
Was drug ever used Asking if a specific medication was used (e.g., Was Applies to Medication of Interest.
aspirin every used?)
Total duration Length of time subject was exposed to a drug If needed, can be calculated from Start
Date/Time and Stop Date/Time.
Total duration unit Unit of time for subject exposure (e.g., minutes, hours, If needed, can be derived.
days, etc.)
Was Medication Did the medication reach toxic levels, requiring it to be Applies to Medications of Interest.
stopped due to discontinued?
toxicity
General Comments The team assumes that comments will be

collected on a Comment CRF. This comment
CRF may be on the same page as the CM
CRF.
None Taken A single box that can be marked to indicate that no Instead of this question, a Y/N question “Were
concomitant medications were taken any drugs taken?” is recommended to avoid
ambiguity if this box is not marked, but no
medication details are present. This
recommended option is listed on Table 3.
Category of Applies to Medications of Interest.

Medication

DRAFT 2008-04-03
Type of Medication Applies to Medications of Interest

DRAFT 2008-04-03
APPENDIX B4: Demography
Subject Reference Reference Start Date/time for the subject in ISO 8601 Derived.
Start Date/Time character format. Usually equivalent to date/time when
subject was first exposed to study treatment. Required for
all randomized subjects; will be null for all subjects who
did not meet the milestone the date requires, such as screen
failures (if screen failures are submitted).
Subject Reference Reference End Date/time for the subject in ISO 8601 Derived.
End Date/Time character format. Usually equivalent to date/time when
subject was determined to have ended the trial, and often
equivalent to date/time of last exposure to study treatment.
Required for all randomized subjects; null for screen
failures (if screen failures are submitted).
Planned Arm Code Short name for ARM (may be up to eight characters). Derived.
Description of Name of the Arm to which the subject was assigned. Derived.
Planned Arm

DRAFT 2008-04-03
APPENDIX B5: Disposition
Category for Used to define a category of related records. (e.g., Derived.

Disposition Event DISPOSITION EVENT or PROTOCOL MILESTONE)
Subcategory for A further categorization of disposition event. Not needed.

Disposition Event
Date/Time of The date that the disposition of the subject was collected Not needed since the date of interest is the
Collection actual date of completion or discontinuation
Study Day of Start of Study day of start of the disposition event relative to the Derived if needed.
Disposition Event sponsor-defined RFSTDTC.
Death details Information such as Date of Death (if not the disposition This information is not strictly required for the
event for a specified trial epoch and/or if required for every description of subject disposition; if required,
subject in order that a survival analysis can be performed), it should be collected on a separate CRF
Cause of Death (if not requested on disposition CRF), module. A Clinical Events module is
whether autopsy done, etc. proposed by the SDS team in the draft SDTM
Implementation Guide that could be used to
submit such data
Follow-up / vitals Information such as method of contact, frequency of This information is not strictly required for the
information contact attempts, whether subject is dead or alive, etc. description of subject disposition; if required,
it should be collected on a separate CRF
module
Additional blind Information such as when blind was broken, reason for This information is not strictly required for the
break information blind break, treatment administered to subject, etc. description of subject disposition; if required,
it should be collected on a separate CRF
module
Date of Withdrawal The date on which consent was withdrawn Considered redundant field when date of
of Consent completion or discontinuation is collected
Comments Open comment field Any additional information should be

recorded as a specification of the reason for
discontinuation

DRAFT 2008-04-03
APPENDIX B6: Drug Accountability
Definition Recommendation Rationale
Capsules actually taken EX • When collected, Exposure is the most appropriate domain
because this is assessing exposure rather than tracking
medication.
• If needed, it can be derived based on Dispensed less Returned.
• This may be covered by one of the DATESTCD values.
Was study medication EX • When collected, Exposure is the most appropriate domain
dispensed during the study? because this is assessing exposure rather than tracking
medication.
• This question was present on an electronic data capture screen for
navigation purposes. This data can be derived from other
sources.
Was study medication taken EX • When collected, Exposure is the most appropriate domain
during the study? because this is assessing exposure rather than tracking
medication.
navigation purposes.
• This data can be derived from other sources.
Was the study medication dose EX • When collected, Exposure is the most appropriate domain
modified during the study? because this is assessing exposure rather than tracking
medication.
navigation purposes.
• This data can be derived from other sources.
Did subject receive correct Derivable from other data. This information will probably be obtained from reviewing the site’s
treatment? If no, explain. drug accountability logs and/or randomization records post-blinding.
It may not be possible to answer this question on the CRF prior to
breaking the blind.
Was correct treatment Derivable from other data. This information will probably be obtained from reviewing the site’s
delivered? drug accountability logs and/or randomization records post-blinding.
It may not be possible to answer this question on the CRF prior to
breaking the blind.

DRAFT 2008-04-03
APPENDIX B7a: ECG Test Results, Scenario 1
Data Collection Variables Considered Not Necessary to Collect on CRF. These are either expected to be
received from the Central ECG vendor or are not considered necessary. For central ECG processing these
data are expected to be provided separately by the ECG vendor or are not considered necessary to be
collected.
Test Name Verbatim name of the test or examination used to obtain Not required when ECG data is not recorded
the measurement or finding. on CRF. This data may be obtained from the
central ECG vendor or the electronic
Test Result Result of the measurement or finding as originally received equipment.
or collected. If Clinical Significance is not present in the
electronic data and the sponsor needs to
Units Original units in which the data were collected. collect this on the CRF instead, Scenario 3
should be used.
Vendor Name Name of vendor providing ECG data
Evaluator Role of the person who provided the evaluation. This

should only be used for results that are subjective (e.g.,
assigned by a person or a group) and do not apply to
quantitative results (e.g., ADJUDICATION COMMITTEE,
VENDOR)
Clinical Significance Whether ECG results were clinically significant.
Abnormal flag Reference Range Indicator Indicates where value falls with
respect to reference range defined by high and low ranges,
or by an expected character result (e.g., NORMAL).
Investigator Investigator comment on ECG test or results. Not needed. Details of collecting comments
Comment are covered under the CDASH Comments
Team. It is expected that comments related to
specific tests will be coming from the
electronic data, not collected on the CRF.

DRAFT 2008-04-03
APPENDIX B7b: ECG Test Results, Scenario 2
Local reading: When results of ECG are reported directly on the CRF.
Investigator comment Not needed. Investigator Comment

on ECG results.
If Investigator is providing comments that are actually an
interpretation of the ECG as a whole or indicating the
presence of a particular condition, this is expected to be
collected as a result of the ECG.
Details of collecting general comments are covered under
the CDASH Comments Team.
Name of vendor If ECG is read locally, vendor name does not apply. Vendor Name
providing ECG data
Internal or external If ECG is read locally, external reference does not apply ECG Reference ID
ECG identifier.

DRAFT 2008-04-03
APPENDIX B7c: ECG Test Results, Scenario 3
Central processing but CRF includes site assessment of clinical significance.
Abnormal flag Reference Range Indicator Indicates where value falls with Not required when ECG data is not recorded
respect to reference range defined by high and low ranges, on CRF.
or by an expected character result (e.g., NORMAL).
Units Original units in which the data was collected. Not required when ECG data is not recorded
on CRF.
Investigator Investigator comment on ECG test or results. Not needed. Details of collecting comments
Evaluator Role of the person who provided the evaluation. This Not required when ECG data is not recorded
should only be used for results that are subjective (e.g., on CRF.
assigned by a person or a group) and do not apply to
quantitative results (e.g., ADJUDICATION COMMITTEE,
VENDOR)

DRAFT 2008-04-03
APPENDIX B8: Exposure
Body Surface Area VS This is not exposure data, even though it’s
related to dosage.
Actual Body Weight VS This is not exposure data, even though it’s
related to dosage.
Was any sedation or CONMED This is not exposure data, even though it
topical anesthetic occurs around the time of dose
given?
Weight used to VS This is not exposure data, even though it’s

prepare infusion related to dosage.
Any premeds given? CONMED This is not exposure data, even though it
occurs around the time of dose.
Total input / output CONMED Not exposure data

amounts and types
(PRBC, Enteral
nutrition, prenteral
nutrition, conmed,
other / Other blood
loss including
drainage, other)
Date of Dose Change Not needed Derivable from start date variable provided
that a new record is recorded in the database
when the dose changes
AE # associated with Not needed Administrative field that is not necessary on

Dose Change CRF.
Was entire dose Not needed Derivable from protocol specifications and
administered? dose/amount taken
Did subject receive at Not needed Derivable from other data

least one dose?
Was the dose stopped Not needed Derivable from other data
early?
Dose Administered? Do not collect per recommendation of SDS team EXOCCUR will not be included in SDTM per
Yes/No decision by SDS team on 16 January 2008.
Gauge of needle used Not typically collected in majority of CRFs The Exposure and Drug Accountability work
to administer stream initially included this CRF question as
investigational ‘optional’. Based on feedback received during
product the CDASH Collaborative Group review
period, we agreed to move it to ‘not
recommended to collect’.
Total Volume Not typically collected in majority of CRFs The Exposure and Drug Accountability work
Prepared stream initially included this CRF question as
‘optional’. Based on feedback received during
the CDASH Collaborative Group review
period, we agreed to move it to ‘not

DRAFT 2008-04-03
Total Volume Not typically collected in majority of CRFs The Exposure and Drug Accountability work
Prepared Unit stream initially included this CRF question as
‘optional’. Based on feedback received during
the CDASH Collaborative Group review
period, , we agreed to move it to ‘not

DRAFT 2008-04-03
APPENDIX B9: Inclusion / Exclusion
Consent Date The date that this subject signed the Informed Consent This variable is not required for any purpose
Form in the entry eligibility data. If collected in the
CRF, it should be mapped to the Disposition
Domain.
Consent Time The time that this subject signed the Informed Consent This variable is not required for any purpose
Form in the entry eligibility data. If collected in the
Domain.
ICF Signed? Did the subject sign the Informed Consent Form? This variable is not required for any purpose
in the entry eligibility data. If collected in the
Domain.
Optional Consent Some organizations use separate consent forms to obtain This variable is not required for any purpose
Signed? research samples, or medical histories that will be included in the entry eligibility data. If collected in the
in a separate study database (e.g., natural history of a CRF, it should be mapped to the Disposition
disease) Domain.
Written or Oral Is the subject fluent in written or oral English? This is usually included as an entry criterion,
Fluency? or verified through monitoring practices.
Exception A description of the reason this subject did not meet all of The Team discussed this and decided that no
the entry criteria. references to “exceptions” or “waivers” should
or be recorded on the IE CRF. Only the specific
Waiver criteria that are not met should be recorded.
Note: Consider modifying the criteria
rather than allowing subjects in who do not
meet the criteria.
Exception Approved? This is used to verify that a Sponsor-authorized individual The Team discussed this and decided that no
approved the subject to be enrolled in a study, in spite of references to “exceptions” or “waivers” should
or the subject not meeting all entry criteria. be recorded on the IE CRF. Only the specific
Waiver Granted? criteria that are not met should be recorded.
Date exception This variable collected the date on which a Sponsor- The Team discussed this and decided that no
approved? authorized individual approved a subject to be enrolled in a references to “exceptions” or “waivers” should
study, in spite of the subject not meeting all entry criteria. be recorded on the IE CRF. Only the specific
or criteria that are not met should be recorded.
Date waiver granted?
Exception approved This variable collected the name of the Sponsor-authorized The Team discussed this and decided that no
by individual who approved a subject to be enrolled in a references to “exceptions” or “waivers” should
study, in spite of the subject not meeting all entry criteria. be recorded on the IE CRF. Only the specific
or criteria that are not met should be recorded.
Waiver granted by
Criterion Number The number that corresponds to a protocol-defined entry Since not all Sponsors use a numeric value to
criterion. identify each criterion, the more flexible term
“Criterion Identifier” was included in the
standard.

DRAFT 2008-04-03
APPENDIX B10a: Laboratory Test Results, Scenario 1
These are either expected to be received from the Central lab or are not considered necessary. For central
sample processing these data are expected to be provided separately by the processing lab or are not considered
necessary to be collected.
Test Name Verbatim name of the test or examination used to obtain Not required when lab data is not recorded on
the measurement or finding. Note any test normally CRF. This data may be obtained from the
performed by a clinical laboratory is considered a lab test. central lab or the electronic equipment.
Test Result Result of the measurement or finding as originally received

or collected.
Lab Name Name of lab analyzing sample
Sample Status Free or standardized text describing the condition of the

specimen.
Clinical Significance Whether lab test results were clinically significant. Not required when lab data is not recorded on
CRF. If Clinical Significance is not present in
the electronic data and the sponsor needs to
collect this on the CRF instead, Scenario 3
should be used.
Abnormal flag Reference Range Indicator Indicates where value falls with Not required when lab data is not recorded on
respect to reference range defined by high and low ranges. CRF. This data may be obtained from the
central lab or the electronic equipment.
Units Original units in which the data were collected. Not required when lab data is not recorded on
CRF. This data may be obtained from the
central lab or the electronic equipment.
Normal Range Normal range for continuous measurements in original LBORNRLO and LBORNRHI should be
units. populated only for continuous results;
LBSTNRC should be populated only for non-
Normal values for non-continuous measurements in continuous results. This data may be obtained
original units. from the central lab or the electronic
equipment.
Not required when lab data is not recorded on
CRF.
Investigator Investigator comment on lab test or results. Not needed. Details of collecting comments

DRAFT 2008-04-03
APPENDIX B10b: Laboratory Test Results, Scenario 2
Local processing: When results of sample analysis are reported directly on the CRF, these data are not
considered necessary to be collected.

DRAFT 2008-04-03
APPENDIX B10c: Laboratory Test Results, Scenario 3
Central processing but CRF includes site assessment of clinical significance, these data are not considered
necessary to be collected.
Sample Status Free or standardized text describing the condition of the Not needed. (e.g., HEMOLYZED, ICTERIC,
specimen. LIPEMIC etc)
Abnormal flag Reference Range Indicator Indicates where value falls with Not required when lab data is not recorded on
respect to reference range defined by high and low ranges. CRF.
Units Original units in which the data were collected. Not required when lab data is not recorded on
CRF.
Sample Status Free or standardized text describing the condition of the Not needed. (e.g., HEMOLYZED, ICTERIC,
LIPEMIC etc)
specimen.
Normal Range Normal range for continuous measurements in original LBORNRLO and LBORNRHI should be
units. populated only for continuous results;
LBSTNRC should be populated only for non-
Normal values for non-continuous measurements in continuous results. This data may be obtained
original units. from the central lab or the electronic
equipment.
Not required when lab data is not recorded on
CRF.

DRAFT 2008-04-03
APPENDIX B11: Medical History
Modified Reported If MHTERM is modified, then MHMODIFY will contain Derived.

Term the modified text.
Dictionary-Derived Dictionary-derived text description of MHTERM or Derived.

Term 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.
Medical History Medical history events that are pre-specified on the CRF. MHPRESP should only be derived if
Event Pre-specified MHOCCUR is needed. The use of this
variable is pending approval of 3.1.2.
Medical History The status that the question was not asked. Not needed for the MH CRF. If the response
Status to MHOCCUR is missing, MHSTAT may be
derived to NOT DONE.
Reason Medical Describes the reason medical history was not collected. Not needed on the MH CRF as we are not
History Not Used in conjunction with MHSTAT when value is NOT recommending the use of MHSTAT.
Collected DONE.
Body System or Body system or organ class (Primary SOC) that is involved Derived. MHBODSYS should be reserved for
Organ Class in an event or measurement from the standard hierarchy the body system categories (SOCs) used in the
(e.g., MedDRA). sponsor’s coding dictionary.

DRAFT 2008-04-03
APPENDIX B12: Protocol Deviations
Source of Protocol Point of reference for protocol deviation or CRF source of May be derived, optional for paper-based
Deviation protocol deviation. studies but unnecessary for all others
CRF Page # of CRF page number where protocol deviation occurs May be derived, optional for paper-based
Deviation studies but unnecessary for all others
Page Sequence CRF page number within collection of Protocol Deviations Optional for paper-based studies but
Number CRF pages unnecessary for all others
Check if Last Page Check box if this is the last page of protocol deviations Optional for paper-based studies but
unnecessary for all others
Protocol Deviation The number of the specific page of total pages of protocol Optional for paper-based studies but
Page _ of _ Pages deviations. unnecessary for all others
Check if None Check if no protocol deviations reported. Chose to utilize other flag variable.
Was Protocol Check if protocol deviation was approved by sponsor. Not considered appropriate for clinical data –
Deviation approved particular to another process.
by sponsor?
Approver’s Name Name of staff approving protocol deviation. Not considered appropriate for clinical data –
particular to another process.
Date of Notification Date sponsor was notified of protocol deviation. Not considered appropriate for clinical data –
particular to another process.
Excluded Days
Date of Approval Date protocol deviation was approved.

DRAFT 2008-04-03
APPENDIX B13: Substance Use
Subcategory for A further categorization of substance use. Not needed on the SU CRF.
Substance Use
Substance Pre- Substances that are pre-specified on the CRF. Derived.

specified
Substance Use Used when the use of specific substances is solicited to Derived. See Implementation/Rationale for
Occurrence indicate whether a substance was taken or not. (e.g., SUNCF.
Tobacco Consumption, Alcohol Consumption)
Substance use Amount of SUTRT consumed If the dose is part of a planned analysis, then
Consumption the use of SUDOSE should be considered.
Dose Form Dose form for SUTRT. (e.g., INJECTABLE, LIQUID, Not needed for SU CRF.
POWDER)
Route of Route of administration for SUTRT. (e.g., ORAL, Not needed for SU CRF.
Administration INTRAVENOUS, INHALATION)
Modified Reported If SUTRT is modified, then the modified text is placed Not needed for SU CRF. Note that none of the
Term here. team volunteers are currently coding their
substance use. If sponsors code substance use
information, SUMODIFY and SUDECOD
may be necessary.
Standardized Standardized or dictionary-derived text description of Not needed for SU CRF. Note that none of the
Substance Name SUTRT or SUMODIFY if a sponsor chooses to code the team volunteers are currently coding their
substance use. The sponsor should specify the dictionary substance use. If sponsors code substance use
name and version in the Sponsor Comments column or the information, SUMODIFY and SUDECOD
Define data definition document. may be necessary.
Substance Use Status Used to indicate the question was not asked. Not needed for SU CRF. If the response to
SUOCCUR is missing, SUSTAT may be
derived to NOT DONE.
Reason Substance Describes the reason substance use was not collected. Used Not needed on the SU CRF.
Use Not Collected in conjunction with SUSTAT when value is NOT DONE.
Substance Use Class May be used when coding substance use such as Not needed for SU CRF.
alcoholism or drug abuse.
Substance Use Class May apply when coding substance abuse use cases. Not needed for SU CRF.
Code
Total Daily Total daily use of SUTRT using the units SUDOSU Derived.
Consumption using
SUDOSU

DRAFT 2008-04-03
APPENDIX C: Regulatory References
Introduction:
Data capture is part of the regulated activities in clinical trials but very little in the regulations specifically
references data capture and management requirements. Regulatory references for unsolicited Comments (CO)
and Subject Characteristics (SC) are not included. When the CDASH domains were developed, each team
consulted the relevant guidances and regulations to determine the best way to fulfill the apparent requirements
and incorporate data capture and management best practices.
This appendix is organized by domain and lists the regulations and guidances that were referenced in
developing the CDASH domains. There are brief explanations and/or interpretations of the wording. Note that
there are often several ways of interpreting guidances and regulations, and therefore this information should not
be taken as an official or FDA/ICH-approved interpretation.
Scope:
• Includes information on the collection, analysis and reporting of safety data
• Includes information commonly found in clinical trials databases, and not the extended information
required for expedited adverse event reporting.
• Includes descriptions of the kinds of information present in the regulations, but does not list all the
individual data fields.
• Excludes references to appropriate protocol designs for enabling safety assessments
Key:
Source: defines the regulatory body that issued the regulation or guidelines.
Regulation/Guideline: the reference number and title of the regulation or guidelines.
Description/Wording: provides an interpretation of the intent of the regulations/guidelines as it applies to the

collection, analysis and reporting of clinical data, as well as specific wording from the guidelines where useful.
Generally the reader should reference the original document for details. Wording in italics contains some
suggestions for the implications of the regulation on data capture practices. It is not exhaustive, and users
should take these insights and apply them broadly.
Sources:
• Code of Federal Regulations (CFR)
• European Commission directives
• ICH Harmonized Efficacy Guidelines finalized as of 14 March 2008 (www.ich.org)
• FDA Guidances finalized as of 14 March 2008
(http://www.fda.gov/opacom/morechoices/industry/guidedc.htm)
• FDA Manual of Policies and Procedures and Compliance Program Guidance Manual
(http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm)
• NCI Code lists

DRAFT 2008-04-03
APPENDIX C1: Adverse Events (AE)
SOURCE REGULATION/GUIDELINE DESCRIPTION/WORDING
ICH E2A Clinical Safety Data Section II: Definitions and Terminology Associated With Clinical Safety Experience
Management: Definitions and
Standards for Expedited Reporting • Provides definitions for terms commonly used in safety data reporting, such as adverse event, serious adverse event and expectedness.
• Provides definitions for terms commonly used in safety data reporting, such as adverse event, serious adverse event and expectedness.
• By referencing the information to be submitted, it suggests a minimal set of variables to capture the key information.
• Defines processes for expedited reporting, including what must be reported and how to determine reporting timeframe
• Outlines assessing safety during blinded treatment, associated with placebo treatment, and post-study events
• Does not go into any detail around individual data points required, although contains some inferences about what SAE narratives must include
ICH E2B (M) Maintenance Of The ICH This document lists data points that must be transmitted when sending expedited AE reports, including in some cases suggested code lists (e.g.,
Guideline On Clinical Safety Data action taken with respect to study drug). While these are often handled by the Regulatory departments in companies, there should be discussions
Management : Data Elements For with CDM to determine the relationship of this information to the clinical database.
Transmission Of Individual Case
Safety Reports NB: as of Mar 2006 there is a new version of this document out for review (E2B (R3)). It contains clarifications and improvements. Its expected
finalization date is unknown.
ICH E2C Clinical Safety Data This covers the requirements for periodic reporting of safety information after product launch. It doesn’t list variables in the manner of E2B, but
Management: Periodic Safety Update instead focuses on the frequency and timing of safety updates, how to structure the reports, the information the reports should contain (e.g., patient
Reports For Marketed Drugs exposure), and some considerations around the need to track and report events internationally. It is rather more applicable to the processes around
managing AE data than the data structure and variables themselves.

DRAFT 2008-04-03
ICH E3: Structure and Content of Clinical References to AE analysis and reporting appear in several sections of E3. Section 12.2 addresses the requirements most specifically.
Study Reports
• Section 9: discusses rating AEs in terms of severity or relationship to drug. It also states that the report should define how consistency in
applying the ratings was achieved between sites. Be clear in defining the severity and relationship categories, and include the definitions in
CRF completion guidelines.
• Section 12.2: provides a fairly detailed description of the kinds of safety summaries that must be conducted for AEs. These include
summarization of AEs by body system, by intensity if used, by relationship to treatment if collected, and by treatment emergence.
Summaries should include lab findings and vital signs changes identified as AEs. Even if AEs are categorized by relationship and/or
treatment emergence, all AEs should be included in the summaries. Although E3 does not require that relationship to study drug be
captured, the EU Directive on AEs (April 2006) does require it. There must be a way to determine treatment emergence (both for increases
in severity and in frequency). Labs and vital signs must be mergeable with AEs data, or somehow accessible.
• Section 12.2.3: describes the general analysis approach for AEs, including examination of relationship to dosage level if that seems
appropriate. This implies that the data must include dosage dates and levels, and AE dates and severities.
• Section 12.2.4: provides a list of variables that must be included in AE listings (i.e., that need to be collected). These include typical AE
variables, as well as study drug treatment data and concomitant treatment data and assessment of seriousness. Note that while the FDA does
not require listings of AE data if AE data have been provided electronically, ICH guidelines do still request these.
• Section 12.3: Discusses the display of Deaths & other Serious Adverse Events (SAEs); they should be split out and discussed separately, in
the report, but essentially the same data are required for display. Additionally, it requires that “significant” AEs be split out, i.e., AEs that
were not serious, but required some significant concomitant therapy or intervention. This implies that AEs requiring significant concomitant
treatment (either pharmacological or non-pharmacological) be specifically identifiable.
ICH E6 (R1): Good Clinical Practice • 1.2: Defines “Adverse Event”

• 4.11: Investigator responsibilities for reporting safety issues to sponsors, specifically SAEs, Lab AEs and AEs of special interest in a
particular protocol
• Most of the rest of GCPs have more to do with actions around data, rather than the data themselves.
• 5.16: Sponsor responsibilities for ongoing review of safety information; notification of investigators.
• 5.17.1 and 5.17.2: Spell out the sponsor’s regulatory responsibility to report all serious and unexpected AEs to IRBs, investigators and
regulatory authorities in accordance with ICH E2A, Clinical Safety Data Management
• 5.17.3: Sponsor responsibilities of periodic safety updates to regulatory authorities.

DRAFT 2008-04-03
ICH E9: Statistical Principles for Clinical This guidelines in fairly general in its observations, but provides some insight into regulatory expectations.
Trials
• Section VI: Evaluation of Safety and Tolerability: Contains considerable discussion about appropriate approaches to the analysis and
reporting of safety data, including summarizing by severity, onset and duration of AE, as well as potential subpopulation analyses (e.g., sex,
age)
• Section VII: Reporting – provides a supplement to the info contained in E3.
FDA Guidance for Industry: Premarketing Provides guidance on approaches to evaluating a drug’s risk profile. While much of it focuses on pooled data and guidelines for pooling data,
Risk Assessment there are implications for individual studies, particularly in terms of coding, and the analysis of temporal relationships of drugs and AEs.
• Section VI.A.1., Accuracy of Coding: provides recommendations around coding AEs, and ensuring appropriate coding.
• Section VI.B, Analyzing Temporal or Other Associations: discusses the importance of being able to determine the timing of AEs both
relative to treatment dates as well as to length of exposure to treatment. This emphasizes the need to capture complete and accurate event
dates.
• Section VI.G, Long-term Follow-up: discusses the need to determine what an appropriate follow-up period is for AE collection, and suggests
that this should be discussed with regulatory authorities, potentially during end-of-Phase-2 meetings. This should drive the cut-off point for
collecting AEs for a study, and how long the database needs to remain open for adding AEs after the study is completed.
• Section VI.H, Important Aspects of Data Presentation: this is a supplement to the ICH E3 guidelines, and it covers additional analyses to be
considered. Particularly, it states that for subjects who died during the study, the official CRF should contain copies of hospital records,
autopsy reports, biopsy results, and any other pertinent information. This doesn’t necessarily mean this information must be specifically
collected on sponsor-generated CRFs, but that copies of this information should be stored with the rest of the subject data, and be
appropriately indexed and referenced.
CFR 21 CFR Part 312 – Investigational • 312.32: Safety reports following IND submissions: defines “serious” and the terms that are used in the definition. Describes what the reports
New Drug Application should contain; defines ‘associated’, ‘expected’ and ‘unexpected’ adverse drug reactions
• 312.33.3b Section 1 through 4: Annual reports to INDs related to safety information. May require the production of interim safety summaries
and reports which may affect the way the data capture tools are structured.
• (doesn’t really apply to what data should be captured)312.64: refers to investigator’s responsibility to report events that are probably or
possibly related to the treatment. Implies an assessment of causality by the investigator
CFR 21 CFR Part 803 – Devices 803.32: provides a list of variables to be collected and reported by user facilities for individual adverse event reports related to medical devices
803.42: provides a list of adverse event-related variables that must be reported for individual safety reports by importers of medical devices
803.52: provides a list of variables to be collected and reported by device manufacturers for individual adverse event reports related to medical
devices
Note: these references apply to most if not all the domains covered in this document.

DRAFT 2008-04-03
NCI CTEP Guidelines, Adverse Event A document produced by the National Cancer Institute’s Cancer Therapy Evaluation Program. It provides definitions for terms used in reporting
Reporting Requirements AEs, lists the information that should be included when reporting different kinds of AEs resulting from different kinds of treatments for cancer
(e.g., marketed, pre-registration). These requirements are somewhat different from those for other types of diseases, due in part to the severity of
the disease and the toxicity of the treatments. Among other information, it includes the definitions for AE Grades that are used in oncology in
place of severity assessments.
ICH E3, Structure and content of a Clinical Sections 12.3.1, 12.3.2 and 12.3.3: Deaths are to be analyzed and presented separately from other data. Deaths occurring both during the study as
Study Report well as during the post treatment follow-up period are to be included. The guideline includes a description of what the subject narrative must
discuss, including a list of data points. In the list of appendices, the guidelines indicate that CRFs for subjects who died must be submitted. This
implies that death data must be either collected for all studies on CRFs or on the serious AE collection instruments.
ICH E2A, Clinical Safety Data The description of the information required for expedited reporting of serious adverse events outlines further information that may be required to
Management : Definitions and characterize deaths, including items such as allergy, drug or alcohol abuse; family history; findings from special investigations. An autopsy or
Standards for Expedited Reporting, other post mortem findings must be included when available. This may have implications for data to be collected in every study.
Attachment 1, Section 4, page 10 (Nov
1994)
ICH E6 Consolidated Good Clinical • Section 1.50 - Definition of SAE

Practices
• Section 4.11.3 - Investigator responsibilities in regards to death reports
• Section 5.16 - Sponsor responsibilities for safety review
CFR 21 CFR 314.80 - Post marketing Definition of SAE.

reporting of adverse drug experiences
EC European Commission: Detailed Presents extensive information on expedited reporting of serious AEs. It is very similar to ICH E2A and E2B, although it provides somewhat
guidance on the collection, verification more specificity in places. It doesn’t define requirements for any additional data, but rather clarifies roles and responsibilities, and timelines for
and presentation of adverse reaction reporting.
reports arising from clinical trials on
medicinal products for human use,
ENTR/CT3 April 2006.

DRAFT 2008-04-03
APPENDIX C2: Concomitant Medications (CM)
General Notes: One of the primary roles of concomitant medications data is to assist in the identification of significant non-serious adverse events (AEs), which are
AEs for which significant therapy was instituted but that did not meet the criteria for “serious”. Significant AEs should be identified and discussed
separately in the clinical study report. This implies an ability in the data to link the medications taken to the AE(s) for which they were taken.
ICH E3, Structure and Content of Clinical • Section 9.4.7., Prior and Concomitant Therapy: This part of the guideline states that allowed prior and concomitant drugs or procedures should
Study Reports be discussed in the report, and an assessment of their potential impact on study endpoints should be addressed.
• Section 10.1, Disposition of Subjects: States that it may be useful for the listings of subjects who discontinued the study early to include
additional information, including concomitant medications
• Section 10.2, Protocol Violations: Subjects who had protocol violations should be summarized in the report text by the type of violation. One
type specifically mentioned is subjects who received excluded concomitant treatment.
• Section 11.2, Demographic and Other Baseline Characteristics and 11.4.3, Tabulation of Individual Response Data: Concomitant medications
should be presented for all subjects in by-subject tabular listings. There are some specific recommendations for presentations in these sections.
• Section 12, Safety Evaluation: In the introduction to this section, the guideline states that “Significant Adverse Events” (as distinct from SAEs)
should be identified. This is defined as AEs that resulted in an intervention such as dose withdrawal or reduction, or significant additional
concomitant therapy, which is understood to include both non-pharmacological interventions and non-study medications.
• Section 12.2.4., Listing of Adverse Events by Subject: In the section that describes the information that should be presented in by-subject
adverse events listings, variables listed include “concomitant treatment during study” and the list of example answers for “Action Taken”
includes “specific treatment instituted.”
• Section 12.3.1.3, Other Significant Adverse Events: States that significant AEs, other than those listed as SAEs, should be listed as well.
• Section 12.6, Safety Conclusions: Overall safety discussion should pay particular attention to events requiring interventions, especially
administration of concomitant medications
FDA Guideline For The Format And There are a number of references to concomitant drugs and other therapies in this guideline. Below are the ones that most clearly impact decisions
Content on the data to collect for a trial.
Of The Clinical And Statistical • Section G.2.e, Integrated Efficacy, Subset analyses: concomitant medications are included in the list of parameters to be used for subset
Sections Of An Application efficacy analyses
• H.4.i.3.b., Drug/Drug Interactions in the ISS: Specifically states that the concomitant therapies used in all studies should be listed, along with
the numbers of subjects using each concomitant drug

DRAFT 2008-04-03
APPENDIX C3: Demography (DM)
FDA Guidance for Industry Collection of • Outlines the FDA’s approach to collecting and categorizing race and ethnicity data
Race and Ethnicity Data in Clinical
Trials • Strong recommendation to collect self-reported race, with selections of “White” “Black” “Native American & Alaska native” “Hawaiian or
Pacific Islander” “Other” “Other specify”.
• If more detailed characterizations of race or ethnicity are collected to enhance data quality and consistency, it is recommended that they be
“collapsible” up to the five minimum designations for ethnicity, as needed for reporting to FDA under its guidance. When more detailed
categorizations are desired, the use of race and vocabulary tables located within Health Level Seven’s Reference Information Model Structural
Vocabulary Tables is recommended, as they are designed to collapse up in this manner. Ethnicity is optional, and when collected should be a
separate field from race. As outlined, it is primarily for identifying Hispanic vs non-Hispanic
This regulation remains extremely US-centric, and studies conducted elsewhere may need to adapt codes as necessary. For studies where race
and/or ethnicity are expected to be a focus of analysis, a more specific approach should be developed.
FDA Guideline For The Format And The Format and Content of the Full Integrated Clinical and Statistical Report of a Controlled Clinical Study, Pg 74: The need to display sex, date
Content of birth and race is referenced in numerous sections of this guidance, including listing safety information for each subject.
Of The Clinical And Statistical
Sections Of An Application
ICH E.2.B, Clinical Safety Data Part B.1: Defines demography information to be included with SAE reports
Management
Data Elements for Transmission of
Individual Case Safety Reports
ICH E3, Structure and Content of Clinical • Section 11.2:- Demographic & other baseline characteristics, States that demography variables are usually expected.
Study Reports
• Sections 8, 12 & 14: various sections state requirement that key efficacy and safety data be presented broken down by various demographic
variables
ICH E5 Guidance on Ethnic Factors in the Guidance discusses what kinds of factors may affect drug efficacy and sensitivity, and defines ethnicity vs race. It does not include any specifics
Acceptability of Foreign Clinical Data about race, but provides a good summary of what characterizes ethnicity, how to consider it in evaluating a drug, and what it is most likely to
affect.

DRAFT 2008-04-03
APPENDIX C4: Disposition (DS)
ICH E3, Structure and Content of Clinical Section 10.1 Disposition of Subjects: Specifically states the need to account for each subject randomized, and to summarize and discuss early
Study Reports withdrawals. An appendix provides an example of a flowchart showing the numbers of subjects who progressed through each phase of the study.
This implies that there must be a way of assessing how many screen failures there were (could bring screen fail CRFs in-house and enter), as well
as specifically tracking the number of subjects completing each phase. Easiest way to do this is usually to require that there be a CRF completed
specifying the status of the subject at the termination of the phase.

DRAFT 2008-04-03
APPENDIX C5: Drug Accountability (DA)
ICH E3, Structure and Content of Clinical • Section 9.4.8 Treatment Compliance: states that the means of assessing compliance should be presented, including if it involved drug
Study Reports accountability
ICH E6 Good Clinical Practices • Section 4.6 Investigational Products: outlines the many responsibilities the investigator has for ensuring investigational substances are securely
stored and handled, access is restricted to authorized individuals, and appropriate records are maintained that track the location and disposition
of all test article from the time it is received by the site to the time it is dispensed to the subject (with any remaining test article returned),
returned to the sponsor or destroyed. All test article must be accounted for.
• Section 6.4.7 Protocol Design: methods for ensuring accountability for all test article must be defined in the protocol
• Section 8 Essential Documentation: includes shipping records, dispensing and retrieval records, documentation that the test article has been
used in accordance with the study protocol, and “To document the final accounting of investigational product(s) received at the site, dispensed
to subjects, returned by the subjects, and returned to sponsor”
FDA Guidance for Industry: Guideline for • Monitors are required to inspect clinical sites prior to initiating the study to ensure that the investigator understands the obligations they have
the Monitoring of Clinical with respect to controlled handling of the test article
Investigations
FDA Compliance Program Guidance • 14.1.1 Compliance Program 7348.811, Bioresearch Monitoring: Clinical Investigators: Extensive instructions on how inspectors should verify
Manual for FDA Staff who has access to the test article and that proper and controlled storage conditions were in place, associated shipping records, control and
documentation of test article dispensed to and retrieved from the subjects and returned to the sponsor or destroyed, whether the amount of test
article at the site roughly corresponds to the amount expected given the number of subjects and the dosing schedule,
CFR 21 CFR 312.57 & 59 • Recordkeeping and record retention: discussed the requirements around investigators maintaining adequate records showing the receipt,
shipment, or other disposition of the investigational drug. These records are required to include, as appropriate, the name of the investigator to
whom the drug is shipped, and the date, quantity, and batch or code mark of each such shipment.
• Disposition of unused test article: the sponsor is responsible for ensuring that all test article is accounted for, and shall maintain written records
to that effect.

DRAFT 2008-04-03
APPENDIX C6: ECG Test Results (EG)
ICH E14. The Clinical Evaluation Of These quotes are taken directly from the guidance, and define the requirement for ECG data for general clinical trials
QT/QTc Interval
2.2 The ‘Thorough QT Study’:
Also referred to as the EMEA QT/QTc
guidance. The ‘thorough QT/QTc study’ would typically be conducted early in clinical development to provide maximum guidance for later trials, although
the precise timing will depend on the specifics of the drug under development. It would usually not be the first study, as it is important to have
basic clinical data for its design and conduct, including tolerability and pharmacokinetics. Some drugs might not be suitable for study in healthy
volunteers because of issues related to tolerability (e.g., neuroleptic agents, chemotherapeutics).
The results of the ‘thorough QT/QTc study’ will influence the amount of information collected in later stages of development:
• A negative ‘thorough QT/QTc study’ will almost always allow the collection of on-therapy ECGs in accordance with the current practices in
each therapeutic area to constitute sufficient evaluation during subsequent stages of drug development (see section 2.3);
• A positive ‘thorough QT/QTc study’ will almost always call for an expanded ECG safety evaluation during later stages of drug development (see
section 2.3).
There could be very unusual cases in which the ‘thorough QT/QTc study’ is negative but the available nonclinical data are strongly positive (e.g.,
hERG positive at low concentrations and in vivo animal model results that are strongly positive).
3. ANALYSIS OF ECG DATA FROM CLINICAL TRIALS
Evaluation of the effects of a drug on the standard ECG intervals and waveforms is considered a fundamental component of the safety database of
any new drug application.
Regardless of the outcome of the ‘thorough QT/QTc study’, ECG changes recorded as adverse events should be pooled from all studies for
analysis. ECG interval data from the ‘thorough QT/QTc study’ should only be pooled with subsequent trials of similar rigor with regard to ECG
data collection and analysis, but should not be pooled with trials using less rigorous ECG collection. Standardization of ECG collection for similar
studies within a clinical trial programmer will facilitate pooled analyses.
The guidance also provides an outline of what the agencies expect with respect to the collection, presentation and analysis of ECGs.

DRAFT 2008-04-03
APPENDIX C7: Exposure (EX)
ICH E3, Structure and Content of Clinical Section 12.1, Extent of Exposure: specifies that the CSR should characterize each subject population with respect to the duration of exposure, the
Study Reports dose, and, if available, the drug concentration (i.e., Cmax). This applies to exposure to placebo and active control as well as study medication.
This verbiage is virtually identical to E1, Extent of Population Exposure to Assess Clinical Safety.
In order to assess Exposure appropriately, compliance must be gauged.
ICH E4, Dose-response Information to Discusses various trial designs and various ways of assessing exposure and its relationship to efficacy and to safety issues. The implication of this
Support a Drug Registration guidance to study design is that the right data should be collected to allow for fairly specific and detailed analyses of exposure, dose, duration and
concentration.
It is important to note that compliance is not the same as drug accountability. Compliance speaks to whether the subject took the study
medication as required by the protocol. Drug accountability means the ability to account for all the study medication, whether or not the subject
took it. Generally, drug accountability records are a poor way of assessing compliance or exposure.

DRAFT 2008-04-03
APPENDIX C8: Inclusion / Exclusion (IE)
SOURCE REGULATION/GUIDELINE DESCRIPTION
ICH E3 Structure and Content of a Clinical Section 9.3 Selection of Study Population - States that the criteria that subjects had to satisfy in order to enter the trial must be described (e.g.,
Study Report, diagnostic criteria, demographic criteria), and any safety or other factors used to exclude subjects must be laid out and discussed. If there is reason
to believe that there might have been systematic bias on the part of the investigator (e.g., not entering the sickest subjects), this must be described
and its potential effects discussed.
ICH E6, Good Clinical Practices Section 6.5.1 and 6.5.2: Subject inclusion and exclusion criteria must be specified in the protocol
CFR 21 CFR 312.42 Discusses some eligibility issues that may incur "clinical holds" for studies that are planned or already in progress. These primarily involve
studies where the selection of subjects may inappropriately exclude certain groups, such as people of reproductive potential.

DRAFT 2008-04-03
APPENDIX C9: Laboratory Test Results (LB)
ICH E3, Structure of the Clinical Study • Section 12, Safety Evaluation: Laboratory results are expected to be presented along with AEs, concomitant medications and other data that
Report assess the basic safety profile of the drug
• Section 12: laboratory results are one of the criteria for identifying significant non-serious AEs
• Section 12.1, Extent of Exposure: CSR is expected to present analyses of drug concentration in relationship to abnormal lab parameters, if seen
• Section 12.2.2.2, Adverse Events: significant lab abnormalities are expected to be presented along with other AEs
• Section 16.1.10, Appendices, Study Information: states that there should be documentation of inter-laboratory standardization methods and
quality assurance procedures if used
ICH E9, Statistical Principals • Section 6.2: states that lab values, along with vital signs and AEs, are expected to form the main body of evidence as to the safety of the drug

DRAFT 2008-04-03
APPENDIX C10: Medical History (MH)
ICH E2B Data Elements for Transmission Section B.1.7., Relevant Medical History: Medical history is listed as one of the elements that must be included in the evaluation and
of Individual Safety Case Reports communication of expedited safety event reports. The User Guidance suggests that medical judgment must be used in determining what to record
– focus on the findings that are at all likely to have a bearing on the event, rather than an exhaustive list of all observations. This suggests that if
there are specific medical history conditions of interest they might be best captured by asking specific questions, rather than relying on a general
list.
ICH E3 Structure & Content of a Clinical • Section 11.2, Demographic and Other Baseline Characteristics: Describes the information that must be included as part of the general
Study Report characterization of comparative groups. It includes “relevant previous illness”, which refers to diseases other than that under study. This is
another term for “Medical History.”
• Section 11.4.5, Drug-Drug and Drug-Disease Interactions: states that relationships between subject response and prior illness must be
described. This does not necessarily imply that medical history must capture an exhaustive list of prior conditions; it may be appropriate to
focus on particular conditions or classes of condition.
• Section 12.3.2. Narrative of Deaths, Serious AEs: “previous illness” is an element that must be addressed in characterizing serious adverse
events.
ICH E6 Consolidated Good Clinical Section 8.3.13 Source documents - To document the existence of the subject and substantiate integrity of trial data collected. To include original
Practices documents related to the trial, to medical treatment, and history of subject.

DRAFT 2008-04-03
APPENDIX C11: Physical Examination (PE)
ICH E3, Structure and Content of Clinical Section 12.5, Vital Signs, Physical Findings and Other Observations Related to Safety - Physical findings must be analyzed and displayed in the
Study Reports same manner as lab values. If any apparent relationship to dose effect or other response was observed, this must be discussed.
FDA Premarketing Risk Assessment (2005) Section VI H, Important Aspects of Data Presentation - States that physical exam findings are a useful part of the subject narratives associated
with serious adverse events
The ICH E3 guideline states that physical examination data should be analyzed and presented in the same manner as laboratory data. The approach recommended by
CDASH as the best practice still accomplishes the ultimate goal of assessing the impact of physical exam findings on the treatment’s safety profile. The best practice
recommends that physical findings, e.g. abnormalities, be reported as adverse events or medical history findings. Adverse events are extensively analyzed and medical
history data are available for reference and as a result there is no loss of safety information.
There are several reasons for the CDASH recommendation.

• When capturing physical exam findings, sites are instructed to record any clinically significant findings on the Medical History or AE CRF. Collecting these
findings as part of the Physical Exam domain as well amounts to double collection of data, which runs counter to the CDASH best practices.
• AE data are already extensively analyzed, and Medical History data are available for reference. Analyzing physical exam findings as well would add little to this
information.
• There are currently no dictionaries that are suitable for coding physical exam findings, and by extension Medical History findings, such that they are comparable to
AEs coding. This can result in conflicting analysis results, which may be difficult to resolve and not add to the clarity of the safety profile.
• If the intent in summarizing physical findings like lab findings is to produce shift tables, this implies a comparison to baseline. This can be accomplished if
baseline data are coded, which, as is noted above, is challenging whether they are captured as physical exam or medical history findings. AE data capture this as
part of the definition of an AE is a condition that worsens after treatment begins.
• If there is a desire to assess if particular baseline conditions affect study outcomes or safety profiles, neither physical exam data nor medical history data as
generally collected are suitable, as they are both open ended structures. To be useful, the specific conditions should be listed and assessed so that the study can
designed appropriately and proper analyses can be conducted.

DRAFT 2008-04-03
APPENDIX C12: Protocol Deviations (DV)
ICH E3, Structure and Content of Clinical Section 10.2 Protocol Deviations - requires the reporting of protocol deviation information ‘related to study inclusion or exclusion criteria,
Study Reports conduct of the trial, patient managements or patient assessment’ within the body of the text and patient data listings.
CFR 21 CFR Part 812 – Investigational 812.140 Records – requires a participating investigator to maintain documentation of the dates of, and reasons for, deviating from the protocol.
Device Exemptions

DRAFT 2008-04-03
APPENDIX C13: Substance Use (SU)
ICH E2A: Clinical Safety Data Attachment 1, Section 4, Details of suspected adverse drug reaction: includes history of drug or alcohol abuse as information that may help in
Management: Definitions And characterizing potential AEs.
Standards For Expedited Reporting
ICH E3: Clinical Study Report Section 9.5.4, Drug Concentration Measurements: mentions that assessments of study drug concentrations should take into account characteristics
that may affect it, such as concomitant medication/alcohol/caffeine/nicotine, among others.
ICH E5: Acceptability of Foreign data Refers to alcohol and tobacco usage as “extrinsic” ethnic factors that may be relevant when studying a drug in a different population.
ICH E11: Pediatric Studies Section 2.5.5 Adolescents (12 to 16-18 years (dependent on region)): encourages the examination of recreational use of drugs, alcohol and tobacco
when doing studies in this population.

DRAFT 2008-04-03
APPENDIX C14: Vital Signs (VS)
FDA Premarketing Risk Assessment • Section VI F, Rigorous Ascertainment of Reasons for Withdrawals from Studies: a detailed analysis of all withdrawals should be conducted,
especially for those that withdrew due to changes that may not be captured as adverse events, such as ECGs or vital signs.
• Section VI H, Important Aspects of Data Presentation: States that adverse events important to a drug class should be comprehensively analyzed
in the integrated summary of safety, along with relevant ancillary information such as vital signs.
FDA MAPP (Manual of Policies and • Section 7.2.5, Adequacy of Routine Clinical Testing: Vital Signs monitoring is considered to be one of the key indicators of whether good
Procedures) for the Evaluation of quality clinical care was provided to subjects in trials in an NDA.
NDAs
ICH E3, Structure and Content of Clinical • Section 12.2.2., Display of Adverse Events: states that changes in vital signs considered relevant to adverse events should be displayed with the
Study Reports AEs.
• Section 12.5, Vital Signs, Physical Findings and Other Observations Related to Safety: Vital Signs should be analyzed and displayed in the
same manner as lab values. If any apparent relationship to dose effect or other response was observed, this should be discussed.
ICH E9 Statistical Principles for Clinical Section 6.2, Choice of Variables and Data Collection: Vital Signs are listed as one of the items that generally contribute to the body of evidence
Trials characterizing safety.

DRAFT 2008-04-03
APPENDIX D: CDASH Project Team
APPENDIX D1: CDASH Core Team
Following is a list of the CDASH management (Core) team members:
Team Leader Affiliation Email Address Team / Responsibility
Rhonda Facile CDISC rfacile@cdisc.org Project Director
Paul Bukowiec Millennium Pharmaceuticals Paul.Bukowiec@mpi.com Physical Exam & Vital Signs
Dorothy Dorotheo Intermune, Inc. and SCDM DDorotheo@intermune.com Concomitant Medications
Kit Howard Kestrel Consulting kit@kestrelconsultants.com References
Shannon Labout CSS Informatics and SCDM shannon.labout@csscomp.net Inclusion/Exclusion, Best Practice
Jay Leeka AstraZeneca Jay.Leeka@astrazeneca.com Comments & Protocol Deviations
Liz Nulton-Bodiford GlaxoSmithKline liz.m.nulton-bodiford@gsk.com Drug Accountability & Exposure, Best Practice
Holly Peterson Forest Laboratories Holly.peterson@frx.com Adverse Events
Cathy Schleuning Schwarz BioSciences/UCB cathy.schleuning@ucb-group.com Editor
Lauren Shinaberry PRA International ShinaberryLauren@PRAIntl.com ECG
Trisha D. Simpson Schwarz BioSciences/UCB Trisha.Simpson@ucb-group.com Medical History & Substance Use
David Tatum Eli Lilly & Co./Consultant tatum4@comcast.net Adverse Events
Kim Truett KCT Data, Inc. Kim.Truett@kctdm.com Lab
Alec Vardy CV Therapeutics/Consultant Alec.Vardy@cvt.com Disposition/ End of Study
Gary Walker Quintiles gary.walker@quintiles.com Demographics & Subject Characteristics

DRAFT 2008-04-03
APPENDIX D2: Participating Companies
The CDASH project was started in October of 2006 with an open meeting in Cary, NC. This project was
initiated with an “all comers welcome” approach. There was a public call for volunteers which resulted in
approximately 80 attendees at the kick-off meeting. During the development process over 190 volunteers
representing all aspects of the drug development process (Industry, CROs, eVendors, Government and
Academia) participated on the CDASH project. Involvement from international organizations was actively
sought and encouraged. The following European organizations have reviewed and commented on CDASH
drafts: The Association of Clinical Data Management (ACDM), the International Network of Clinical Data
Management Associations (INCDMA), the French Association for Statistics and Data Management (DMA),
and the Dutch Association for Statistics and Data Management (PSDM). Representatives from the following
countries either participated in CDASH teams and/or commented on domain drafts: Belgium, Denmark, France,
Germany, Japan, Sweden, The Netherlands and the United Kingdom.
Due to the nature of a volunteer effort, there have been changes in both the membership of the teams and the
degree of participation over the 1.5 year course of this project. As a result we have listed only the company
affiliation. Participating companies appear in alphabetical order.
Participating Companies
1. Abbott 32. Eisai Global Clinical Development

2. Accenture 33. Eli Lilly and Company
3. Accovion GmbH 34. Enzon Pharmaceuticals, Inc.
4. AdvaMed 35. Ethicon (Johnson & Johnson)
5. Amgen 36. Fast Track Systems
6. ArisGlobal, LLC 37. Forest Laboratories, Inc.
7. Astelles Europe BV 38. Genentech, Inc.
8. Astellas Pharma Inc. 39. Genzyme Corp.
9. AstraZeneca 40. Gilead Colorado, Inc.
10. Bausch & Lomb 41. GlaxoSmithKline
11. Baxter 42. Global Research Services, LLC
12. Biogen Idec 43. Harvard Clinical Research Institute
13. Biopharma Data Services 44. Health Decisions
14. Boehringer Ingelheim 45. HealthRoad Co. Ltd,
15. Boston Scientific Corporation 46. ICON Clinical Research
16. Bristol-Meyers Squibb 47. ImClone Systems Incorporated
17. Brown University 48. Insmed Incorporated
18. Building Points of View 49. InterMune, Inc.
19. Cambridge Cognition 50. Johnson & Johnson
20. Cleveland Cinic (CCF) 51. Kai Research
21. Cephalon 52. KCT Data, Inc.
22. CliniPharma Consulting 53. Kos Pharmaceuticals, Inc.
23. Cognizant Technology Solutions 54. Lab Connect LLC
24. Commitum AB 55. Kestrel Consultants
25. Covidien (formerly Tyco Healthcare/Mallinckrodt) 56. Medidata
26. CV Therapeutics 57. Medifacts
27. Daedalus Software, Inc 58. Merck & Company
28. DataScene 59. Millennium Pharmaceuticals, Inc.
29. CSS Informatics 60. MRL, Merck & Co., Inc.
30. DataLabs 61. National Cancer Institute - Center for Bioinformatics
31. Duke Clinical Research Institute 62. NCI Cancer Therapy Evaluation Program

DRAFT 2008-04-03
63. NCI-caBIG 88. Rho Inc.

64. NCI Enterprise Vocabulary Services 89. RTI International
65. Nextrials, Inc. 90. Schering-Plough Corporation
66. NIH Office of Biotechnology Activities (OBA) 91. Schwarz BioSciences
67. Novartis Pharmaceuticals Corporation 92. SpaceLabs Healthcare
68. Nounsware Company 93. Statistics & Data Corporation
69. Octagon Research Solutions 94. Stellar Systems
70. Ofni Systems Inc. 95. Synteract, Inc
71. Omnicare 96. TAKE Solutions Inc.
72. Oracle Health Sciences 97. Takeda Global Research & Development Centre
73. Organon (Europe) Ltd.
74. Othera Pharmaceuticals, Inc 98. Teva Neuroscience
75. PAREXEL International 99. The University of Texas Health Science Center at
Houston
76. Percipenz
100. Tyco Healthcare Mallinckrodt
77. Pfizer, Inc.
101. UCB Pharma SA
78. PharmaNet, Inc
102. University of California, Irvine
79. Phoenix Data Systems
103. University of Pennsylvania School of Medicine
80. PHT Corp
104. University of Utah College of Nursing
81. PPD
105. University of Utah Health Science Center
82. PRA International
106. Wake Forest University Baptist Medical Center
83. Procter & Gamble
107. Westat Inc.
84. PTC Therapeutics
108. Wyeth Inc.
85. QIMR
109. ZymoGenetics
86. Quintiles Transnational
87. Regeneron

DRAFT 2008-04-03
APPENDIX E: List of Abbreviations
To be added prior to production.

DRAFT 2008-04-03
APPENDIX F : Acknowledgements
CDISC wishes to thank the Collaborative Group and all the companies that have generously donated their
resources in staff, time and other forms of support to the CDASH project.
The CDASH project team would also like to thank all CDISC standards teams for their cooperation and
collaboration in reviewing the CDASH drafts in accordance with the CDISC COP-001.

DRAFT 2008-04-03
APPENDIX G: Revision History
None.

DRAFT 2008-04-03
APPENDIX H: Representation and Warranties; Limitations of Liability, and Disclaimers
CDISC Patent Disclaimers. It is possible that implementation of and compliance with this standard may require
use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect
to the existence or validity of any claim or of any patent rights in connection therewith. CDISC, including the
CDISC Board of Directors, shall not be responsible for identifying patent claims for which a license may be
required in order to implement this standard or for conducting inquiries into the legal validity or scope of those
patents or patent claims that are brought to its attention.
Representations and Warranties. Each Participant shall be deemed to represent, warrant, and covenant, at the
time of a Contribution by such Participant (or by its Representative), that to the best of its knowledge and
ability: (a) it holds or has the right to grant all relevant licenses to any of its Contributions in all jurisdictions or
territories in which it holds relevant intellectual property rights; (b) there are no limits to the Participant’s ability
to make the grants, acknowledgments, and agreements herein; and (c) the Contribution does not subject any
Contribution, Draft Standard, Final Standard, or implementations thereof, in whole or in part, to licensing
obligations with additional restrictions or requirements inconsistent with those set forth in this Policy, or that
would require any such Contribution, Final Standard, or implementation, in whole or in part, to be either: (i)
disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works (other
than as set forth in Section 4.2); or (iii) distributed at no charge, except as set forth in Sections 3, 5.1, and 4.2. If
a Participant has knowledge that a Contribution made by any Participant or any other party may subject any
Contribution, Draft Standard, Final Standard, or implementation, in whole or in part, to one or more of the
licensing obligations listed in Section 9.3, such Participant shall give prompt notice of the same to the CDISC
President who shall promptly notify all Participants.
No Other Warranties/Disclaimers. ALL PARTICIPANTS ACKNOWLEDGE THAT, EXCEPT AS

PROVIDED UNDER SECTION 9.3, ALL DRAFT STANDARDS AND FINAL STANDARDS, AND ALL
CONTRIBUTIONS TO FINAL STANDARDS AND DRAFT STANDARDS, ARE PROVIDED .AS IS.
WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR
OTHERWISE, AND THE PARTICIPANTS, REPRESENTATIVES , THE CDISC PRESIDENT, THE CDISC
BOARD OF DIRECTORS, AND CDISC EXPRESSLY DISCLAIM ANY WARRANTY OF
MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR OR INTENDED
PURPOSE, OR ANY OTHER WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, FINAL
STANDARDS OR DRAFT STANDARDS, OR CONTRIBUTION.
Limitation of Liability. IN NO EVENT WILL CDISC OR ANY OF ITS CONSTITUENT PARTS

(INCLUDING, BUT NOT LIMITED TO, THE CDISC BOARD OF DIRECTORS, THE CDISC PRESIDENT,
CDISC STAFF, AND CDISC MEMBERS) BE LIABLE TO ANY OTHER PERSON OR ENTITY FOR ANY
LOSS OF PROFITS, LOSS OF USE, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR
SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE,
ARISING IN ANY WAY OUT OF THIS POLICY OR ANY RELATED AGREEMENT, WHETHER OR
NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.
Note: The CDISC Intellectual Property Policy can be found at:

http://www.cdisc.org/about/bylaws_pdfs/CDISC%20IP%20Policy-FINAL.pdf.

DRAFT 2008-04-03

Cdash Draft Post Version

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cdash Draft Post Version

Uploaded by

Copyright:

Available Formats

CDISC CDASH (Draft Version 1.

Clinical Data Acquisition

Prepared by the CDISC CDASH Team

• This is the CDASH draft posted for public comment.

Date Version Summary of Changes

2008-04-03 Draft 1.0

CDISC © 2008. All rights reserved Page 1

3. Best Practice (General Recommendations and Observations Applicable to all

4. CDASH Domain Tables.............................................................................................. 17

CDISC © 2008. All rights reserved Page 2

APPENDIX B: Data Collection Variables Generally Considered Not Necessary

APPENDIX C: Regulatory References .............................................................................. 113

CDISC © 2008. All rights reserved Page 3

APPENDIX D: CDASH Project Team ................................................................................. 131

APPENDIX E: List of Abbreviations.................................................................................. 134

APPENDIX F : Acknowledgements ................................................................................... 135

APPENDIX G: Revision History......................................................................................... 136

APPENDIX H: Representation and Warranties; Limitations of Liability,

CDISC © 2008. All rights reserved Page 4

CDISC © 2008. All rights reserved Page 5

• National Institutes of Health (NIH)

Adverse Events (AE) Inclusion and Exclusion Criteria (IE)

Comments (CO) Lab (LB)

Concomitant Medications (CM) Medical History (MH)

Demographics (DM) Physical Examination (PE)

Disposition (DS) Protocol Deviations (DV)

Drug Accountability (DA) Subject Characteristics (SC)

ECG (EG) Substance Use (SU)

Exposure (EX) Vital Signs (VS)

CDISC © 2008. All rights reserved Page 7

3. Best Practice (General Recommendations and Observations

3.2. Core Designations for Basic Data Collection Variables

3.3. Introduction to Best Practices

CDISC © 2008. All rights reserved Page 8

3.4. Recommended Methodologies for Creating Data Collection Instruments

Ref Methodology Rationale

Ref Methodology Rationale

CDISC © 2008. All rights reserved Page 10

Start planning Suggested CRF Development Workflow

CDISC © 2008. All rights reserved Page 11

Ref Question CRF Type Best Practice Recommendation Rationale

CDISC © 2008. All rights reserved Page 12

Ref Question CRF Type Best Practice Recommendation Rationale

CDISC © 2008. All rights reserved Page 13

Ref Question CRF Type Best Practice Recommendation Rationale

CDISC © 2008. All rights reserved Page 14

3.6. Common Identifier Variables

CDISC © 2008. All rights reserved Page 16

4. CDASH Domain Tables

4.2. Explanation of Table Headers

CDISC © 2008. All rights reserved Page 17

4.3. Adverse Event – AE (Events)

CDISC © 2008. All rights reserved Page 18

CDISC © 2008. All rights reserved Page 19

CDISC © 2008. All rights reserved Page 20

CDISC © 2008. All rights reserved Page 21

CDISC © 2008. All rights reserved Page 22

CDISC © 2008. All rights reserved Page 23

4.4. Comments – CO (Special Purpose)

4.4.1. Solicited Comments

4.4.2. Unsolicited Comments

4.4.3. Considerations Regarding Usage of a General Comments CRF

CDISC © 2008. All rights reserved Page 24