1 Orientation

This implementation guide has been developed to assist in the following activities associated with the collection and compilation of data in a clinical trial.

1.1 Purpose

The Clinical Data Acquisition Standards Harmonization (CDASH) Model, the CDASH Implementation Guide (CDASHIG), and the CDASHIG Metadata Table define basic standards for the collection of clinical trial data and how to implement the standard for specific case report forms (CRFs). CDASH establishes a standard way to collect data in a similar way across studies and sponsors, so that data collection formats and structures provide clear traceability of submission data into the Study Data Tabulation Model (SDTM), delivering more transparency to regulators and others who conduct data review. The CDASH standard directly supports the production of clinical data collection instruments. Through this support, the standard also contributes to:

• Consistency and detail in representations of research protocol concepts
• Streamlined processes within medical research
• Development of a corporate library of standardized CRFs
• Use of metadata repositories
• Reporting and regulatory submission
• Data warehouse population
• Data archiving
• Post-marketing studies/safety surveillance

There is growing recognition around the globe that industry standards promote data interchange, which is essential to effective partnering and information exchange between and among clinicians and researchers. Clinical care can more easily reap benefits through medical research findings, and more clinicians will be interested in conducting research if the research process can be integrated into their clinical care workflow. CDISC encourages the adoption of its global standards for clinical research, which should continue to be harmonized with healthcare standards, to provide a means for interoperability among healthcare and research systems such that medical research can support informed healthcare decisions and improve patient safety.

This document is intended to be used by persons involved in the planning, collection, management, and analysis of clinical trials and clinical data, including clinical investigators, medical monitors, clinical research associates (monitors), clinical research study coordinators, clinical data standards subject matter experts (SMEs), clinical data managers, clinical data and statistical programmers, biostatisticians, drug safety monitors, CRF designers, and others tasked with the responsibility to collect, clean, and ensure the integrity of clinical trial data. Although much of the language in this standard addresses development of (e)CRFs, the CDASH standard can also be leveraged for other data sources. The principles and the metadata presented here can be applied to eSource (also known as non-CRF) data such as vendors' electronic data transfer standards, ePRO data structures, and direct data acquisition from electronic healthcare record (EHR) systems.

1.2 Organization of this Document

This document has been organized into the following sections:

• Section 1, Orientation
• Section 2, How to Use the CDASH Standard
• Section 3, General Assumptions for Implementing CDASH
• Section 4, Best Practice Recommendations
• Section 5, Conformance to the CDASH Standard
• Section 6, Other Recommendations
• Section 7, Special-purpose Domains
• Section 8, General Observation Classes
• Appendices

1.2.1 General Notes

Throughout this document, a deliberate decision was made to use a variety of synonyms for various terms in order to reflect the fact that sponsors also use a variety of terms.

• Paper CRFs vs. electronic CRFs: The term CRF used throughout this document refers to both paper and electronic formats, unless otherwise specified.
• Fields vs. variables: Data collection fields refers to terms that are commonly on the CRF. Data collection variables refers to what is in a clinical database.
• Study treatment: The phrase study treatment has been used instead of investigational/medicinal product, study drug, test article, vaccine, study product, medical device, and so on, in order to include all types of study designs and products.
• Mechanisms for data collection: Different data collection mechanisms can be used to control how data are collected (e.g., tick boxes, check boxes, radio buttons, drop-down lists). For the purposes of this document, these terms are used interchangeably.

2 How to Use the CDASH Standard

2.1 The Three Components of the CDASH Standard

CDASH is composed of the CDASH Model and the CDASH Implementation Guide (CDASHIG), with its associated CDASHIG Metadata Table. A domain is a collection of data points related by a common topic, such as adverse events or demographics. CDASHIG domains are aligned with Study Data Tabulation Model Implementation Guide (SDTMIG) domains for beginning-to-end traceability.

2.1.1 CDASH Model

CDASH Model v1.1 provides a general framework for creating fields to collect information on CRFs and includes the model metadata, which shows the standard variables in the model. CDASHIG provides information on the implementation of the CDASH Model and includes the CDASHIG Metadata Table, which details additional specifications for data collection variables within each domain.

CDASH Model v1.1 provides root naming conventions for CDASHIG variables that are intended to facilitate mapping to SDTMIG variables. The variables defined in the CDASH Model follow the same "--XXXX" naming convention as the SDTM. The 2 dashes are replaced by the domain code when applied to create the CDASHIG variable. For example, --DOSFRQ is the CDASH Model variable name to for Dosing Frequency per Interval in the Interventions Class. When a domain abbreviation is applied (e.g., "CM"), CMDOSFRQ is the CDASHIG variable for the frequency of the concomitant medication use. The CDASH Model includes metadata for variables used in each of the SDTM general observation classes, Timing variables, Identifier variables, variables for Special Purpose domains, and domain-specific variables. See Section 3.5.1, CDASH Model, for specific information on this content.

2.1.2 CDASHIG

The CDASHIG provides general information on the implementation of CDASH standards. The CDASH standards include the CDASH Model and the CDASHIG, which includes the supporting CDASHIG Metadata Table. The informative content of the CDASHIG and the normative content metadata table comprise the CDASHIG and must be referenced together.

2.1.3 CDASHIG Metadata Table

The CDASHIG Metadata Table includes only those variables commonly implemented by a significant number of the organizations/companies that provided information/examples (e.g., Medical History, Adverse Events). Implementers can add appropriate variables to their CDASHIG domain using the associated General Observation class within the CDASH Model. The CDASHIG Domain Metadata illustrates the use of Question Text and Prompts employed by many sponsors. Implementers should reference the CDASH Model to see all available options for Question Text and Prompts for parameters and verb tenses that may be substituted.

2.2 CDASHIG Metadata Table Attributes

The CDASHIG Metadata Table attributes provide building blocks for the development of a case report form (CRF) and the underlying database or other data collection structure.

2.2.1 CRF and Data Management System Design Metadata

Certain metadata attributes are essential to CDASH conformance. Combined with the variable naming conventions discussed in Section 5.1, Conformance Rules, these metadata attributes will assist the designer of the CRF(s) and the underlying database structure to remain in conformance with the standard:

• Question Text (full sentence/question forms to prompt for data) OR Prompts (short phrases, often suitable as column headers, to prompt for data)
• CDISC Controlled Terminology lists and subsets of list values when applicable
• DRAFT CDASH Definition (to assist in understanding the purpose of each variable, which ensures proper usage and simplifies subsequent pooled data analyses)
• CDASHIG Core designations and implementation notes (which, when used together, can assist a designer in determining the complete set of data to be collected on a form)

2.2.2 SDTMIG Programming Metadata

Columns in the CDASHIG Metadata Table that will assist in developing programs to generate SDTM domain datasets from CDASHIG-compliant data include:

• Domain
• CDASHIG Variable
• Data Type
• SDTMIG Target
• Mapping Instructions
• Controlled Terminology Codelist Name
• Subset Controlled Terminology/CDASH Codelist Name
• Implementation Notes

2.2.3 Additional Metadata

Clear and consistent completion instructions for sites help to ensure collection of quality, reliable data, a critical factor in the development of high-quality pooled/submission data. The CDASHIG Metadata Table includes the Case Report Form Completion Instructions column to assist authors in creating this study-level documentation for instructing sites how to complete CRF fields.

2.3 CRF Development Overview

The key steps to developing CRFs using CDASH are as follows:

1. Each organization may maintain a corporate library of standardized CRFs. Determine the requirements for data domains from these (if applicable) or from the protocol data collection requirements for the study.

2. Review the domains published in the CDASHIG to determine which of the data collection domains and fields are already specified in the published domains.

3. As much as possible, the standard domains should be used to collect data in a manner that will be effective for data collection. Develop the data collection tools using these published, standard domains first.

4. During the development of CDASH-conformant collection instruments (e.g., CRFs, eCOA screens), the SDTMIG domain to which the collected data is to be mapped must be determined. The choice of the SDTMIG domain to use does NOT depend upon the mode of transmission, the methodology used to generate the data, the medium used to store the data, the person who recorded the data, nor the subject whom the data describes. The SDTMIG domain to be used impacts what CDASH variable names, question texts, prompts, controlled terminology, and so on, to use. CDASH suggests a format to be presented to the person entering the data, but it does not dictate any data structure in which to store the collected data (often referred to as a data management operational database).

Example 1: A study has meal consumption diary data captured via a subject-completed PRO. Another study also captures meal consumption data, but the subject takes a photo of the food prior to and after the meal, and sends the photos to a third party, which determines food consumption. Even though captured in a different way, the data from both studies will map into the SDTMIG ML (Meal Data) domain.

Example 2: A study where subjects have their blood samples sent to a central lab, which analyzes the samples and sends results to the sponsor via electronic data transfer. In a second study, the samples are analyzed locally and results are captured on a CRF. The laboratory results from both studies are stored in the SDTMIG LB (Laboratory Test Results) domain. CDASH recommends that dates be collected in an unambiguous format and suggests using the DD-MON- YYYY format. This defines the format to be presented to the person entering the data, but it does not define the electronic format in which to store the data. One system may store each date as a character field, another may store them as numeric values (e.g., an SAS date), and yet another as 3 separate fields formatted as day, month, and year. Each of these is a legitimate way to store the data collected.

5. Using the root variables and other CDASH metadata in the CDASH Model, add any additional variables that are needed to meet the requirements of data collection. Follow CDISC Variable Naming Fragment (see Appendix B, Glossary and Abbreviations) conventions, and CDASH root variable naming conventions where they exist (e.g., --DAT for dates, --TIM for times, --YN for prompts as described in the CDASH Model). Example: Replace "--" with the 2-character domain code that matches the other variables in the same domain. For example, to add the --LOC variable to a Medical History CRF, the domain code is "MH", so the variable would become "MHLOC" in that domain.

6. The Question Text and Prompt columns in the CDASH Model metadata provide different variations in the recommended text for asking the question on a CRF. For each question, the sponsor may elect to either use the Question Text or the Prompt on the CRF. Some text is presented using brackets [ ], parentheses ( ), and/or incorporating forward slashes. These different formats are used to indicate how the Question Text or Prompt may be modified by the sponsor.

a. The text inside the brackets provides an option on the verb tense of the question, or text that can be replaced with protocol-specific verbiage.

b. The text inside the parentheses provides options (e.g., singular/plural) or text that may be eliminated.

c. Text separated with a forward slash provides optional words that the sponsor may choose.

Example: The CDASH variable --PERF, from the CDASH Model, has the following Question Text and Prompt.

Question Text:

[Were any/Was the] [--TEST/ topic] [measurement(s)/test(s)/examination(s)/specimen(s)/sample(s)] [performed/collected]?

Prompt:

[--TEST/Topic] [Measurement(s)/Test(s)/Examination(s)/Specimen(s)/Sample(s)] [Performed/Collected]?

The sponsor wants to add a question to a CRF that asks whether a lab specimen was collected using a Yes/No response.

The sponsor selects the CDASH variable --PERF and adds the appropriate domain code. LBPERF Use either the Prompt or the full Question Text on the CRF.

Question Text: Was the laboratory specimen collected?

i. In the first set of brackets, the text option "Was the" is selected as the study required only 1 lab test to be performed. [Were any/Was the]

ii. In the second set of brackets, the text used is "laboratory" which is the topic of interest. [-- TEST/Topic (laboratory)]

iii. In the third set of brackets, the text option "specimen" without the optional "s" is selected. [measurement(s)/test(s)/examination(s)/specimen(s)/sample(s)]

iv. In the fourth set of brackets, the text option "collected" is selected. [performed/collected]

Prompt: Laboratory Specimen Collected

i. In the first set of brackets, the text used is the topic of interest (i.e., laboratory). [-- TEST/Topic (Laboratory)]

ii. In the second set of brackets, the text option "specimen" without the optional "s" is selected. [Measurement(s)/Test(s)/Examination(s)/Specimen(s)/Sample(s)]

iii. In the third set of brackets, the text option "collected" is selected. [Performed/Collected]

7. Create custom domains based on one of the General Observation Classes in the CDASH Model. See Section 3.4, How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined, for more information.

The CDASHIG Metadata Table attributes provide building blocks for the development of a CRF and the underlying database or other data collection structure.

3 General Assumptions for Implementing CDASH

3.1 How CDASH and SDTM Work Together

1. The Study Data Tabulation Model (SDTM) and the SDTM Implementation Guide (SDTMIG) provide a standard for the submission of data. CDASH is earlier in the data flow and defines a basic set of data collection fields that are expected to be present on the majority of case report forms (CRFs). SDTM and CDASH are clearly related. The use of CDASH data collection fields and variables is intended to facilitate mapping to the SDTM structure. When submitted data can be collected as represented in an SDTM dataset, with no transformations or derivations, the SDTMIG variable names are presented in the CDASHIG Metadata Table and should be used to collect the data. In cases where the collected data must be transformed or reformatted prior to inclusion in an SDTM dataset, or where a corresponding SDTMIG variable does not exist, CDASH has created standardized data collection variable names.

2. CDASHIG Version 2.1 content is based on SDTMIG Version 3.2.

3. All SDTMIG “Required” variables have been addressed either directly through data collection or by determining what needs to be collected to derive the SDTMIG variable. In some cases, SDTMIG variable values can be obtained from data sources other than the CRF or are populated during the preparation of the submission datasets (e.g., --SEQ values).

4. CDASHIG domains contain variables that may be used in the creation of the RELREC submission dataset. RELREC is an SDTM dataset that describes relationships between records for a subject within or across domains, and relationships of records across datasets. The specific set of identifiers necessary to properly identify each type of relationship is collected in each dataset to support merging the data. Collected data may be across records within a domain, records in separate domains, and/or in sponsor-defined variables. For example, the CDASHIG variable CMAENO, having a question text of "What [is/was] the identifier for the adverse event(s) related to this (concomitant) [medication/therapy]?", may be used to collect data that identifies a relationship between records in the CM dataset and records in the AE dataset.

5. The CDASH standard includes some data collection fields that are not in the SDTMIG (e.g., “Were any adverse events experienced?”, “Were any medication(s) taken?”, "Was the medication taken prior to study start?", “Was the medication ongoing?”). These fields support site-friendly data collection and help with data cleaning/data monitoring by providing verification that other fields on the CRF are deliberately left blank. For use of a field with this intent in an electronic data capture (EDC) system, a CDASH variable name is provided in the CDASHIG Metadata Table (e.g., AEYN, CMYN, CMPRIOR, CMONGO). When the CDASHIG field is confirming that data collection is not expected in other records (e.g., AEYN, CMYN), the corresponding SDTMIG Variable Name column indicates “N/A” and the Mapping Instruction column indicates that “this field is NOT SUBMITTED”. When the CDASHIG field is confirming that data collection is not expected in another date field (e.g., CMPRIOR, CMONGO), the SDTMIG Variable Name lists the applicable SDTM timing variables and Mapping Instructions.

6. The CDASHIG Findings domain (e.g., Drug Accountability (DA), ECG Test Results (EG), Vital Signs (VS)) tables are presented in a structure that is similar to the SDTMIG, which is to list the variable names and some examples of the tests. Implementers are expected to include protocol-specific tests in a CRF presentation layout, using the appropriate values from the relevant CDISC Controlled Terminology codelists. For example, VSTEST values are used to name the test on the CRF, and the corresponding test code is determined from the VSTESTCD codelist. Implementers may use synonyms when the xxTEST values are long or not commonly recognized (e.g., ALT in place of Alanine Aminotransferase). Implementers should use the CDASHIG recommendations to identify the types of data to collect while referring to the SDTMIG and CDISC Controlled Terminology for additional metadata (e.g., labels, data type, controlled terminology).

7. The CDASH standard has intentionally not reproduced other sections of the SDTM standard and implementers are asked to refer to the SDTM and SDTMIG for additional information (both available on the CDISC website, http://www.cdisc.org/sdtm.

8. The CDASHIG data collection fields included in the CDASHIG Metadata Table are the most commonly used and should be easily identified by most implementers. Additional data collection fields may be necessary to capture therapeutic area-specific data points as well as other data specified in the clinical study protocol or for local regulatory requirements. Reference the CDASH Model and relevant CDISC therapeutic area user guide(s) for additional information.

9. Use the CDASH recommendations to develop company standards, taking into consideration the stage of clinical development and the individual therapeutic area requirements. To gain the greatest benefit from using the CDASH standard, CRFs should not be developed on a trial-by-trial basis within the implementer organization, but rather be brought into a study from a library of approved CRFs based on the CDASH Model and Implementation Guide, whenever practicable.

10. The CDASHIG is divided into sections of similar types of data and the CDASHIG Metadata Table is arranged in alphabetical order (by domain abbreviation) within the respective general observation class. CRF layout was not within the original scope of the CDASH project; however, to assist with standardization of CRF layout, data collection fields are presented within the CDASHIG Metadata Table in a logical order, and annotated example CRFs have been provided (if available). In addition, implementers are referred to Section 4.1, Best Practices for Creating Data Collection Instruments, for a discussion on best practices for ordering fields on a CRF.

3.2 Core Designations for Basic Data Collection Fields

The CDASH Team initially considered utilizing the SDTMIG Core Designations of Required, Expected, and Permissible to capitalize on prior understanding of these descriptive designations as well as to enable a consistent categorization across CDASH and SDTM standards. However, when the CDASHIG Metadata Table was constructed, it quickly became apparent that CDASHIG core designations would often differ from SDTMIG core designations due to the inherent differences in the manner in which data are collected (to ensure the most accurate data) and the structure in which data are reported and submitted. For example, a variable categorized as Required in the SDTMIG may not be required in the CDASHIG if it can be derived in the SDTM datasets (rather than be a field captured explicitly on a CRF). Also, the SDTMIG core designation of “Required” imposes a rule that the variable cannot be null. CDASHIG core designations are not intended to impose any rules that require a field to be populated with data. They are only intended to designate which fields should be present on the CRF.

In order to facilitate classification of the different types of data collection fields, the following categories were used:

• Highly Recommended (HR): A data collection field that should always be on the CRF (e.g., the data are needed to meet a regulatory requirement or are required to create a meaningful dataset).
• Recommended/Conditional (R/C): A data collection field that should be on a CRF based on certain conditions (e.g., complete date of birth is preferred, but may not be allowed in some regions; AE time should be captured only if there is another data point with which to compare it). For any R/C fields, the "condition" is described in the Implementation Notes column of the CDASHIG Metadata Table.
• Optional (O): A data collection field that is available for use.

3.3 Form-level CRF Instructions

3.3.1 General Design Considerations for Completion Instructions

Whenever possible, details related to the completion of a single field should be placed with the field itself on the CRF. If this is not possible due to the medium and/or system being used to create CRFs, then it is permissible to include the field-level instructions at the top of the form, in what is generally considered the form-level instruction area. In some cases, such as when the form-level instructions are very lengthy or include graphics or flowcharts, a separate CRF completion instruction guideline may be required.

3.3.2 General Content Considerations for Completion Instructions

When creating form-level instructions for a CRF, the following points should be considered:

• The instructions should include clear references to the time period for which data are to be reported for the study, or to specific time windows that are allowed.
• The instructions should provide references to protocol sections for the specifics of and/or limitations on the data to be reported.
• The instructions should include any special instructions for additional reporting or actions required beyond what is collected on the CRF.
• The instructions should include considerations on how data collected on one CRF might have an impact on data that are reported on a different CRF.
• The instructions should refer to any other forms that are related to the CRF being completed.

3.4 How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined

Adding new sponsor-defined collection fields is often constrained by business rules, as well as by clinical data standards subject matter experts (SMEs), clinical data management processes, and electronic data capture (EDC) systems. The naming conventions and other variable creation recommendations in CDASHIG are designed to allow collection of data regardless of subsequent inclusion in SDTM, as well as to consistently facilitate transforming the collected data into submission datasets.

Prior to adding any new fields to a sponsor's study CRF, the CDASH Model should be reviewed to see if there is a root field that will work for the data collection need.

New data collection fields (not already defined in the CDASH Model) will fall under one of following categories.

• Fields used for data cleaning purposes only and not submitted in SDTM datasets (e.g., --YN): The field --YN with Question Text "Were there any [interventions/events/findings]?" can be added to a domain for this purpose. Replace the 2 dashes (--) with the 2-character domain code, and create the Question Text or Prompt using generic Question Text or Prompt from the CDASH Model as a base. Always create custom data cleaning/operational variables using consistent naming conventions.
• Fields with a direct mapping to an SDTMIG variable: If a value can be collected exactly as it will be reported in the SDTM dataset (i.e., same value, same datatype, same meaning, same controlled terminology), the SDTMIG variable name should be used as the data collection variable name in the operational database to streamline the mapping process. Extensions may be appended if needed to create a unique variable name in the collection database. Any collection variable whose meaning is the same as an SDTMIG variable should be a copy of the SDTMIG variable, and the meaning should not be modified for data collection.
• Fields without a direct one-to-one mapping to SDTM datasets:
• If a study requires a field that is not identical to an SDTMIG field, for example the collected data type is different from the data type in the corresponding SDTMIG variable, or the SDTMIG variable is derived from collected data, the operational database should use a variable with a different name from the SDTMIG variable into which it will be mapped.
• Example 1: A study collects Findings data in a denormalized format and then maps the data to the normalized SDTM structure. The --TESTCD values can be used as the CDASHIG variable names, and the corresponding --TEST value can be used as the prompt on the CRF (See Section 8.3.1, General CDASH Assumptions for Findings Domains, for more information).
• Example 2: Dates and times are collected in a local format, familiar to the CRF users, and then reported in the SDTM-specified ISO 8601 format. In the operational database, the CDASH variables --DAT and --TIM (if collected) map into the single SDTM variable (--DTC).
• Example 3: If the mapping to SDTM is similar, but not direct, "C" can be included before the root variable name to indicate a "collected" version of the variable to which that data will map. For example, if an injection is to be administered to a subject’s LEFT THIGH, RIGHT THIGH, LEFT ARM, or RIGHT ARM, the sponsor may create the variable EXCLOC. The SDTM mapping would split these into EXLOC and EXLAT, which would avoid having to split the collection of the data into 2 fields on the CRF.
• An STDM variable that is not defined in the SDTM version being used by the sponsor can be included as a non-standard variable or a supplemental qualifier.
• If a study requires a field that is not defined in CDASH and SDTM with the same meaning or intent (e.g., would map to SDTM SUPP--), a unique name should be assigned based on sponsor business rules using CDASH naming fragments (e.g., --DAT, --TIM) as appropriate and CDISC Variable Naming Fragments where possible. See SDTMIG v3.2 Appendix D.

3.5 Explanation of Table Headers in the CDASH Model and CDASHIG Metadata Table

3.5.1 CDASH Model

This section provides an explanation of the columns used in the CDASH Model.

• Observation Class: This column contains the SDTM Class for the domain.
• Domain: This column contains the 2-letter domain code.
• Order Number: The values in this column are used to help sequence the variables as they appear in the pmetadata table. There are no implied meaning, significance or conformance expectations. The values increase by one for each variable within a unique grouping of Observation Class plus Domain.
• CDASH Variable: This column provides the CDASH root variable names (e.g., --ONGO, --DAT).
• CDASH Variable Label: This column contains a suggested root variable label that that may be used for the CDASHIG variable.
• DRAFT CDASH Definition: This column provides a draft definition of the root variable. This text may or may not mirror any text in the SDTM. Currently, there is a new CDASH/SDTM team creating variable definitions. Once these definitions are finalized, the CDASH definitions will be updated to harmonize with them.
• Question Text: This column in the CDASH Model contains the recommended question text for the data collection field. Question Text is a complete sentence. Some text is presented inside brackets [ ] or parentheses (). The text inside brackets should be replaced with protocol-specified verbiage; text inside parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Prompt: This column in the CDASH Model contains the recommended prompt text for the data collection field. The Prompt is a short version of the question. Some text is presented inside brackets [ ] or parentheses (). The text inside brackets should be replaced with protocol-specified verbiage; text inside parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Data Type: This column contains the simple data type of the CDASH variable (i.e., Char, Num, Date, Time).
• SDTM Target: This column provides the suggested mapping to the SDTM root variable. When no direct mapping to an SDTM root variable is available, the column contains "N/A". When the column contains "SUPP--.QNAM", it means that the value represented in the CDASH variable shall be mapped to an SDTM Supplemental Qualifier.
Note: CDASH variables noted as not having a direct map to SDTM variables (i.e., non-standard variables) may have SDTM variable equivalents in future versions.
• Mapping Instructions: This column contains information on the suggested mapping of the root variable to the SDTM variable.
• Controlled Terminology Codelist Name: This column contains the Controlled Terminology (CT) codelist name, e.g., "LOC" that is associated with the field. Certain variables (e.g., dates) use ISO formats as CT; however, in CDASH these variables are generally not collected using the ISO CT. These variables are converted to the ISO format when the SDTM-based submission datasets are created.
• Implementation Notes: This column contains further information, such as rationale and implementation instructions, on how to implement the CRF data collection fields and how to map CDASH variables to SDTM variables.

Note: When multiple options are contained in a single cell, the options are separated by a semicolon.

3.5.2 CDASHIG Metadata Table

This section provides an explanation of the columns used in the CDASHIG Metadata Table.

• Observation Class: This column contains the SDTM Class for the domain.
• Domain: This column contains the 2-letter domain code.
• Data Collection Scenario: This column in the CDASHIG Metadata Table identifies the different data collection options in CDASH for the same domain and is best used for filtering the table. The information in this column provides the context for the CDASHIG Core Designations (e.g., denoting which fields should be present on the CRF). When only 1 data collection scenario is provided for the domain, the column contains "N/A".
• Implementation Options: When this column contains "Horizontal-Generic", a sampling of the CDASHIG metadata is provided as a template for the metadata of the CRF in a denormalized structure.
• Order Number: The values in this column are used to help sequence the variables as they appear in the metadata table and provide a suggested order of CDASHIG variables to be displayed on a CRF. There are no implied meaning, significance or conformance expectations. The values increase by one for each variable within a unique grouping of Observation Class plus Domain plus Implementation Options.
• CDASHIG Variable: This column provides the CDASHIG variable names (e.g., CMONGO, AEDAT).
• CDASHIG Variable Label: This column provides the CDASHIG variable label.
• DRAFT CDASHIG Definition: This column provides a draft definition of the CDASHIG variable. This text may or may not mirror any text in the SDTMIG. Currently, there is a new CDASH/SDTM team creating variable definitions. Once these definitions are finalized, the CDASH definitions will be updated to harmonize with them.
• Question Text: This column in the CDASHIG Metadata Table provides the suggested text for the specific domain. Implementers should refer to the CDASH Model to create alternative question text that may be used that meets the CDASH conformance rules. Question Text is a complete sentence. Some text is presented inside brackets [ ] or parentheses (). Text inside brackets should be replaced with protocol- specified verbiage; text inside parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Prompt: This column in the CDASHIG Metadata Table provides the suggested text for the specific domain. Implementers should refer to the CDASH Model to create alternative prompt text that may be used that meets the CDASH conformance rules The Prompt is a short version of the question. Some text is presented inside brackets [ ] or parentheses (). Text inside brackets should be replaced with protocol- specified verbiage. [NULL] in this column indicates that populating a prompt is not required on a CRF screen/page if not needed.
• Data Type: This column contains the simple data type of the CDASH variable (i.e., Char, Num, Date, Time).
• CDASHIG Core: This column contains the CDASHIG core designations for basic data collection fields (i.e., Highly Recommended (HR), Recommended/Conditional (R/C), Optional (O)). See Section 3.2, Core Designations for Basic Data Collection Fields.
• Case Report Form Completion Instructions: This column contains recommended example instructions for the clinical site on how to enter collected information on the CRF.
• SDTMIG Target: This column provides the suggested mapping to the SDTMIG variable name. It may help facilitate the creation of the SDTMIG variables needed for submission. When no direct mapping to an SDTMIG variable is available, the column contains "N/A". When the column contains "SUPP--.QNAM", it means that that the value represented in the CDASH field shall be mapped to an SDTM Supplemental Qualifier.
• Note: CDASHIG variables noted as not having a direct map to SDTMIG variables (i.e., non-standard variables) may have SDTM variable equivalents in future versions.
• Mapping Instructions: This column contains information on the suggested mapping of the CDASHIG variable to the SDTMIG variable. Mapping instructions in the CDASHIG Metadata Table provide more complete guidance than those present in the CDASH Model. When domain-level metadata are not available, consult the CDASH Model for SDTM Mapping Instructions.
• Controlled Terminology Codelist Name: This column contains the Controlled Terminology (CT) codelist name, e.g., "LOC", that is associated with the field. The SDTMIG indicates that certain variables (e.g., dates) use ISO formats as CT. However, in CDASH these variables are generally not collected using the ISO CT; these variables are converted to the ISO format when the SDTM-based submission datasets are created.
• Subset Controlled Terminology/CDASH Codelist Name: This column contains the CDISC Controlled Terminology or CDASH Subset Codelist name that may be used for that specific variable (e.g., EXDOSFRM).
• Implementation Notes: This column contains further information, such as rationale and implementation instructions, on how to implement the CRF data collection fields and how to map CDASHIG variables to SDTMIG variables.

Note: When multiple options are contained in a single cell, the options are separated by a semicolon.

3.6 Collection, Conversion, and Imputation of Dates

3.6.1 Collection of Dates

Collect dates in such a way to allow sites to record only the precision they know. The system should also store only the collected precision. Any incomplete dates must remain incomplete with no imputation and no “zero-filling” of missing components.

Data collection and database processes should allow for the possibility of partial dates and times, because a partial date may be the most precise information that can be collected for some data. For an example of when it may be necessary or appropriate to collect partial dates, see Section 7.3, DM - Demographics. In some countries, collection of a complete date of birth is restricted under privacy rules, so only a year, or year and month of birth, might be collected. Other examples of commonly collected partial dates occur in the CM and MH domains, where the subject may not remember the complete date of when they started to take a medication or when a significant medical history condition began.

If a full date is collected, the CDASH variable --DAT or all 3 date components (i.e., --DATYY, --DATMO, -- DATDD) should be included on the collection tool. If a partial date can be collected in a single field, the CDASH --

DAT should be used. If a partial date must be collected as separate database fields to collect year, month, and day, refer to the CDASH Model for examples of standard naming fragments (--YY, --MO, --DD, --TIM). The capabilities of individual software systems (e.g., EDC) will determine which variable names are needed. CDASH uses separate data collection fields for dates and times. If times are collected, it is expected that they will be used with the appropriate collected date to derive the related SDTM date variable in ISO8601 format.

3.6.2 Conversion of Dates for Submission

See SDTMIG v3.2 Sections 4.1.4.1 and 4.1.4.2 for detailed information about converting dates and times from the collection format to the submission format using ISO 8601. A specific example of mapping birth date is shown here.

The SDTM date format allows this partial date to be submitted so the reviewer can see what was collected.

3.6.3 Imputation of Dates

If missing parts of the date are imputed for analysis purposes, the imputed dates will be generated in the Analysis Data Model (ADaM) but not in the SDTM submission data sets.

3.7 Mapping Relative Times from Collection to Submissions

Relative timing variables are sets of variables that provide information about how the timing of the record relates to either the study reference period or another fixed point in time. CDASH relative timing variables are collected for those observations where a date either is not collected or is not available. The CDASH set of variables serve as an indicator (or flag) that the observation's "start" was "prior" to the study reference period or prior to another fixed point in time OR that the observation's "end" was "after" or "ongoing" as of the study reference period or another fixed point in time. The CDASH variables of --PRIOR and --ONGO serve this purpose. How these CDASH flags are translated to SDTM (according to controlled terminology) depends on whether the comparison is against the protocol-defined study reference period or against another fixed point in time that may serve as the "reference" for the timing of the record. To emphasize, collection of these CDASH relative timing variables is always dependent on the actual date either being prospectively "not collected" or not available. For more information, see Section 8.1.1, General CDASH Assumptions for Interventions Domains and Section 8.2.1, General CDASH Assumptions for Events Domains.

For all SDTM submissions, there is a defined timeframe called the study reference period. According to the SDTMIG v3.2, the start and end dates of the study reference period are submitted in the variables RFSTDTC and RFENDTC. The defined period may be protocol-specific or set by company policy, standard operating procedures, or other documented procedures. The study reference period might be defined as being from the date/time of informed consent through the date/time of subject's completion of the study, or it might be from the date/time of first dose to the date/time of last dose. Regardless of how the study reference period is defined, the dates (and optionally times) of the start and end of that period must be collected.

If there is a need to collect information about whether an observation of interest occurred prior to a reference point or milestone other than the beginning of the study reference period, or was ongoing or continuing at some reference point or milestone in the study other than the end of the defined study reference period, the date/time of that reference point or milestone should also be collected. If this date/time has been collected, reasonable comparisons can be made to that date/time with “prior”, “coincident”, “continuing”, or “ongoing” questions.

The following steps should be taken to ensure observations of interest that occur over time can be related to the study reference period or to a fixed point in time/milestone in a meaningful way. Figure 1 provides a representation of an intervention as it relates to the study reference period, and Figure 2 and Figure 3 provide a representation of comparisons related to other fixed points in time or a milestone.

3.7.1 Study Reference Period

1. Define the “on study” period (B-C). Once the overall “on study” period has been defined (B-C), collect the dates (/times) of the start of the study reference period (e.g., date of informed consent, date of first dose) and end of the study reference period (e.g., date of last contact, date of last dose), as part of the clinical data with their respective domains (e.g., Disposition (DS), Exposure (EX)). These dates will map into the RFSTDTC (B; start of Study Reference Period) and RFENDTC (C; end of Study Reference Period) variables in the SDTMIG Demographics (DM) dataset.

2. Collected comparisons (D, E) using CDASHIG variables (e.g., “prior”, “ongoing”) of when something started or ended in relation to the “on study” reference period (i.e., RFSTDTC-RFENDTC: B-C). These CDASH variables are used to populate the SDTMIG variables--STRF and --ENRF variables when the SDTM-based datasets are created.

Note: These relative timing variables are only populated in the SDTM -based datasets when a date is not collected.

3.7.2 Fixed Point in Time/Milestone

1. Define the fixed point in time or milestone (B or C). The fixed point in time or milestone can be a date or a description. This will map into the SDTMIG variables --STTPT or --ENTPT when the SDTM-based datasets are created.

2. Collected comparisons (D or E) using CDASHIG variables (e.g., “prior”, “ongoing”) of when something started or ended in relation to the fixed point in time or milestone (B or C). These CDASH variables are used to populate the SDTMIG variables--STRTPT or --ENRTPT when the SDTM-based datasets are created.

Note: These relative timing variables are only populated in the SDTM -based datasets when a date is not collected.

For information about mapping what is collected in “prior”, “ongoing”, and “continuing” fields into the appropriate SDTMIG variables, see SDTMIG v3.2 Section 4.1.4.7.

3.8 CDISC Controlled Terminology

Submission data standards are required by some global regulators, and controlled terminology (CT) is part of the requirement. Using CT from the start during data collection builds in traceability and transparency, and reduces the problems associated with trying to convert legacy codelists and variables to the submission standards. CT can be used in the following ways during data collection:

1. To collect data using a standardized list of values (e.g., Mild, Moderate, Severe)

2. To ask a specific question on the CRF (e.g., Temperature)

3. To create a variable name in the database (e.g., TEMP for the collection of vital sign data when a unique variable name must be created for each vital sign result)

Terminology applicable to CDASH data collection fields is either in production or under development by the CDISC Terminology Team. Production terminology is published by the National Cancer Institute‘s Enterprise Vocabulary Services (NCI EVS) and can be accessed at http://www.cancer.gov/cancertopics/terminologyresources/CDISC. The examples in this document use CDISC Controlled Terminology where possible, but some values that seem to be CT may still be under development at the time of publication, or even especially plausible "best-guess" placeholder values. Do not rely on any source other than the CDISC value set in the NCI Thesaurus for CT.

In some cases it is more appropriate to use a subset of a published SDTM terminology list, rather than the entire list. To begin with an established subset of the SDTM terminology, go to https://www.cancer.gov/research/resources/terminology/cdisc and reference the CDASH terminology. These CDASH codelists have been subsetted from the complete SDTM terminology lists and are available to implementers as a way to quickly set up codelists for data collection. However, most implementers will also need to review the SDTM terminology to determine which other values are needed for their particular implementation. The CDASH terminology subset names are provided in the CDASHIG Metadata Table for easy reference.

Some codelists, such as Laboratory Test Codes (LBTESTCD), are extensible. This means that values that are not already represented in that list (either as a CDISC Submission Value, a synonym, or an NCI preferred term) may be added as needed. Other codelists, such as AE Action Taken with Study Treatment, are non-extensible and must be used without adding any terms to the list. Where no CDISC Controlled Terminology exists, implementers should develop sponsor defined terminology to ensure consistency and transparency. If gaps are identified, sponsors should submit requests to add values to controlled terminology by using the Term Suggestion form (available at http://ncitermform.nci.nih.gov/ncitermform/?version=cdisc).

In cases where a CDASH/CDASHIG variable has associated CT, the codelist is referenced in the Controlled Terminology column in the CDASH Model and CDASHIG Metadata Table in this format: (codelist name).

4 Best Practice Recommendations

CDASH best practices describe operational recommendations to support data collection, suggested case report form (CRF) development workflow, and methods for creating data collection instruments. Adherence to Section 4.1, Best Practices for Creating Data Collection Instruments, is an important part of conformance to the CDASH standard. The best practices in this section provide an overview of key data collection methodologies to expedite the clinical data flow from CDASH to the Study Data Tabulation Model (SDTM). For additional guidance, see the Society for Clinical Data Management's (SCDM) Good Clinical Data Management Practices (GCDMP) standard at https://scdm.org/gcdmp/.

4.1 Best Practices for Creating Data Collection Instruments

4.2 CRF Design Best Practices

The following recommendations are general principles that may be implemented during CRF form design and/or database set-up in different ways, depending on the systems used.

Providing the clinical site with a consistent and clinically logical order of these fields will reduce data entry time and result in more reliable data. The CRF should be quick and easy for site personnel to complete.

Clinical Operations staff should review the CRF for compatibility with common site workflow and site procedures.

4.3 Organizational Best Practices to Support Data Collection

4.4 General Recommendations on Screen Failures

Should the sponsor choose, screen failure data are collected for those who fail screening and who are not subsequently enrolled in the study. Section 10.1 of ICH E3 (Structure and Content of Clinical Study Reports, available at https://www.fda.gov/regulatory-information/) describes the reporting of subject disposition in the clinical study report. This section states that it may be “relevant to provide the number of patients screened for inclusion and a breakdown of the reasons for excluding patients during screening, if this could help clarify the appropriate patient population for eventual drug use.” Although screen failure data may not be relevant for all studies, it is recommended that screen failure data be collected based on the needs of the protocol and drug development programs. Timely collection of screen failure data may also be used to identify eligibility criteria that contribute to enrollment challenges.

Using CDASH, the minimum data to be collected should include a subject identifier and reason(s) for screen failure. Typically, there is a reason on the End of Study form indicating “Screen Failure”. This information allows overall summarization of all subjects screened/enrolled and, when captured, provides easy subject accountability for the clinical study report. Other data may be considered for collection, such as date of informed consent, sex, race, date of birth or age, or other data to further describe the reason for ineligibility (e.g., the lab value that was out of range).

The SDTMIG does not provide a separate domain specifically for screen failure data and does not require that the screen failure data be included in the SDTM. Data for screen failure subjects, if submitted, should be included in the appropriate SDTMIG domains. Refer to the SDTMIG for further guidance on submitting screen failure data.

5 Conformance to the CDASH Standard

5.1 Conformance Rules

Conformance means that:

1. Core designations must be followed. All Highly Recommended and applicable Recommended/Conditional Fields must be present in the case report form (CRF) or available from the operational database.

2. CDISC Controlled Terminology must be used. The CDISC Controlled Terminology that is included in the CDASHIG Metadata Table must be used to collect the data in the CRF. All codelists displayed in the CRF must use or directly map to the current published CDISC Controlled Terminology submission values, when it is available. Subsets of published Controlled Terminology, such as those provided in CDASH terminology, can be used.

a. In Findings domains, values from the relevant CDISC Controlled Terminology lists must also be used to create appropriate Question Text, Prompts, and/or variable names. For example, if the question is about the subject's height, incorporate the value of "Height" from the VSTEST codelist as the Prompt on the CRF, and incorporate "HEIGHT" from VSTESTCD in the variable name.

3. Best practices must be followed. The design of the CRF must follow guidance in Section 4.1, Best Practices for Creating Data Collection Instruments and Section 4.2, CRF Design Best Practices.

4. The wording of CRF questions should be standardized; CDASH Question Text or Prompt must be used to ask the question.

a. In cases where the data collection is done in a denormalized presentation on the CRF, the relevant CDISC Controlled Terminology should be used in the Question Text or Prompt as much as possible. It is acceptable to use synonym text that will directly map to a CDISC Submission Value (including an NCI Preferred Term), if the CDISC Submission Value is not appropriate for data collection. For example, "ALT" may be better than "Alanine Aminotransferase" as the prompt for this lab test. If there is no CDISC Controlled Terminology available, the Question Text or Prompt must be standardized by the implementing organization and used consistently. One of the basic purposes of CDASH is to reduce unnecessary variability between CRFs and to encourage the consistent use of variables to support semantic interoperability; therefore, Question Text and Prompt must be used verbatim.

b. Similarly, where Study Data Tabulation Model Implementation Guide (SDTMIG) variables may exist in the operational database and the value conforms to controlled terminology, it is permissible to use a familiar synonym on the CRF without affecting conformance. For example, on the Demographics page, SEX may be displayed as "Male" or "Female", whereas in the operational database the controlled terminology values of "M" and "F" would be used.

c. In some cases, CDASH Questions Text and Prompt allow for flexibility while still being considered conformant. See Section 2.3, CRF Development Overview, for further details on the usage of Question Text and Prompt.

d. CDASH Model Question Text may contain options for the tense, but if the option is not provided, the tense of the Question Text may be modified to reflect the needs of the study.

e. For cases where the Question Text or Prompt cannot be used due to culture or language, or a CRF must be translated for language or cultural reasons, the implementer must ensure the translation is semantically consistent with the CDASH Question Text and Prompt in the CDASHIG Metadata Table.

f. In cases where a more specific question needs to be asked than what is provided by Question Text or Prompt, CDASH recommends the use of a brief CRF Completion Instruction, as long as the instruction clarifies the data required by the study without altering the meaning of variable as defined by the standard. For example, "Sex at birth" is not the same question as "Sex" (which is loosely defined as "reported sex").

5. CDASHIG variable naming conventions should be used in the operational database. Use a consistent syntax that includes the root variable name and/or controlled terminology, and any other standardized concepts that are needed to support efficient mapping of the collected value to SDTM datasets. The goals are to have beginning-to-end traceability of the variable name from the data capture system to the SDTM datasets, and to support automating electronic data capture (EDC) set-up and downstream processes.

a. It is recognized that (particularly in an EDC system) the variable name of a data collection field, as well as the name in the underlying database, may have various “system” components that become part of the item’s identifier. EDC systems, prior to exporting data in a defined format, may require the variable name to include such database “references” as the EDC page name, the item “group” name, or perhaps a combination.

b. In cases where the data collection is done in a denormalized way, appropriate CDISC Controlled Terminology must be used when it is available. For example, when collecting Vital Signs results in a denormalized eCRF, the variable names can be created by using terms from the Vital Signs Test Code codelist. For example, Temperature result can be collected in a variable called TEMP or TEMP_VSORRES; Systolic Blood Pressure result can be collected in a variable called SYSBP or SYSBP_VSORRES. When a particular system’s constraints limit the variable name to 8 characters, a similar, consistent implementation that preserves either the normalized root variable (e.g., ORRES) or the controlled terminology (e.g., --TESTCD value) should be implemented.

c. Whereas all CDASHIG defined variable names are 8 characters or fewer to accommodate SDTM limits on variable names, QNAMs, and --TESTCDs, the maximum length of a variable name that may be implemented is determined by the data management system used, not by CDASH.

d. When collecting data in a horizontal manner, to facilitate transformation to SDTM datasets, when possible it is recommended to create denormalized CDASH variables in the data collection system by incorporating the SDTMIG variable name target and/or the controlled terminology (e.g., --TESTCD) as part of the CDASH variable names. The domain level metadata labeled as "Horizontal-Generic" in the Implementation Options column of the CDASHIG metadata tables are examples of how to implement this. There is no conformance requirement implied by these examples.

6. Data output by the operational database into an SDTMIG variable ideally should require no additional processing if the CDASHIG and SDTMIG variable names are the same. An SDTM data programmer should be able to assume that data in an SDTMIG variable is SDTMIG-compliant. Minimal processing (e.g., changing case) does not effect conformance. This helps to ensure a quality deliverable, even if the programmer is unfamiliar with data capture practices.

7. Validated questionnaires, ratings, or scales must present the questions and reply choices in the manner in which these were validated. This must be followed to maintain the validity of a validated instrument. (See Section 8.3.12, QRS - Questionnaires, Ratings, and Scales).

a. In some cases, this may result in CRFs that do not conform to CDASH best practices; however, restructuring these questionnaires should not be done because it could invalidate them.

b. The use of such questionnaires in their native format should not be considered to affect conformance to CDASH.

Implementers must determine what additional data fields to add to address study-specific and therapeutic area requirements, and applicable regulatory and business practices. See Section 3.4, How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined, for more information on how to create data collection fields that have not already been described in this implementation guide.

6 Other Recommendations

6.1 Standardized Coding of Collected Data

6.1.1 Data Collection to Facilitate Coding

Adverse Events, Medical History, and Prior and Concomitant Medications are often coded to standard dictionaries (thesauri). There are many coding dictionaries; this section will focus on the Medical Dictionary for Regulatory Activities (MedDRA) and the World Health Organization Drug Dictionary (WHO-DD) as examples, because these are common coding dictionaries.

The Study Data Tabulation Model Implementation Guide (SDTMIG) variable AEDECOD is the dictionary-derived text description of AETERM (the reported term for the adverse event) or AEMODIFY (the modified reported term). When coding with MedDRA, the AEDECOD is the Preferred Term and is a required variable. Corresponding SDTMIG variables CMDECOD (for medications) and MHDECOD (for medical history items) are permissible SDTMIG variables. These are the equivalent of the preferred term in the dictionary used for coding, and when data are coded these SDTMIG variables should be provided.

These --DECOD variables are not necessarily collected on case report forms (CRFs). They are often determined from other collected variables (e.g., AETERM, CMTRT, and MHTERM). Conventions adopted in the collection of these reported terms can have an effect on the resulting --DECOD variables. If collected on a CRF, --DECOD values would be selected from sponsor-defined or CDISC Controlled Terminology.

CRF designers should consult with medical coders, review relevant documentation, and ensure that all elements needed to facilitate the coding process are collected.

6.1.2 Coding Adverse Events and Medical History Items

Data managers are encouraged to collaborate with coding specialists and medical staff to develop guidance for sites in accordance with applicable coding conventions and other company/project agreements and requirements.

Reported terms are often coded without other information for the subject. Therefore, sites should be advised that nothing can be assumed, and that the reported term should include all information relevant to the event being reported. For example, if “Congestion” is reported as an adverse event for a particular subject, together with several other pulmonary events, the coder cannot assume that the congestion is “Lung congestion”, rather than congestion of some other organ (e.g., nose, ear). The reported term “Congestion” will need to be queried before it can be coded.

6.1.3 Medications

With regard to medications, the CDASH standard offers some guidance on the recording of medication names and on the use of additional Recommended/Conditional data collection fields (e.g., CMROUTE, CMINDC) to facilitate coding. See Section 8.1.1, General CDASH Assumptions for Interventions Domains.

The purpose of coding medications is usually to provide a Standardized Medication Name (CMDECOD) and a Medication Class (CMCLAS). Most dictionaries facilitate the derivation of the Standardized Medication Name on identification of the medication that was taken and the reason taken.

Although it would be preferable to collect all active ingredients of a particular medication, in a clinical trial this is impractical. There are numerous CRF design possibilities. When designing a collection tool, it is critical to ensure that details appropriate to the trial and the sponsor’s coding requirements are included. For example, betamethasone dipropionate is used topically; however, if the site records only betamethasone (which can be administered orally, as drops, or inhaled), the topical route of the drug will be lost. In this case, collecting route of administration (CMROUTE) or the indication (CMINDC) would provide the additional information needed to code this medication.

In summary, when medications are to be coded, the indication (CMINDC) and route (CMROUTE) or anatomical location (CMLOC) should be collected along with the medication name.

7 Special-purpose Domains

The Study Data Tabulation Model Implementation Guide (SDTMIG) includes 3 types of special-purpose datasets:

• Domain datasets—Demographics (DM), Comments (CO), Subject Elements (SE), and Subject Visits (SV)—which contain subject-level data
• Trial Design Model (TDM) datasets, which contain trial-level data
• Relationship datasets

These datasets are described in SDTMIG Section 2.3. CDASH does not currently contain information on Trial Design Model or Relationship datasets. Because CDASH standards are for collection of subject-level data, the collection of Trial Design domains is out of the scope for CDASH. CDASHIG contains information on these Special-Purpose Domains: Comments (CO) and Demographics (DM).

7.1 General CDASH Assumptions for Special-purpose Domains

1. Each study must include the DM domain.

2. CDASH does not currently contain metadata information on SDTM Special-Purpose Domains Subject Elements (SE) and Subjects Visits (SV). The SDTM SE and SV domains are commonly derived/created during the SDTM dataset creation process. Each implementer has to determine the best practice within their organization for creating visits and collecting the information on any unplanned visits. See SDTMIG v3.2 Section 5, Subject Elements and Subject Visits, for more information.

7.2 CO - Comments

Description/Overview for the CDASHIG CO - Comments Domain

The CDASHIG Comments (CO) domain describes free text collected alongside other data on typical case report form (CRF) pages (e.g., Adverse Events) when there is not a specified variable for the free text. The CDASHIG CO domain has no mandatory data elements for inclusion in a separate Comments CRF, and the recommendation is to avoid creating a General Comments CRF.

Specification for the CDASHIG CO - Comments Domain

Comments Metadata Table

Assumptions for the CDASHIG CO - Comments Domain

Solicited Comments vs. Unsolicited Comments

Solicited comments are defined as those comments entered in free-text data collection fields (e.g., “Please comment”) that are intentionally included on the CRF. These data collection fields provide the site with a predefined space to further explain or clarify an associated record within the CRF. For example, the Vital Signs CRF may include a solicited comment data collection field that enables recording of free text, such as “Reason for performing assessment out of window”.

Unsolicited comments are those comments entered outside of predefined data collection fields (also referred to as marginal comments, as they are sometimes written in the margins of paper CRFs). These may include marginal CRF comments written by site staff, notes written by the subject on paper diaries, or additional information collected through an electronic data capture (EDC) system function which collects comments that are not included as data collection fields on the eCRF. Although such comments may be intended to reduce queries, in practice they often lead to clinical data not being entered into the correct data collection field and may cause additional work in the data management process. The collection of unsolicited comments should be discouraged. If allowed, unsolicited comments should be reviewed and resolved during the conduct of the study.

Some unsolicited comments may be intended to avoid queries, for example “Subject visit was delayed due to his holidays”, and may not be regarded as clinical data. When these comments are permitted during data collection, the sponsor should have a process by which the comments are reviewed and processed. This should include a method to query and move relevant data to the appropriate form.

The Investigative site should be trained to enter clinical data in the appropriate data collection fields rather than making marginal notes on the CRF, and to use appropriate methods and tools to communicate to the monitor information that should not be included in the clinical data.

Free Text vs. Value List Fields

Clinical data must be entered in appropriate data collection fields; otherwise, there is a potential for data that should be entered on other CRFs to be hidden within the comment. For example, if a general comment of “Subject visit was delayed as he had the flu” was captured, this would necessitate that someone review the data and query the site to enter “flu” in an Adverse Event CRF and not leave it as a comment. An additional concern with free-text comments is the potential for inappropriate or sensitive information to be included within general comments data collection fields. For example, a comment could contain a subject’s name or may have unblinding information. Free-text comments are also inefficient for processing due to their variable and unstructured nature; they offer limited or no value for statistical analysis, as they cannot be tabulated. CRF development teams are encouraged to strive for data collection methods that maximize the use of predefined lists of responses rather than relying solely on free-text comment fields. The recommendation is that CRF development teams consider what additional questions may be needed within a specific CRF, and what the typical responses would be. They can then create a standardized list of responses for those questions, and make the data collected more useful for analysis.

Considerations Regarding General Comments CRFs

Solicited comments often used to be collected on a General Comments CRF. In recent years, though, most organizations have discontinued this practice.

The CDASHIG CO domain has no mandatory data elements and is not intended to encourage the creation of a General Comments CRF. CDASHIG recommends against the use of a General Comments CRF. This recommendation is not meant to discourage investigators from providing unsolicited comments where they are appropriate, nor to discourage solicited free-text comment data collection fields that may appear within any CRF. Free-text comment fields should be used to solicit comments where they are needed. When comments are collected, they should use a variable naming convention that conforms to CDASH (e.g., COVAL may be used in any CRF because it is part of the SDTMIG specification).

Example CRF for the CDASHIG CO - Comments Domain

Example 1

This CRF shows the use of a targeted comment to collect the reason a pharmacokinetics (PK) sample was drawn more than 5 minutes late.

Title: Pharmacokinetic Sample Collection with Comments

CRF Metadata

7.3 DM - Demographics

Description/Overview for the CDASHIG DM - Demographics Domain

The Demographics (DM) CDASHIG domain includes essential data collection fields that describe each subject in a clinical study. The collection of some demographics data is useful to perform simple analyses based upon population stratification.

Privacy concerns surrounding the DM and Subject Characteristics (SC) data were taken into account when these domains were created. For example, there are optional CDASHIG variables to collect the components of birthdate (e.g., BRTHDD, BRTHMO, BRTHYY); therefore, limited elements of birthday may be collected and later mapped to the SDTMIG variable BRTHDTC. This approach provides flexibility in categorizing some variables to facilitate compliance with local privacy issues.

Collection of Age vs. Date of Birth

It is recognized that sponsors may collect the Age or Date of Birth of the subject. In multiregional studies, sponsors may need to enable the collection of either in order to comply with local regulations. But only one or the other should be collected for any given subject. When only AGE is collected, the sponsor is left with a window of uncertainty of, at most, 365 days. Although knowing the precise date of birth provides the ability to calculate accurately an age for any date, a precise (and complete) date of birth may be considered “personally identifying information” for some privacy oversight boards or government regulators.

Collect the date of birth to the extent that the local regulatory authorities will allow.

• The best method is to collect a complete date of birth, and derive age.
• When there are privacy concerns with collecting the complete date of birth, the recommendation is to collect year of birth at a minimum.
• In cases when neither of the above can be implemented (e.g., cultural or regional considerations) then Age and Age Unit should be collected, and Date of Collection should be collected or derived from the Visit Date.
• Use the AGETXT variable only in very rare cases when only an age range or age description can be determined.

Date of Birth should be implemented such that incomplete dates may be entered, as allowed by the data capture system.

See Section 3.6, Collection, Conversion, and Imputation of Dates, for more information.

Collection of Sex

The collection of some demographics data is useful to perform simple analyses based upon population stratification.

Collection of Ethnicity and Race

The US Food and Drug Administration (FDA) requirement is to collect Ethnicity before Race. A secondary analysis is often made using the phenotypic race of the subject. Collect Race if required for the protocol and not prohibited by local laws and regulations.

In 2016, the US Office of Management and Budget (OMB) revised its recommendations for the collection and use of race and ethnicity data by Federal agencies. The FDA follows this directive and recommends “the use of the standardized OMB race and ethnicity categories for data collection in clinical trials for two reasons. The use of the recommended OMB categories will help ensure consistency in demographic subset analyses across studies used to support certain marketing applications to FDA and across data collected by other government agencies”.

The Race values listed in the FDA Guidance (available at https://www.fda.gov/) are:

• American Indian or Alaska Native
• Asian
• Black or African American
• Native Hawaiian or Other Pacific Islander
• White

Note: For studies where data are collected outside the US, the recommended categories are the same, except for “Black” instead of “Black or African American”.

CDASH provides only 1 variable for Race. Sponsors wishing to capture more than 1 race will need to create non- standard variables to store the collection of the multiple races and map appropriately to the SDTMIG DM domain.

Race Other has been included as a free-text field to capture responses. The use of this variable is optional and should be used with caution. When submitting data to the FDA, all races must be mapped to the 5 values recognized by the FDA; providing an Other, Specify field might lead to mapping errors or difficulties. RACE is Recommended/Conditional (R/C) because some sponsors prefer to derive values that are compliant with the codelist RACE (e.g., as derived from values collected in CRACE).

The category of ethnicity is similar to race but, as defined by the US Centers for Disease Control and Prevention (CDC), is an arbitrary classification based on cultural, religious, or linguistic traditions; ethnic traits; background; or allegiance or association. In a fairly heterogeneous country such as the United States, ethnicity data (e.g., "Hispanic or Latino" and "Not Hispanic or Latino") might be useful to confirm that ethnic groups are not being discriminated against by being unfairly excluded from clinical research. In other countries, regulatory bodies (e.g., Japanese Ministry of Health, Labour and Welfare) may expect the reporting of ethnicity values which appropriately reflect the population of their areas. This information may be collected using the CETHNIC variable with its corresponding codelist, ETHNICC.

If more detailed information on race or ethnicity is required to further characterize study subjects, it is recommended that the presented choices be “collapsible” up to one of the 5 FDA designations for race, as well as the 2 categories for representing ethnicity, as needed for reporting to FDA. If more detailed categorizations are desired, the recommendation is to use the HL7 Reference Information Model's race and ethnicity vocabulary tables (available at https://www.hl7.org/), which are designed to collapse up in this manner. For the collection of such added detail or granularity, as the sponsor may require, CDASH provides the variables CRACE and CETHNIC, respectively.

Collection of Special Optional Fields in Demographics

CDASHIG allows for collection of the Date of Informed Consent using the variable RFICDAT. (If a sponsor chooses to collect Informed Consent using this variable, the data should not also be collected using DSSTDAT from the Disposition (DS) Domain.) The data from RFICDAT would then be mapped to the SDTMIG variable DSSTDTC and the companion variables (e.g., DSTERM, DSDECOD) must be populated accordingly.

The CDASH Model also defines a field for Death Date (DTHDAT) as a timing variable. It may be collected on any CRF deemed appropriate by the sponsor. The SDTMIG variables DTHDTC and DTHFL are mapped to the DM domain during the SDTM submission dataset creation process. The CDASH field Death Date may be mapped to other SDTMIG domains (e.g., DS), as deemed appropriate by the sponsor.

See Section 4.1, Best Practices for Creating Data Collection Instruments, Num 4 for additional guidance recommending that the same data not be collected more than 1 time per subject.

Specification for the CDASHIG DM - Demographics Domain

Demographics Metadata Table

Assumptions for the CDASHIG DM - Demographics Domain

The CDASHIG DM domain is a special-purpose domain that collects specific data elements that are mapped to the SDTMIG DM domain. Additional data elements that are not within the scope of the demographics must be mapped to other domains.

Example CRFs for the CDASHIG DM - Demographics Domain

Example 1

Title: Demographics

CRF Metadata

Example 2

Title: Demographics with Additional Granularity for Ethnicity and Race

CRF Metadata

8 General Observation Classes

This section reflects common practices implemented by a significant number of the organizations/companies that provided information and examples. Most subject-level data collected during a study are represented using 1 of the 3 Study Data Tabulation Model (SDTM) general observation classes: Interventions, Events, and Findings. Section 8.1 describes the CDASH Intervention domains, Section 8.2 the CDASH Events domains, and Section 8.3 the CDASH Findings Domains.

Within each domain class, the domains are presented in alphabetical order. Readers should refer to Section 6 of the SDTM Implementation Guide (SDTMIG) for additional information on these classes. Within each domain, a link is provided to the CDASHIG Domain Metadata table. The CDASHIG Domain Metadata tables include the variables that are commonly used by a significant number of the organizations/companies that provided information and examples.

Implementers may add other variables from the CDASH Model as needed, following the instructions in Section 3.4, How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined.

8.1 Interventions Class Domains

The Interventions class includes CDASH domains that define collection standards for investigational treatments, therapeutic treatments, and procedures that are intentionally administered to the subject either as specified by the study protocol (e.g., exposure), coincident with the study assessment period (e.g., concomitant medications), or self- administered by the subject (e.g., alcohol, tobacco, caffeine).

8.1.1 General CDASH Assumptions for Interventions Domains

1. CDASH --YN variables with the question text "Were there any interventions?" (e.g., “Were there any procedures?”, “Were there any concomitant medications?") are intended to assist in the cleaning of data and in confirming that there are no missing values. These variables are not included as part of the SDTM Intervention domains for submission and are annotated as NOT SUBMITTED on the case report form (CRF).

2. CDASH --CAT and/or -SCAT are generally not entered on the CRF by the sites. Implementers may prepopulate and display these category values to help the site understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories are determined per protocol design, and could be populated during SDTM submission dataset creation.

3. Date and Time Variables

a. CDASH date variables (e.g., --DAT, --STDAT, --ENDAT) are concatenated with CDASH Time variables (e.g., --TIM, --STTIM, --ENTIM, if time is applicable) into the appropriate SDTM --DTC variables (e.g., --DTC, --STDTC, --ENDTC) using the ISO 8601 format.

b. Collecting the time an intervention was started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the intervention was started, and the study design is such that it is important to know the intervention start time with respect to dosing.

4. The CDASH variable -- REASND is used with SDTM variable --STAT only. The value "NOT DONE" in - -STAT indicates that the subject was not questioned about the intervention or that data were not collected; it does not mean that the subject had no interventions.

5. The CDASH --SPID variable may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system.

6. Coding

a. When free-text intervention treatments are recorded, the location may be included in the --TRT variable to facilitate coding (e.g., Liver Biopsy). Location may be collected when the sponsor needs to identify the specific anatomical location of the intervention. This location information does not need to be removed from the verbatim --TRT when creating SDTMIG submission datasets.

b. The Non-Standard (or SUPPQUAL) Variables --ATC1 through --ATC5 and --ATC1CD through -- ATC5CD are used only when the intervention is coded using the World Health Organization's Anatomical Therapeutic Chemical (ATC) classification system (https://www.who.int/medicines/regulation/). The numbers indicate the anatomical main group: "1" = the anatomical main group, "2" = the therapeutic main group, "3" = the therapeutic/pharmacological subgroup, "4" = chemical/therapeutic/pharmacological subgroup, "5" = chemical substance.

c. The implementer may also add MedDRA coding elements as non-standard variables to the Intervention domain if this dictionary is used for coding.

7. Location (--LOC) and related variables (--LAT, --DIR, -- PORTOT)

a. Because the complete lists of controlled terminology for these variables may be too extensive to be relevant for a particular study CRF, sponsors may choose to include only subsets of the controlled terminology on the CRF.

b. --LOC could be a defaulted or hidden field on the CRF for prespecified [--TRT]/Intervention Topic].

8. Relative Timing Variables (See SDTMIG v3.2 Section 4.1.4.7 for more information and details)

a. For each study, the sponsor defines the study reference period in the DM domain using SDTMIG variables RFSTDTC and RFENDTC. Other sponsor-specified reference time points can be defined for other data collection situations. The CDASH variables --PRIOR and --ONGO may be collected in lieu of "start date" or "end date".

b. The CDASH variable --PRIOR is used to indicate if the --TRT (the topic item) started prior to either the study reference period or another sponsor-defined reference time point. When the study reference period is used as the anchor, --PRIOR may be used to derive a value (from the Controlled Terminology codelist STENRF) into the SDTM relative timing variable --STRF. When populating --STRF, if the value of --PRIOR is "Y", the value of “BEFORE” may be mapped to --STRF. The value in DM.RFSTDTC serves as the anchor for --STRF.

c. When a reference time point is used instead of the study reference period, --PRIOR may be used to derive a value into the SDTM relative timing variable --STRTPT. If the value of --PRIOR is "Y", the value of "BEFORE" may be derived into --STRTPT. Note: --STRTPT must refer to the “time point anchor” as described in --STTPT. The value in --STTPT can be either text (e.g., "VISIT 1") or a date (in ISO 8601 format).

d. The CDASH variable --ONGO is used to indicate if the value in --TRT is continuing beyond the study reference period or beyond another sponsor-defined reference time point. When the study reference period is used as the anchor, --ONGO may be used to derive a value into the SDTM relative timing variable --ENRF. If the value of --ONGO = "Y", the value of "AFTER" may be mapped to --ENRF.

e. When a reference time point is used instead of the study reference period, --ONGO may be used to derive a value into the SDTM relative timing variable --ENRTPT. If the value of --ONGO is "Y", the value of "ONGOING" may be mapped to --ENRTPT. Note: --ENRTPT must refer to the “time point anchor” as described in --ENTPT. The value in --ENTPT can be either text (e.g., "TRIAL EXIT") or a date (in ISO 8601 format).

8.1.2 CM - Prior and Concomitant Medications

Description/Overview for the CDASHIG CM - Prior and Concomitant Medications Domain

The same basic data collection variables should be collected for all medications/treatments/therapies (Prior, General Concomitant Medications, and Medications of Interest). If additional fields are needed to collect other data about a medication of interest, those should be added as non-standard fields.

Note:

• Sponsors may use terms like concomitant medications, treatments, or therapies, as appropriate for the study. The following text may use one of these terms, but sponsors can always use the term most appropriate for their study.
• The term prior refers to medications/treatments that were started before study participation, because limited information may be available on prior medications taken by a subject; the core requirements were constrained to reflect this limitation.
• Sponsors should define the appropriate collection period for prior and concomitant medications/treatments in the study protocol.

Specification for the CDASHIG CM - Prior and Concomitant Medications Domain

Prior and Concomitant Medications Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Interventions	CM	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Interventions	CM	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on CRFs that are shipped to each site. EDC: This should be prepopulated.
Interventions	CM	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Interventions	CM	N/A	N/A	4	CMCAT	Category for Medication	A grouping of topic-variable values based on user-defined characteristics.	What is the category for the (concomitant) [medication/treatme nt/therapy]?	(Concomitant) [Medication/Treatment/ Therapy Category]; NULL	Char	O	Record the (concomitant) [medication/treat ment/therapy] category, if not pre-printed on the CRF.	CMCAT	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Interventions	CM	N/A	N/A	5	CMSCAT	Subcategory for Medication	A sub-division of the CMCAT values based on user- defined characteristics.	What is the subcategory for the (concomitant) [medication/treatme nt/therapy]?	(Concomitant) [Medication/Treatment/ Therapy subcategory]; NULL	Char	O	Record (concomitant) [medication/treat ment/therapy] subcategory, if not pre-printed on the CRF.	CMSCAT	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be pre- printed on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer.
Interventions	CM	N/A	N/A	6	CMYN	Any Concomitant Medications Taken	An indication whether or not any (concomitant) medications/treatm ents/therapies were taken/given.	Were/Was any (concomitant) [medication(s)/treat ment(s)/therapy(ies)] taken?	Any (Concomitant) [Medication(s)/ Treatment(s)/ Therapy(ies)]	Char	O	Indicate if the subject took any (concomitant) [medications/treat ments]. If Yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Interventions	CM	N/A	N/A	7	CMSPID	CM Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	CMSPID	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target". May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medication/treatment records with AEs and/or MH. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Interventions	CM	N/A	N/A	8	CMTRT	Reported Name of Drug, Med, or Therapy	Verbatim medication name or treatments (include only treatments with data collection characteristics similar to medications).	What was the (concomitant) [medication/treatme nt/therapy] (name/term)?	(Concomitant) [Medication/Treatment/ Therapy]	Char	HR	Record only 1 [medication/treat ment/therapy] per line. Provide the full trade or proprietary name of the [medication/treat ment/therapy]; otherwise the generic name may be recorded.	CMTRT	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	In most cases, the verbatim drug names or treatment will be coded to a standard dictionary such as WHODrug after the data have been collected on the CRF. For the collection of verbatim drug name or treatments, the recommendation is to ask sites to provide the full trade or proprietary name since it is more exact than 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, Tylenol with codeine #1 has a different ATC code than Tylenol with codeine #3. This field can be used for either prior or concomitant medication/treatments.
Interventions	CM	N/A	N/A	9	CMPRESP	CM Pre- Specified	An indication that a specific intervention or a group of Interventions is prespecified on a CRF.	N/A	N/A	Char	O	N/A	CMPRESP	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	(NY)	N/A	For prespecified interventions, a hidden field on a CRF defaulted to "Y", or added during the SDTM dataset creation. If a study collects both prespecified interventions as well as free-text interventions, the value of CMPRESP should be "Y" for all prespecified interventions and null for interventions reported as free text.
Interventions	CM	N/A	N/A	10	CMOCCUR	CM Occurrence	An indication whether the prespecified medication/treatme nt/therapy (CMTRT) or the group of medications/treatm ents/therapies was administered when information about the occurrence of a specific intervention is solicited.	Did the subject take [prespecified (concomitant) medication/treatmen t/therapy/dose]?; Has the subject taken [prespecified (concomitant) medication/treatmen t/therapy/dose]?	[Specific (Concomitant) [Medication/ Treatment/Therapy]	Char	O	Indicate if [specific medication/treatm ent] was taken by checking Yes or No.	CMOCCUR	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target". If the response was not asked or answered, populate the SDTMIG variable CMSTAT with "NOT DONE".	(NY)	N/A	CMOCCUR is used to report the occurrence of a prespecific medication/treatment. CMOCCUR is not used for spontaneously free text reported concomitant medication/treatments. The site should be able to indicate that the response was not asked or answered.
Interventions	CM	N/A	N/A	11	CMINGRD	Concomitant Meds Active Ingredients	Medication Ingredients.	What were the active ingredients?	Active Ingredients	Char	O	Prior to a subject's clinical visit, remind all subjects to bring all medications bottles, packs etc. they are taking with them to their clinical visit. Record all active ingredient(s) off the medication label and separate each ingredient with a comma for the name of drug medication or treatment taken. For example, the medication Dolmen, if manufactured in Spain, the active ingredients should be collected as noted below: Active Ingredient: Acetylsalicylic Acid, Ascorbic acid, codeine phosphate.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	N/A	N/A	This may be collected in addition to the Medication/Treatment Name. Collecting this provides more detailed information when coding to a medication dictionary like WHODrug Dictionary Enhanced Format C, which now codes to the ingredient level for many trade-named medications. For example, depending on the country where it is manufactured, the active ingredients in the medication Dolmen may be different: In Spain, Acetylsalicylic Acid, Ascorbic acid, codeine phosphate; in Italy and Czech Republic, contains Tenoxicam; in Estonia and Latvia, contains Dexketoprofen trometamol.
Interventions	CM	N/A	N/A	12	CMINDC	CM Indication	The condition, disease, symptom, or disorder that the concomitant (non- study) medication/treatme nt/therapy was used to address or investigate (e.g., why the medication/treatme nt/therapy was taken or administered).	For what indication was the (concomitant) [medication/treatme nt/therapy] taken?	Indication	Char	R/C	Record the reason the medication was taken based on clinical investigator's evaluation. If taken to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If taken to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for " and include a description of the condition(s).	CMINDC	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	This is not the pharmacological/therap eutic classification of an agent (e.g., antibiotic, analgesic), but the reason for its administration to the subject. This additional information is collected on the CRF when sponsors want to capture the reason(s) why a subject took a medication/treatment. This information could be used as deemed appropriate for coding, analysis (e.g., in the classification of medications), for reconciling the medications/treatments taken by a subject with provided medical history, and/or AEs/SAEs as part of the data clean-up and monitoring process.
Interventions	CM	N/A	N/A	13	CMAENO	Related Adverse Event ID	Identifier for the adverse event that is the indication for this medication/treatme nt/therapy.	What was the identifier for the adverse event(s) for which the (concomitant) [medication/treatme nt/therapy] was taken?	Adverse Event Identifier	Char	O	Record the identifier of the Adverse Event for which this (concomitant) [medication/treat ment/therapy] was taken.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Adverse Events domain.	N/A	N/A	Intent is to establish a link between the medication/treatment and the AE that was reported. CMAENO can be used to identify a relationship between records in CM dataset and records in the AE dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Interventions	CM	N/A	N/A	14	CMMHNO	Related Medical History Event ID	Identifier for the medical history condition that is the indication for this medication/treatme nt/therapy.	What was the identifier for the medical history event(s) for which the (concomitant) [medication/treatme nt/therapy] was taken?	Medical History Event Identifier	Char	O	Record the identifier of the medical history event for which this (concomitant) [medication/treat ment/therapy] was taken.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Medical History domain.	N/A	N/A	Intent is to establish a link between the medical history condition and the medication/treatment taken for the medical history condition. CMMHNO can be used to identify a relationship between records in the CM dataset and records in the MH dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Interventions	CM	N/A	N/A	15	CMDOSE	CM Dose per Administration	The dose of medication/treatme nt (e.g., --TRT ) given at one time represented as a numeric value.	What was the individual dose (of the concomitant [medication/treatme nt/therapy] per administration)?	[Dose/Amount] (per administration)	Num	O	Record the dose of (concomitant) [medication/treat ment] taken per administration (e.g., 200).	CMDOSE	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	Used when the dose/amount taken/administered/con sumed has only numeric entries. If non- numeric entries are possible, use the CDASH field CMDSTXT.
Interventions	CM	N/A	N/A	16	CMDSTXT	Concomitant Meds Dose Description	The dose of medication/treatme nt taken per administration.	What was the individual dose of the (concomitant) [medication/treatme nt/therapy]?	Dose	Char	O	Record the dose of (concomitant) [medication/treat ment] taken per administration (e.g., 200).	CMDOSTXT ; CMDOSE	This does not map directly to an SDTMIG variable. Numeric values map to CMDOSE in SDTM. Non- numeric values (e.g., 200-400) map to CMDOSTXT in SDTM.	N/A	N/A	Defining this data collection field as a dose text field allows for flexibility in capturing dose entries as numbers, text or ranges. The data collected in this dose text-format field should be separated or mapped to either SDTMIG CMDOSE if numeric or CMDOSTXT if text.
Interventions	CM	N/A	N/A	17	CMDOSTOT	CM Total Daily Dose	The total amount of CMTRT taken over a day using the units in CMDOSU.	What was the total daily dose of the (concomitant) [medication/treatme nt/therapy]?	Total Daily Dose	Num	O	Record the total dose of (concomitant) [medication/treat ment/therapy] taken daily.	CMDOSTO T	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	For use when only total daily dose is collected in the CRF. For general medications/treatments , it is not recommended to use Total Daily Dose. Instead, this can be calculated from other fields such as Units, Dose, and Frequency.
Interventions	CM	N/A	N/A	18	CMDOSU	CM Dose Units	The unit associated with the concomitant medication/treatme nt/therapy taken (e.g., mg in "2 mg 3 times per day").	What is the unit (for the dose of concomitant [medication/treatme nt/therapy])?	(Dose) Unit	Char	R/C	Record the dose unit of the dose of concomitant [medication/treat ment/therapy] taken (e.g., mg.).	CMDOSU	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	(UNIT)	(CMDOSU)	When sponsors collect data for amount of dose taken (i.e., Dose, Total Daily Dose), Unit must be collected as well (if applicable).
Interventions	CM	N/A	N/A	19	CMDOSFR M	CM Dose Form	The pharmaceutical dosage form in which the CMTRT is physically presented.	What was the dose form of the (concomitant) [medication/treatme nt/therapy]?	Dose Form	Char	O	Record the pharmaceutical dosage form (e.g., TABLET CAPSULE, SYRUP) of delivery for the concomitant [medication/treat ment/therapy] taken.	CMDOSFR M	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	(FRM)	(CMDOSFRM)	Some drugs have multiple forms and this field may be needed to code the drug to an ATC level. However, in general, this level of detail should not be necessary except for medications/treatments of interest.
Interventions	CM	N/A	N/A	20	CMDOSFR Q	CM Dosing Frequency per Interval	The number of doses given/administered /taken during a specific interval.	What was the frequency of the (concomitant) [medication/treatme nt/therapy]?	Frequency	Char	O	Record how often the (concomitant) [medication/treat ment/therapy] was taken (e.g., BID, PRN).	CMDOSFR Q	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	(FREQ)	(CMDOSFRQ)	The frequency of the concomitant medication/treatment. When collected, the recommendation is to collect dosing information in separate fields (e.g., CMDOSE, CMDOSEU, CMDOSFRQ) for specific and consistent data collection and to enable programmatically utilizing these data.
Interventions	CM	N/A	N/A	21	CMROUTE	CM Route of Administration	The route of administration of the (concomitant) [medication/treatm ent/therapy].	What was the route of administration of the (concomitant) [medication/treatme nt/therapy]?	Route	Char	R/C	Provide the route of administration for the (concomitant) [medication/treat ment/therapy].	CMROUTE	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	(ROUTE)	(CMROUTE)	This additional information may be important to collect on the CRF when the sponsor would want to capture a medication's/treatment' s route of administration for purposes such as coding and the medication/treatment may have more than one route. Some companies may use route in coding medications/treatments to be able to choose a precise preferred name and ATC code.
Interventions	CM	N/A	N/A	22	CMSTDAT	Concomitant Meds Start Date	The start date when the concomitant medication/treatme nt/therapy was first taken, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the (concomitant) [medication/treatme nt/therapy/dose] start date?	Start Date	Char	R/C	Record the date the concomitant [medication/treat ment] was first taken using this format (DD-MON- YYYY). If the subject has been taking the concomitant [medication/treat ment] for a considerable amount of time prior to the start of the study, it is acceptable to have an incomplete date. Concomitant [medication/treat ment] taken during the study are expected to have a complete start date. Prior concomitant [medication/treat ment] that are exclusionary should have both a start and end date.	CMSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CMSTDTC in ISO 8601 format.	N/A	N/A	The assumption is that sponsors should either have a Start Date or will indicate that the medication or therapy was started before, during or after the study period. The preferred method is to collect a complete Start Date. Partial dates (e.g., providing year only) for medications/treatment started a considerable amount of time prior to the start of study are acceptable.
Interventions	CM	N/A	N/A	23	CMSTTIM	Concomitant Meds Start Time	The time the concomitant medication/treatme nt/therapy was started, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (concomitant) [medication/treatme nt/therapy/dose] start time?	Start Time	Char	R/C	Record the time (as complete as possible) that the concomitant [medication/treat ment] was started.	CMSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CMSTDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a concomitant medication/treatment was started only when a protocol or data collection scenarios supports it. Typically, a start time is not collected unless the subject is under the direct care of the site at the time a concomitant medication/treatment administered or the subject records the start time in a diary. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.
Interventions	CM	N/A	N/A	24	CMPRIOR	Prior Concomitant Meds	Indication the concomitant medication/treatme nt/therapy was given or taken prior to [CMSTTPT] or prior to the date in DM.RFSTDTC.	Was the (concomitant) [medication/treatme nt/therapy] given/taken prior to [CMSTTPT]?; Was the (concomitant) [medication/treatme nt/therapy] given/taken prior to study start?	Prior to [CMSTTPT]; Prior to Study	Char	O	Check if the concomitant [medication/treat ment/therapy] was started before the study.	CMSTRF; CMSTRTPT	This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTM relative timing variable such as CMSTRF or CMSTRTPT. When populating CMSTRF, or CMSTRTPT, if the value of the CDASH field CMPRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When CMPRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable CMSTRF should be populated. When CMPRIOR is compared to another time point, the SDTM variables CMSTRTPT and CMSTTPT should be used. When CMONGO is used in conjunction with another time point, the SDTM variables CMENRTPT and CMENTPT should be used. Note: CMSTRTPT must refer to the time point anchor described in CMSTTPT.	(NY)	N/A	Sponsors may collect this information rather than start dates. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.
Interventions	CM	N/A	N/A	25	CMONGO	Ongoing Concomitant Meds	Indication the concomitant medication/treatme nt/therapy is ongoing when no end date is provided.	Was the (concomitant) [medication/treatme nt/therapy] ongoing (as of [the study- specific time point or period])?	Ongoing (as of [the study-specific time point or period])	Char	R/C	Record the concomitant [medication/treat ment/therapy] as ongoing if the subject has not stopped taking the concomitant [medication/treat ment/therapy] at [the timepoint defined by the study]. If the concomitant medication is ongoing, the end date should be left blank	CMENRF; CMENRTPT	This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as CMENRF or CMENRTPT. When populating CMENRF, if the value of CMONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating CMENRTPT, if the value of CMONGO is "Y", the value of "ONGOING" may be used. When CMONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable CMENRF should be populated. When CMONGO is used in conjunction with another time point, the SDTM variables CMENRTPT and CMENTPT should be used. Note: CMENRTPT must refer to a time point anchor described in CMENTPT.	(NY)	N/A	This box should be checked to indicate that the concomitant medication/treatment has not stopped at the time of data collection. It is expected that every recorded medication/treatment should have either an End Date or be checked as Ongoing, but not both. However, in cases where ongoing concomitant medications/treatments are not permitted, it may not be necessary to include an Ongoing field in the CRF. See Section 3.7, Mapping Relative Times from Collection to Submission, for more information about collecting relative date/time; see SDTMIG v3.2 Section 4.1.4 for information about mapping relative times.
Interventions	CM	N/A	N/A	26	CMENDAT	Concomitant Meds End Date	The date that the subject ended/stopped taking the concomitant medication/treatme nt/therapy represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the (concomitant) [medication/treatme nt/therapy/dose] end date?	End Date	Char	R/C	Record the date the concomitant [medication/treat ment] was stopped using this format (DD-MON- YYYY). If the subject has not stopped taking the concomitant [medication/treat ment] leave this field blank.	CMENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable CMENDTC in ISO 8601 format.	N/A	N/A	The assumption is that sponsors should either have an End Date or will indicate that the medication or therapy was ongoing at the time of collection or at the end of the study. However, in cases where the End Date can be determined from dates collected elsewhere in the CRF it is not necessary to include an End Date in the CRF. For example, if all concomitant medications/treatments are administered only once during a trial, the End Date will be the same as the Start Date.
Interventions	CM	N/A	N/A	27	CMENTIM	Concomitant Meds End Time	The time when the subject ended/stopped taking the concomitant medication/treatme nt/therapy represented in an unambiguous time format (e.g., hh:mm:ss).	What was the [medication/treatme nt/therapy/dose] end time?	End Time	Char	R/C	Record the time (as complete as possible) that the concomitant medication/treatm ent was stopped.	CMENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable CMENDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a concomitant medication or treatment was ended only when a protocol or data collection scenarios require it or the subject records the start time in a diary. Typically, an end time is not collected unless the subject is under the direct care of the site at the time a concomitant medication/treatment is stopped.
Interventions	CM	N/A	N/A	28	CMDECOD	Standardized Medication Name	The dictionary- or sponsor-defined standardized text description of the topic variable, CMTRT, or the modified topic variable (CMMODIFY), if applicable.	N/A	N/A	Char	O	N/A	CMDECOD	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. Equivalent to the generic drug name in WHODrug, or a term in SNOMED, ICD9, or other published or sponsor-defined dictionaries.
Interventions	CM	N/A	N/A	29	CMCLAS	CM Medication Class	The class for the intervention, often obtained from a coding dictionary.	N/A	N/A	Char	O	N/A	CMCLAS	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This would generally be the class used for analysis.
Interventions	CM	N/A	N/A	30	CMCLASCD	CM Medication Class Code	The assigned dictionary code for the class for the intervention.	N/A	N/A	Num	O	N/A	CMCLASCD	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Target".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This would generally be the class code used for analysis.
Interventions	CM	N/A	N/A	31	CMATC1	ATC Level 1 Description	Dictionary text description of the first level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the anatomical main group.	N/A	N/A	Char	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC1" and SUPPCM.QLABE L="ATC Level 1 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	32	CMATC1CD	ATC Level 1 Code	Dictionary code denoting the first level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the anatomical main group.	N/A	N/A	Num	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM ="MATC1CD" and SUPPCM.QLABE L="ATC Level 1 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	33	CMATC2	ATC Level 2 Description	Dictionary text description for the second level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic main group.	N/A	N/A	Char	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC2" and SUPPCM.QLABE L="ATC Level 2 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	34	CMATC2CD	ATC Level 2 Code	Dictionary code denoting the second level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic main group.	N/A	N/A	Num	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC2CD" and SUPPCM.QLABE L="ATC Level 2 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	35	CMATC3	ATC Level 3 Description	Dictionary text description of the third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharm acological subgroup.	N/A	N/A	Char	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC3" and SUPPCM.QLABE L="ATC Level 3 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.standard variables in SDTM domains.	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	36	CMATC3CD	ATC Level 3 Code	Dictionary code denoting the third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharm acological subgroup.	N/A	N/A	Num	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC3CD" and SUPPCM.QLABE L="ATC Level 3 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	37	CMATC4	ATC Level 4 Description	Dictionary text description of the fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeut ic/pharmacological subgroup.	N/A	N/A	Char	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC4" and SUPPCM.QLABE L="ATC Level 4 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	38	CMATC4CD	ATC Level 4 Code	Dictionary code denoting the fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeut ic/pharmacological subgroup.	N/A	N/A	Num	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC4CD" and SUPPCM.QLABE L="ATC Level 4 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	39	CMATC5	ATC Level 5 Description	Dictionary text description of the fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification system. Indicates the chemical substance.	N/A	N/A	Char	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC5" and SUPPCM.QLABE L="ATC Level 5 Description". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.
Interventions	CM	N/A	N/A	40	CMATC5CD	ATC Level 5 Code	Dictionary code denoting the fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification system. Indicates the chemical substance.	N/A	N/A	Num	O	N/A	SUPPCM.Q VAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPCM dataset as the value of SUPPCM.QVAL where SUPPCM.QNAM= "CMATC5CD" and SUPPCM.QLABE L="ATC Level 5 Code". Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. This is populated through the sponsor's coding process.

Assumptions for the CDASHIG CM - Prior and Concomitant Medications Domain

1. General medications/treatments are defined as any medications/treatments 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. Additional information might be sourced by referring to a subject’s medical record.

2. Medications of interest are defined as any medications or classes of drugs specifically mentioned in the protocol and were not the primary focus for determining the CDASHIG Core designations for the domain (e.g., excluded medications, drugs requiring a washout period prior to dosing in study, rescue medications).

3. As with all the data collection variables recommended in the CDASH standard, 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).

4. The CMOCCUR field provides a structure for capturing the occurrence of specific medications of interest.

5. Sponsors wishing to capture non-pharmacological therapies (e.g., surgery procedures, aromatherapy, massage, acupuncture) can use the Procedures (PR) domain.

Example CRF for the CDASHIG CM - Prior and Concomitant Medications Domain

Example 1

Title: Concomitant Medications



CRF Metadata

Order	CDASH Variable	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	CMCAT	What is the category for the medication?	Concomitant Medication Category	Record the medication category, if not preprinted on the CRF.	Text	CMCAT				GENERAL			Yes
2	CMYN	Were any concomitant medications taken?	Any Concomitant Medications	Indicate if the subject took any concomitant medications/treatments. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes
3	CMSPID	What is the medication identifier?	CM Number	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Text	CMSPID					prompt
4	CMTRT	What was the medication?	Concomitant Medication	Record only one treatment per line. Provide the full trade or proprietary name of the medication/treatment; otherwise, record the generic name .	Text	CMTRT
6	CMINDC	For what indication was the medication taken?	Indication	Record the reason the medication was taken based on clinical investigator's evaluation. If taken to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If taken to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for " and include a description of the condition(s).	Text	CMINDC
7	CMDSTXT	What was the individual dose of the medication?	Dose	Record the dose of medication/treatment per administration (e.g., 200).	Text	CMDOSTXT; CMDOSE	CMDOSTXT/ CMDOSE				prompt
8	CMDOSU	What is the unit?	Unit	Record the dose unit of the dose of concomitant medication/treatment taken (e.g., mg).	Text	CMDOSU		(UNIT)	CAPSULE; g; IU; mg; mL; PUFF; TABLET; ug		prompt
9	CMDOSFRM	What was the dose form of the medication?	Dose Form	Record the pharmaceutical dosage form (e.g., TABLET CAPSULE, SYRUP) of delivery for the concomitant [medication/treatment/therapy] taken.	Text	CMDOSFRM		(FRM)	AEROSOL; CAPSULE; CREAM; GAS; GEL; OINTMENT; PATCH; POWDER; SPRAY; SUPPOSITORY; SUSPENSION; TABLET		prompt
10	CMDOSFRQ	What was the frequency of the medication?	Frequency	Record how often the medication was taken (e.g., BID, PRN).	Text	CMDOSFRQ		(FREQ)	BID; PRN; QD; QID; QM; QOD; TID		prompt
11	CMROUTE	What was the route of administration of the medication?	Route	Provide the route of administration for the medication.	Text	CMROUTE		(ROUTE)	INTRALESIONAL; INTRAMUSCULAR; INTRAOCULAR; INTRAPERITONEAL; NASAL; ORAL; RECTAL; RESPIRATORY (INHALATION); SUBCUTANEOUS; TOPICAL; TRANSDERMAL; VAGINAL		prompt
12	CMSTDAT	What was the start date?	Start Date	Record the date the concomitant medication/treatment was first taken using this format (DD-MON-YYYY). If the subject has been taking the concomitant medication/treatment for a considerable amount of time prior to the start of the study, it is acceptable to have an incomplete date. Concomitant medications taken during the study are expected to have a complete start date. Prior concomitant medications that are exclusionary should have both a start date and an end date.	Date	CMSTDTC					prompt
13	CMONGO	Is the medication ongoing?	Ongoing	Record the concomitant medication/treatment as ongoing if the subject has not stopped taking the concomitant medication/treatment at the time of data collection and the end date should be left blank.	Text	CMENRF; CMENRTPT	CMENRF or CMENRTPT	(NY)	Yes			checkbox
14	CMENDAT	What was the end date?	End Date	Record the date the concomitant medication/treatment was stopped using this format (DD-MON-YYYY). If the subject has not stopped taking the concomitant medication/treatment leave this field blank.	Date	CMENDTC					prompt

8.1.3 EC - Exposure as Collected and EX - Exposure

Description/Overview for the CDASHIG EC - Exposure as Collected and CDASHIG EX - Exposure Domains

In the SDTMIG, the Exposure (EX) domain is used to represent exposure to study treatment as described in the protocol. The Exposure as Collected (EC) domain is used to represent the data as collected on the CRF. The CDASHIG EC domain is used in a study when the SDTMIG EX domain cannot be directly populated with the data collected on the CRF.

CDASHIG EC is used when:

1. An alias for the actual treatment name is used (e.g., the study is masked) rather than the actual treatment name (e.g., the study is open label).

2. Exposure data are collected in non-protocol-specified units (e.g., tablets).

3. Scheduled and/or missed doses are collected.

4. Planned doses (e.g., a calculation based on body weight) are collected in addition to actual doses given.

A sponsor may choose to always collect exposure data using the CDASHIG EC domain.

Extensive discussion of the use of the EC and EX domains, including examples of data collection, is available in the SDTMIG.

Specification for the CDASHIG EC - Exposure as Collected and EX - Exposure Domains

Exposure as Collected Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Interventions	EC	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Interventions	EC	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Interventions	EC	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Interventions	EC	N/A	N/A	4	EPOCH	Epoch	Name of the Trial Epoch with which this Element of the Arm is associated.	What is the trial epoch?	[Epoch](Period/Phase/ Sponsor-defined phrase)	Char	R/C	[protocol specific]	EPOCH	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EPOCH)	N/A	If the same information is collected more than once in different periods/parts of a study (e.g., Disposition), EPOCH may be needed to differentiate them. Typically, the trial epoch will be preprinted on the CRF as the title of the page. See SDTMIG for further information regarding EPOCH.
Interventions	EC	N/A	N/A	5	ECYN	Any Study Treatment Taken	An indication whether or not the subject took study medication/ treatment.	Were any[study treatment/dose] taken?	Any Study Treatments	Char	O	Indicate if the subject took any study medications. If Yes, include the appropriate details where indicated.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank. The ECYN is meant to indicate that the exposure as collected form should be completed or inserted into the case book. ECOCCUR would be used when the actual drug name is preprinted on the CRF. While these might be equivalent in a single drug study, there are differences in how they would be used in most trials. Therefore, it does not map into the SDTM variable ECOCCUR, since ECOCCUR indicates whether the subject was actually administered treatment/medication. If actual treatment data is available (ECYN ="Y"), ECOCCUR may be populated based on whether subject was actually administered treatment/medication.
Interventions	EC	N/A	N/A	6	ECCAT	Category of Treatment	A grouping of topic- variable values based on user defined characteristics.	What is the category of the [study treatment/dose]?	[Study Treatment Category]; NULL	Char	O	Record the study treatment category, if not pre-printed on the CRF.	ECCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Interventions	EC	N/A	N/A	7	ECSCAT	Subcategory of Treatment	A sub-division of the ECCAT values based on user-defined characteristics.	What is the subcategory of the [study treatment/dose]?	[Study Treatment Subcategory]; NULL	Char	O	Record the study treatment subcategory, if not pre-printed on the CRF.	ECSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. ECSCAT can only be used if there is an ECCAT and it must be a subcategorization of ECCAT.
Interventions	EC	N/A	N/A	8	ECTRT	Treatment	Name of the intervention or treatment known to the subject and/or administrator.	What was the [study treatment/investigational product] name?	[Study Treatment/Investigational Product Name]	Char	R/C	Record the name of study treatment.	ECTRT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	ECTRT is the name of the intervention or treatment known to the subject and/or administrator and it is the SDTM topic variable. It is a equired variable in SDTM and must have a value in CDASH or a plan to populate it in the SDTM submission datasets (i.e., collected or populated from other sources). In a masked study, if treatment is collected and known as Tablet A to the subject or administrator, then ECTRT="TABLET A". If in a masked study the treatment is not known by a synonym and the data are to be exchanged between sponsors, partners and/or regulatory agency(s), then assign ECTRT the value of "MASKED".
Interventions	EC	N/A	N/A	9	ECPRESP	Exposure as Collected Pre- Specified	An indication that a specific intervention or a group of interventions is prespecified on a CRF.	N/A	N/A	Char	O	N/A	ECPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	For prespecified interventions, a hidden field on a CRF defaulted to "Y", or added during the SDTM dataset creation. If a study collects both prespecified interventions as well as free-text interventions, the value of ECPRESP should be "Y" for all prespecified interventions and null for interventions reported as free-text.
Interventions	EC	N/A	N/A	10	ECOCCUR	Exposure as Collected Occurrence	An indication whether the study treatment was administered when information about the occurrence of a specific intervention is solicited.	Was [study treatment/dose] administered?; Has the subject taken [study treatment/dose]?	[Study Medication/Treatment]	Char	O	Indicate if the subject took study treatment. If Yes, include the appropriate details where indicated.	ECOCCUR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. Not applicable when ECMOOD is "Scheduled".	(NY)	N/A	ECOCCUR is used to indicate whether the subject was actually administered treatment/medication. ECOCCUR should not be used to indicate that the question was not asked or answered.
Interventions	EC	N/A	N/A	11	ECREASOC	Exposure Reason for Occur Value	An explanation of why a scheduled study treatment administration did or did not occur.	What was the reason that the[study treatment/dose] was (not)taken?	Reason (Not) Taken	Char	O	Indicate why the study treatment was or wasnot taken.	SUPPEC.QVAL	This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM="ECREASOC" and SUPPEC.QLABEL ="Reason for Occur Value". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	The reason the study treatment was or was not taken may be chosen from a sponsor-defined codelist (e.g., SUBJECT MISTAKE, SUBJECT REFUSED) or entered as free text. When --REASOC is used, --OCCUR must also be populated in the SDTM dataset with a value of "Y" or "N".
Interventions	EC	N/A	N/A	12	ECMOOD	Exposure as Collected Mood	Mode or condition of the record specifying whether the intervention (activity) is intended to happen or has happened.	Does this record describe scheduled [study treatment/dose] or performed [study treatment/dose]?	Scheduled/Performed	Char	O	Indicate if this record has happened or is intended to happen.	ECMOOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. When implemented ECMOOD must be populated for all records.	(BRDGMOOD)	N/A	"SCHEDULED" is for collected subject-level intended dose records. "PERFORMED" is for collected subject-level actual dose records. "Planned" or "Scheduled" can be pre-printed as the CRF name or section header, as applicable. If collecting both the scheduled and performed dosing in the same horizontal record, the sponsor may choose to append "_SCHEDULED" to the ECDOSE/ECDOSTXT variable name to delineate the scheduled dose from the performed dose. The performed dose would just be collected with ECDOSE/ECDOSTXT and ECDOSU.
Interventions	EC	N/A	N/A	13	ECREFID	Exposure as Collected Reference ID	An internal or external identifier such as kit number, bottle label, or vial identifier.	What is the[study treatment/dose] label identifier?	[Study Treatment] Label Identifier	Char	O	Record treatment label identifier.	ECREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This packaging identifier (e.g., kit number, bottle label, vial identifier) may be collected in different ways (e.g., affixing label onto CRF, scanning a bar code). For some study dosing regimens, greater granularity for treatment identifiers may be needed. In this situation, sponsors may need to use additional variables.
Interventions	EC	N/A	N/A	14	ECLOT	Lot Number	Lot Number of the ECTRT product.	What was the lot number of the[study treatment/dose] used?	Lot Number	Char	R/C	Record the lot number that appears on the container holding the study treatment.	ECLOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The Lot Number identifies the manufacturing batch of the study treatment. In open-label studies, the reference number on the study treatment container may represent an actual Lot Number and should be submitted using ECLOT. This variable may be populated during the process of creating the SDTM submission datasets. Do not collect other identification variables in this field.
Interventions	EC	N/A	N/A	15	ECFAST	Exposure as Collected Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	O	Record whether the subject was fasting prior to the study treatment being taken.	ECFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. Would only be populated when ECMOOD="PERFORMED".	(NY)	N/A	Some study treatments may have a food effect and it is important to know whether the dose was taken while the subject was fasted.
Interventions	EC	N/A	N/A	16	ECDOSFRM	Exposure as Collected Dose Form	The dosage form in which the ECTRT is physically presented	What was the dose form of the [study treatment/dose]?	Dose Form	Char	R/C	Record the dose form (e.g., SOLUTION, TABLET, LOTION) or enter the appropriate code from the code list.	ECDOSFRM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FRM)	(EXDOSFRM)	This must be collected if it cannot be determined from other sources or if there are multiple options for the same study treatment.
Interventions	EC	N/A	N/A	17	ECSTDAT	Exposure as Collected Start Date	The start date of study treatment, intended or actual, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the ([intended/planned/actual]) ([study treatment/dose]) (start) date?	(Start) Date	Char	HR	Record the start date of the study treatment administration using this format (DD-MON-YYYY).	ECSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable ECSTDTC in ISO 8601 format.	N/A	N/A	Date when constant dosing interval of the study treatment started or single administration occurred. When collecting the date for an individual dose, the word "start" may be omitted from the Question Text and Prompt. When ECMOOD is collected and ECMOOD is "SCHEDULED", use "intended" in the question text and prompt. When ECMOOD is collected and ECMOOD is "PERFORMED", use "actual" in the question text and prompt.
Interventions	EC	N/A	N/A	18	ECSTTIM	Exposure as Collected Start Time	The start time of study treatment, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the ([intended/planned/actual]) ([study treatment/dose]) (start) time?	(Start) Time	Char	R/C	Record the start time (as complete as possible) when administration of study treatment started.	ECSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable ECSTDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a medication was started only when a protocol or data collection scenarios requires it. When collecting the time for an individual dose, the word "start" may be omitted from the Question Text and Prompt.
Interventions	EC	N/A	N/A	19	ECENDAT	Exposure as Collected End Date	The end date of study treatment, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the ([intended/planned/actual]) ([study treatment/dose]) (end) date?	(End) Date	Char	R/C	Record the end date of the study treatment administration using this format (DD-MON-YYYY).	ECENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable ECENDTC in ISO 8601 format.	N/A	N/A	Date when study treatment period stopped.If start date and end date are not expected to be on the same date, the collection of the end date is required. If the study design indicates that the start and end date are on the same day, the collection of the end date is not required because it can be assigned to be equal to the start date.
Interventions	EC	N/A	N/A	20	ECENTIM	Exposure as Collected End Time	The end time of study treatment, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the ([intended/planned/actual]) ([study treatment/dose]) (end) time?	(End) Time	Char	R/C	Record the time, (as complete as possible) when study treatment administration stopped (e.g., for infusions this is the time when the infusion ended).	ECENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable ECENDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a medication was ended when a protocol or data collection scenarios requires it. For infusions, the end time of the infusion is typically needed.
Interventions	EC	N/A	N/A	21	ECDSTXT	Exposure as Collected Dose Description	The dose of study medication taken (per administration).	What was the dose (per administration) (of [study treatment/dose])?	Dose	Char	R/C	Record the dose or amount of study treatment that was administered to/taken by the subject in the period recorded; from the start date/time to the end date/time inclusive.	ECDOSTXT; ECDOSE	This does not map directly to an SDTMIG variable. The data collected in this dose text-format field should be mapped to either ECDOSE if numeric or ECDOSTXT if text.	N/A	N/A	Dose or amount taken for single administration of study treatment or per constant dosing interval recorded. Dose must be collected if it cannot be determined via other methods (e.g., from diary data, drug accountability data, protocol). Care should be taken when mapping ECDSTXT. The data collected in this dose text-format field should be separated or mapped to either ECDOSE if numeric or ECDOSTXT if text.
Interventions	EC	N/A	N/A	22	ECDOSU	Exposure as Collected Dose Units	The unit for intended dose (per administration) for ECDOSE, ECDOSTOT, or ECDOSTXT.	What were the units for the dose?	Units	Char	R/C	Record the unit of dose or amount taken per period recorded (e.g., ng, mg, mg/kg).	ECDOSU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	(EXDOSU)	Unit of dose or amount taken per constant dosing interval recorded. Dose unit must be collected if it cannot be determined via other methods (e.g., determined from protocol, randomization data). The unit should be preprinted on the CRF or a field provided on the CRF to capture it. A CDASH Subset Controlled Terminology Codelist Name is available for dose and volume units. In blinded trials, the collected unit may be tablet, capsule, etc., since the actual unit is also blinded.
Interventions	EC	N/A	N/A	23	ECDOSFRQ	EC Dosing Frequency per Interval	The number of doses given/administered/taken during a specific interval.	What was the frequency of [study treatment/dose] dosing?	Frequency	Char	R/C	Record the frequency the study treatment was administered for a defined period of time (e.g., BID, QID, TID).	ECDOSFRQ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FREQ)	(EXDOSFRQ)	This may be collected if it cannot be determined from other sources or if there are multiple options. When possible, the options for dose/amount frequency are pre- printed on the CRF. When collected, the recommendation is to collect dosing information in separate fields (e.g., ECDOSE, ECDOSEU, ECDOSFRQ) for specific and consistent data collection and to enable programmatically utilizing these data.
Interventions	EC	N/A	N/A	24	ECROUTE	EC Route of Administration	The route of administration of the study treatment.	What was the route of administration (of the [study treatment/dose])?	Route	Char	R/C	Record the route of administration (e.g., IV, ORAL, TRANSDERMAL) or enter the appropriate code from the code list.	ECROUTE	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ROUTE)	(EXROUTE)	This may be collected if it cannot be determined via other methods (e.g., from protocol) or if there are multiple options.
Interventions	EC	N/A	N/A	25	ECDOSRGM	Intended Dose Regimen	The text description of the (intended) schedule or regimen for the Intervention.	What was the intended dose regimen?	Intended Dose Regimen	Char	O	Record the regimen for the study medication.	ECDOSRGM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The regimen information (e.g., TWO WEEKS ON, TWO WEEKS OFF) may further clarify the dose administration and dose frequency. This may be preprinted or collected. The sponsor may wish to create a codelist to collect this data consistently.
Interventions	EC	N/A	N/A	26	ECDOSADJ	Dose Adjusted	An indication whether or not the dose was adjusted.	Was the dose adjusted?	(Dose) Adjusted	Char	O	Select either Yes or No to indicate whether there was a change in dosing.	N/A	When ECADJ is collected, does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED. When ECADJ is not collected, the sponsor may submit this variable in SUPPEC.	(NY)	N/A	Typically, the intent/purpose of collecting this field is to help with data cleaning and monitoring as it provides a definitive response regarding any dose changes. It provides verification that the associate field on the CRF (ECADJ) was deliberately left blank. However, the sponsor may collect whether the dose was adjusted, without collecting the reason for the change. When using ECMOOD, this field should not be used.
Interventions	EC	N/A	N/A	27	ECADJ	Reason for Dose Adjustment	Description or explanation of why a dose of the study treatment is adjusted.	What was the reason the dose was adjusted?	Reason Adjusted	Char	O	If there was a change in dosing, record the reason for change.	ECADJ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Captures the reason the dose was changed or modified. The reason may be chosen from a sponsor-defined list (e.g., adverse event, insufficient response) or entered as free text. May be used for variations from protocol-specified doses, or changes from expected doses. Used only when an adjustment is represented in EX dataset.
Interventions	EC	N/A	N/A	28	ECITRPYN	EC Exposure Interrupted	An indication whether of not the exposure was interrupted.	Was the [(study) treatment/dose] interrupted?	[(Study) Treatment / Dose] Interrupted	Char	O	Record if there was an interruption in the study treatment or dosing.	N/A	Does not map to an SDTMIG variable. The SDTMIG Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring when the actual duration of the exposure is collected using the CDASH field ECCINTD. In some situations, if the actual duration of the interruption is not collected, or not derived, this information could be submitted in a SUPPEC.QVAL dataset where SUPPEC.QNAM = "ECITRPYN" and SUPPEC.QLABEL = "Exposure Interrupted".
Interventions	EC	N/A	N/A	29	ECCINTD	EC Interruption Duration	The collected duration of the treatment interruption.	What was the duration of the treatment interruption?	(Interruption) Duration	Char	O	Record the duration of treatment interruption.	SUPPEC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM="ECITRPD" and SUPPEC.QLABEL= "Interruption Duration". Concatenate the collected treatment interruption duration and the duration unit components and create ECITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	This field is used to collect the duration of treatment interruption. In some situations, the duration of the interruption may not be collected but calculated from the treatment start and end times recorded elsewhere in the CRF.
Interventions	EC	N/A	N/A	29	ECCINTDU	EC Interruption Duration Units	The unit for the collected duration of treatment interruption.	What was the interruption duration unit?	(Interruption Duration) Unit	Char	O	Record the unit (e.g., MINUTES, HOURS, DAYS) for the duration of treatment interruption.	SUPPEC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM = "ECITRPD" and SUPPEC.QLABEL= "Interruption Duration". Concatenate the collected treatment interruption duration and the duration unit components and create ECITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(UNIT)	(EXCINTDU)	The unit should be collected as a qualifier to the number for duration.
Interventions	EC	N/A	N/A	30	ECLOC	EC Location of Dose Administration	A description of the anatomical location of administration.	What was the anatomical location of the ([study treatment/dose]) administration?	Anatomical Location	Char	O	Record the body location where the study treatment was administered (e.g., SHOULDER, HIP, ARM).	ECLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location where the study treatment was administered. LAT, DIR, PORTOT are used to further describe the anatomical location.
Interventions	EC	N/A	N/A	31	ECLAT	Exposure as Collected Laterality	Qualifier for anatomical location further detailing side of the body for the study treatment administration.	What was the side of the anatomical location of the ([study treatment/dose]) administration?	Side	Char	O	Record the side of the body location where the study treatment was administered (e.g., Left, Right).	ECLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	Further details the laterality of the location where the study treatment was administered. This may be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	EC	N/A	N/A	32	ECDIR	Exposure as Collected Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the ([study treatment/dose]) administration?	Directionality	Char	O	Record the directionality of the body location where the study treatment was administered (e.g., Anterior, Lower, Proximal, Upper).	ECDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	EC	N/A	N/A	33	ECVAMT	EC Vehicle Amount	The amount of the prepared product (treatment + vehicle) administered or given.	What was the total amount (Drug + Vehicle) (of [study treatment/dose]) administered?	Total Amount (Drug + Vehicle)	Num	O	Record the total amount (treatment +vehicle) that was administered/given to the subject.	ECVAMT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTM variable ECTRTV may also be populated during the process of creating the SDTM submission datasets.	N/A	N/A	Administration amount that was given to the subject. Note: should not be the diluent amount alone. The ECTRTV field may be collected if it cannot be determined from other sources.
Interventions	EC	N/A	N/A	34	ECVAMTU	EC Vehicle Amount Units	The unit of measurement for the prepared product (treatment + vehicle).	What was the unit for the amount (of [study treatment/dose]) administered?	Unit	Char	O	Record the unit of total amount (treatment +vehicle) administered/given to the subject (e.g., mL).	ECVAMTU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Unit of the administration amount.
Interventions	EC	N/A	N/A	35	ECFLRT	Exposure as Collected Infusion Rate	The flow rate for the total amount of drug + vehicle administered to the subject.	What was the [study treatment/dose] infusion rate?	Infusion Rate	Num	O	Record the Rate of Infusion (e.g., if rate is 10 mL/min. Record 10 as the infusion rate).	SUPPEC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM="ECFLRT" and SUPPEC.QLABEL= "Infusion Rate". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	Infusion rate can be used to derive dose.
Interventions	EC	N/A	N/A	36	ECFLRTU	Exposure as Collected Infusion Rate Unit	The unit of measure for the flow rate for the total amount of drug + vehicle administered to the subject.	What was the unit for the ([study treatment/dose]) infusion rate?	Infusion Rate Unit	Char	O	Record the unit for the infusion rate (e.g., mL/min).	SUPPEC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM="ECFLRTU" and SUPPEC.QLABEL= "Infusion Rate Unit". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(UNIT)	(EXFLRTU)	Unit of the infusion rate.
Interventions	EC	N/A	N/A	37	ECTPT	EC Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point for [study treatment/dose]?	[Planned Time Point Name]	Char	R/C	Record the planned time point of study treatment administration if not pre-printed on the CRF.	ECTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors ECTPTREF (text description) and ECRFTDTC (date/time) may be needed, as well as SDTMIG variables ECTPTNUM, ECELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Interventions	EC	N/A	N/A	38	ECTRTCMP	Completed Treatment	An indication whether the subject completed the intended regimen.	Did the subject complete the full course of [study treatment/dose]?	Completed Treatment	Char	O	Select either Yes or No to indicate whether subject has completed the full course of treatment.	SUPPEC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEC dataset as the value of SUPPEC.QVAL where SUPPEC.QNAM = "ECTRTCMP" and SUPPEC.QLABEL ="Completed Treatment". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Depending on how the study treatment details are collected via the CRF/eCRF, it may be possible to derive those data if the regimen data are collected.

Exposure Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Interventions	EX	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Interventions	EX	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Interventions	EX	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Interventions	EX	N/A	N/A	4	EPOCH	Epoch	Name of the Trial Epoch with which this Element of the Arm is associated.	What is the trial epoch?	[Epoch](Period/Phase/Sponsor-defined phrase)	Char	R/C	[protocol specific]	EPOCH	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EPOCH)	N/A	If the same information is collected more than once in different periods/parts of a study (e.g., Disposition), EPOCH may be needed to differentiate them. Typically, the trial epoch will be preprinted on the CRF as the title of the page. See SDTMIG for further information regarding EPOCH.
Interventions	EX	N/A	N/A	5	EXYN	Any Study Treatment Taken	An indication whether or not the subject took study medication/treatment.	Were any[study treatment/dose] taken?	Any Study Treatments	Char	O	Indicate if the subject took any study medications. If Yes, include the appropriate details where indicated. all other fields on the	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank. The EXYN variable is a cleaning or EDC convention meant to indicate that the exposure form should be completed or inserted into the case book.
Interventions	EX	N/A	N/A	6	EXCAT	Category of Treatment	A grouping of topic- variable values based on user-defined characteristics.	What is the category of the [study treatment/dose] ?	[Study Treatment Category]; NULL	Char	O	Record the study treatment category, if not preprinted on the CRF.	EXCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Interventions	EX	N/A	N/A	7	EXSCAT	Subcategory of Treatment	A sub-division of the EXCAT values based on user-defined characteristics.	What is the subcategory of the [study treatment/dose] ?	[Study Treatment Subcategory]; NULL	Char	O	Record the study treatment subcategory, if not preprinted on the CRF.	EXSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. EXSCAT can only be used if there is an EXCAT and it must be a subcategorization of EXCAT.
Interventions	EX	N/A	N/A	8	EXTRT	Name of Treatment	Name of the study treatment or intervention given per single administration or during the "constant dosing interval" for the observation.	What was the [study treatment/investigational product] name?	[Study Treatment/Investigational Product Name]	Char	R/C	Record the name of study treatment.	EXTRT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	EXTRT captures the name of the investigational treatment. This is typically collected for open label studies and populated for blinded studies during the SDTM-based dataset creation. Since EXTRT is the SDTMIG topic variable, it is a required variable in SDTM and must have a value in CDASH or a plan to populate it in the SDTM submission datasets (i.e., collected or populated from other sources).
Interventions	EX	N/A	N/A	9	EXREFID	Exposure Reference ID	An internal or external identifier such as kit number, bottle label, vial identifier.	What is the [study treatment/dose] label identifier?	Treatment Label Identifier	Char	R/C	Record treatment label identifier.	EXREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This packaging identifier (e.g., kit number, bottle label, vial identifier) may be collected in different ways (e.g., affixing label onto CRF, scanning a bar code). For some study dosing regimens, greater granularity for treatment identifiers may be needed.
Interventions	EX	N/A	N/A	10	EXLOT	Lot Number	Lot Number of the EXTRT product.	What was the lot number of the[study treatment/dose] used?	Lot Number	Char	R/C	Record the lot number that appears on the container holding the study treatment.	EXLOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The Lot Number identifies the manufacturing batch of the study treatment. In open label studies, the reference number on the study treatment container may represent an actual Lot Number and is submitted using EXLOT. This variable may be populated during the process of creating the SDTM submission datasets. Do not collect other identification variables in this field.
Interventions	EX	N/A	N/A	11	EXFAST	Exposure Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	O	Record whether the subject was fasting prior to the study treatment being taken.	EXFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Some study treatments may have a food effect and it is important to know whether the dose was taken while the subject was fasted.
Interventions	EX	N/A	N/A	12	EXDOSFRM	Exposure Dose Form	The dosage form in which the EXTRT is physically presented.	What was the dose form of the [study treatment/dose] ?	Dose Form	Char	R/C	Record the dose form (e.g., SOLUTION, TABLET, LOTION) or enter the appropriate code from the code list.	EXDOSFRM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FRM)	(EXDOSFRM)	This must be collected if it cannot be determined from other sources or if there are multiple options.
Interventions	EX	N/A	N/A	13	EXSTDAT	Exposure Start Date	The [start] date of study treatment, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the ([intended/planned/actual]) ([study treatment/dose]) (start) date?	(Start) Date	Char	HR	Record the start date of the study treatment administration using this format (DD-MON-YYYY).	EXSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable EXSTDTC in ISO 8601 format.	N/A	N/A	Date when constant dosing interval of the study treatment started or single administration occurred. When collecting the date for an individual dose, the word "start" may be omitted from the Question Text and Prompt.
Interventions	EX	N/A	N/A	14	EXSTTIM	Exposure Start Time	The [start] time of the study treatment, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the ([intended/planned/actual]) ([study treatment/dose]) (start) time?	(Start) Time	Char	R/C	Record the start time (as complete as possible) when administration of study treatment started.	EXSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable EXSTDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a medication was started only when a protocol or data collection scenarios requires it.
Interventions	EX	N/A	N/A	15	EXENDAT	Exposure End Date	The end date of study treatment, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the ([intended/planned/actual]) ([study treatment/dose]) (end) date?	(End) Date	Char	R/C	Record the end date or last date of administration of study treatment using this format (DD-MON-YYYY).	EXENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable EXENDTC in ISO 8601 format.	N/A	N/A	If start date and end date are not expected to be on the same date, the end date is required. If the study design indicates that the start and end date are on the same day, the end date is not required since it can be assigned to be equal to the start date.
Interventions	EX	N/A	N/A	16	EXENTIM	Exposure End Time	The end time of treatment, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the ([intended/planned/actual]) ([study treatment/dose]) (end) time?	(End) Time	Char	R/C	Record the time, (as complete as possible) when study treatment administration stopped (e.g., for infusions this is the time when the infusion ended).	EXENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable EXENDTC in ISO 8601 format.	N/A	N/A	Recommend collecting the time a medication was ended when a protocol or data collection scenarios requires it. For infusions, the end time of the infusion is typically needed.
Interventions	EX	N/A	N/A	17	EXDSTXT	Exposure Dose Description	Dose [per administration].	What was the dose [per administration] (of [study treatment/dose]) ?	Dose	Char	R/C	Record the dose or amount of study treatment that was administered to/taken by the subject in the period recorded; from the start date/time to the end date/time inclusive.	EXDOSTXT;EXDOSE	This does not map directly to an SDTMIG variable. Numeric values map to EXDOSE in SDTM. Non- numeric values (e.g., 200- 400) map to EXDOSTXT in SDTM.	N/A	N/A	Dose or amount taken for single administration of study treatment or per constant dosing interval recorded. Dose must be collected if it cannot be determined via other methods (e.g., from diary data, drug accountability data, protocol). The data collected in this dose text-format field should be mapped to either SDTMIG variable EXDOSE (if numeric) or EXDOSTXT (if text).
Interventions	EX	N/A	N/A	18	EXDOSU	Exposure Dose Unit	The unit for intended dose [per administration] for EXDOSE, EXDOSTOT, or EXDOSTXT.	What was the unit for the dose?	Unit	Char	R/C	Record the unit of dose or amount taken per period recorded (e.g., ng, mg, mg/kg).	EXDOSU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Unit of dose or amount taken per constant dosing interval recorded. Dose unit must be collected if it cannot be determined via other methods (e.g., from protocol, randomization data). The unit should be preprinted on the CRF or a field provided on the CRF to capture it. A CDASH Subset Controlled Terminology Codelist Name is available for general dose and volume units.
Interventions	EX	N/A	N/A	19	EXDOSFRQ	Exposure Dosing Frequency per Interval	The number of doses given/administered/taken during a specific interval.	What was the frequency of[study treatment/dose] dosing?	Frequency	Char	R/C	Record the frequency the study treatment was administered for a defined period of time.	EXDOSFRQ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FREQ)	N/A	This may be collected if it cannot be determined from other sources or if there are multiple options. When possible, the options for dose/amount frequency are preprinted on the CRF. When collected, the recommendation is to collect dosing information in separate fields (e.g., ECDOSE, ECDOSEU, ECDOSFRQ) for specific and consistent data collection and to enable programmatically utilizing these data.
Interventions	EX	N/A	N/A	20	EXROUTE	Exposure Route of Administration	The route of administration of the study treatment.	What was the route of administration (of the [study treatment/dose] )?	Route	Char	R/C	Record the route of administration (e.g., IV, ORAL, TRANSDERMAL) or enter the appropriate code from the code list.	EXROUTE	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ROUTE)	(EXROUTE)	This may be collected if it cannot be determined via other methods (e.g., from protocol) or if there are multiple options.
Interventions	EX	N/A	N/A	21	EXDOSRGM	Intended Dose Regimen	The text description of the (intended) schedule or regimen for the Intervention.	What was the intended dose regimen (of the [study treatment/dose] )?	Intended Dose Regimen	Char	O	Record the regimen for the study medication.	EXDOSRGM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The regimen information may further clarify the dose administration and dose frequency (e.g., TWO WEEKS ON, TWO WEEKS OFF). This may be preprinted or collected. The sponsor may wish to create a codelist to collect this data consistently.
Interventions	EX	N/A	N/A	22	EXDOSADJ	Dose Adjusted	An indication whether or not the dose was adjusted.	Was the dose adjusted?	(Dose) Adjusted	Char	O	Select either Yes or No to indicate whether there was a change in dosing.	N/A	When EXADJ is collected, does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED. When EXADJ is not collected, the sponsor may submit this variable as a SUPPQ.	(NY)	N/A	Typically, the intent/purpose of collecting this field is to help with data cleaning and monitoring as it provides a definitive response regarding any dose changes. It provides verification that the associate field on the CRF (EXADJ) was deliberately left blank. However, the sponsor may collect whether the dose was adjusted, without collecting the reason for the change.
Interventions	EX	N/A	N/A	23	EXADJ	Reason for Dose Adjustment	Description or explanation of why a dose of the study treatment is adjusted.	What was the reason the dose was adjusted (from planned)?	Reason Adjusted	Char	O	If there was a change in dosing, record the reason for change.	EXADJ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Captures the reason the dose was changed or modified. The reason may be chosen from a sponsor-defined list (e.g., adverse event, insufficient response) or entered as free text. May be used for variations from protocol-specified doses, or changes from expected doses.
Interventions	EX	N/A	N/A	24	EXITRPYN	EX Exposure Interrupted	An indication whether of not the exposure was interrupted.	Was the [(study) treatment/dose] interrupted?	[(Study) Treatment / Dose] Interrupted	Char	O	Record if there was an interruption in the study treatment or dosing.	N/A	Does not map to an SDTMIG variable. The SDTMIG Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring when the actual duration of the exposure is collected using the CDASH field EXCINTD. In some situations, if the actual duration of the interruption is not collected, or not derived, this information could be submitted in a SUPPEX.QVAL dataset where SUPPEX.QNAM = "EXITRPYN" and SUPPEX.QLABEL = "Exposure Interrupted".
Interventions	EX	N/A	N/A	25	EXCINTD	Exposure Interruption Duration	The collected duration of the treatment interruption.	If the dose was interrupted, how long was the interruption?	(Interruption) Duration	Char	O	Record the duration of treatment interruption.	SUPPEX.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEX dataset as the value of SUPPEX.QVAL where SUPPEX.QNAM="EXITRPD" and SUPPEX.QLABEL= "Interruption Duration". Concatenate the collected treatment interruption duration and the duration unit components and create EXITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	In some situations, the duration of the interruption may be calculated from the administration start and end times recorded elsewhere in the CRF.
Interventions	EX	N/A	N/A	26	EXCINTDU	Exposure Interruption Duration Units	The unit for the collected duration of treatment interruption.	If the dose was interrupted, what were the units for the interruption duration?	(Interruption Duration) Unit	Char	O	Record the unit (e.g., MINUTES, HOURS, DAYS) for the duration of treatment interruption.	SUPPEX.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEX dataset as the value of SUPPEX.QVAL where SUPPEX.QNAM = "EXITRPD" and SUPPEX.QLABEL= "Interruption Duration". Concatenate the collected treatment interruption duration and the duration unit components and create EXITRPDusing ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(UNIT)	(EXCINTDU)	The unit should be collected and converted into ISO 8601 period format.
Interventions	EX	N/A	N/A	27	EXLOC	Exposure Location of Dose Administration	A description of the anatomical location of administration.	What was the anatomical location of the ([study treatment/dose] ) administration?	Anatomical Location	Char	O	Record the body location where the study treatment was administered (e.g., SHOULDER, HIP, ARM).	EXLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location where the study treatment was administered. LAT, DIR, PORTOT are used to further describe the anatomical location.
Interventions	EX	N/A	N/A	28	EXVAMT	Exposure Vehicle Amount	The amount of the prepared product (treatment + vehicle) administered or given.	What was the total amount (Drug + Vehicle)(of [study treatment/dose] ) administered?	Total Amount	Num	O	Record the total amount (treatment +vehicle) that was administered/given to the subject.	EXVAMT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTM variable ECTRTV may also be populated during the process of creating the SDTM submission datasets.	N/A	N/A	Administration amount that was given to the subject. Note: should not be the diluent amount alone. The ECTRTV field may be collected if it cannot be determined from other sources.
Interventions	EX	N/A	N/A	29	EXVAMTU	Exposure Vehicle Amount Units	The unit of measure for the prepared product (treatment + vehicle).	What was the unit for the amount (of [study treatment/dose] ) administered?	Unit	Char	O	Record the unit of total amount (treatment +vehicle) administered/given to the subject (e.g., mL).	EXVAMTU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	(EXVOLTU)	Unit of the administration amount. A CDASH Subset Controlled Terminology Codelist Name is available for dose and volume units.
Interventions	EX	N/A	N/A	30	EXFLRT	Exposure Infusion Rate	The flow rate for the total amount of drug + vehicle administered to the subject.	What was the [study treatment/dose] infusion rate?	Infusion Rate	Num	O	Record the Rate of Infusion (e.g., if rate is 10 mL/min. Record 10 as the infusion rate).	SUPPEX.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEX dataset as the value of SUPPEX.QVAL where SUPPEX.QNAM = "EXFLRT" and SUPPEX.QLABEL= "Infusion Rate". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	Infusion rate can be used to derive dose.
Interventions	EX	N/A	N/A	31	EXFLRTU	Exposure Infusion Rate Unit	The unit of measure for the flow rate for the total amount of drug + vehicle administered to the subject.	What were the units for the [study treatment/dose] infusion rate?	(Infusion Rate) Unit	Char	O	Record the unit for the infusion rate (e.g., mL/min).	SUPPEX.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEX dataset as the value of SUPPEX.QVAL where SUPPEX.QNAM ="EXFLRTU" and SUPPEX.QLABEL="Infusion Rate Unit". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(UNIT)	(EXFLRTU)	Unit of the infusion rate.
Interventions	EX	N/A	N/A	32	EXTPT	Exposure Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point for [study treatment/dose] ?	[Planned Time Point Name]	Char	R/C	Record the planned time point of study treatment administration if not preprinted on the CRF.	EXTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors EXTPTREF (text description) and EXRFTDTC (date/time) may be needed, as well as SDTMIG variables EXTPTNUM, EXELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Interventions	EX	N/A	N/A	33	EXTRTCMP	Completed Treatment	Subject did not did not complete the intended regimen.	Did the subject complete the full course of [study treatment/dose] ?	Completed Treatment	Char	O	Select either Yes or No to indicate whether subject has completed the full course of treatment.	SUPPEX.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEX dataset as the value of SUPPEX.QVAL where SUPPEX.QNAM = "EXTRTCMP" and SUPPEX.QLABEL=" Completed Treatment". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	Depending on how the study treatment details are collected via the CRF/eCRF, it may be possible to derive those data if the regimen data are collected.
Interventions	EX	N/A	N/A	34	EXLAT	Exposure Laterality	Qualifier for anatomical location further detailing side of the body for the study treatment administration.	What was the side of the anatomical location of the ([study treatment/dose] ) administration?	Side	Char	O	Record the side of the body location where the study treatment was administered (e.g., Left, Right).	EXLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	Further details the laterality of the location where the study treatment was administered. This may be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	EX	N/A	N/A	35	EXDIR	Exposure Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the ([study treatment/dose] ) administration?	Directionality	Char	O	Record the directionality of the body location where the study treatment was administered (e.g., Anterior, Lower, Proximal, Upper).	EXDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.

Assumptions for the CDASHIG EC - Exposure as Collected and EX - Exposure Domains

1. If the SDTMIG EC dataset would be an exact duplicate of the SDTMIG EX dataset, then the sponsor may choose to collect data using either the CDASHIG EC or EX domain. (See the SDTMIG for additional information on submission.)

2. The collected --TRT value is the name of the study treatment that is known to the subject or investigative site (e.g., ECTRT="TABLET A" when EXTRT=<'treatment name'>).

3. If dosing data are collected in non-protocol-specified units, the data are collected in CDASHIG EC dataset, then programmatically converted to the protocol-specified units when the data are mapped to the SDTMIG EX domain.

Dosing units specified in the protocol	Dosing information as collected on the CRF and represented in EC	Representation in EX
200 mg tablet	2 tablets	400 mg
100 mg capsule	1 capsule	100 mg
5 mg/kg	99 mL	5 mg/kg

4. If a treatment is such that start and stop times are not required, and only 1 dosing date is collected, then the collected dosing date will map to both the start date (--STDTC) and end date (--ENDTC) in the submitted exposure dataset(s).

5. If scheduled dosing is collected, the ECMOOD variable may be used to distinguish between "SCHEDULED" and "PERFORMED" dosing records. The sponsor may choose to use this variable to capture multiple scheduled dosing records, if needed.

6. ECOCCUR:

a. ECOCCUR value of "N" indicates a dose was not taken, not given, or missed.

b. ECOCCUR is generally not applicable for Scheduled records.

c. ECOCCUR = "N" is the standard representation of the collected doses not taken, not given, or missed.

7. Dose amount variables (e.g., ECDOSE, ECDOSTXT) must not be set to zero (0) as an alternative method for indicating doses not taken, not given, or missed.

Example CRFs for the CDASHIG EC- Exposure as Collected and CDASHIG EX - Exposure Domains

Example 1

Title: Exposure as Collected



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
EPOCH	1	What is the trial epoch?	Trial epoch	[protocol specific]	Text	EPOCH		(EPOCH)		TREATMENT	Prompt		Y
ECTRT	2	What was the study treatment name?	Study Treatment Name	Record the name of study treatment.	Text	ECTRT				DRUG A	Prompt		Y
ECREFID	3	What is the study treatment label identifier?	Study Treatment Label Identifier	Record treatment label identifier.	Text	ECREFID					Prompt
ECLOT	4	What was the lot number of the study treatment used?	Lot Number	Record the lot number that appears on the container holding the study treatment.	Text	ECLOT					Prompt
ECFAST	5	Was the subject fasting?	Fasting	Record whether the subject was fasting prior to the study treatment being taken.	Text	ECFAST		(NY)	Yes; No			Radio
ECSTDAT	6	What was the study treatment start date?	Start Date	Record the start date of the study treatment administration using this format (DD-MON-YYYY).	Date	ECSTDTC					Prompt
ECSTTIM	7	What was the study treatment start time?	Start Time	Record the start time (as complete as possible) when administration of study treatment started.	Time	ECSTDTC					Prompt
ECENDAT	8	What was the study treatment end date?	End Date	Record the end date of the study treatment administration using this format (DD-MON-YYYY).	Date	ECENDTC					Prompt
ECENTIM	9	What was the study treatment end time?	End Time	Record the time (as complete as possible) when study treatment administration stopped.	Time	ECENDTC					Prompt
ECDSTXT	10	What was the dose per administration of study treatment?	Dose	Record the dose or amount of study treatment that was administered to/taken by the subject in the period recorded; from the start date/time to the end date/time inclusive.	Text	ECDOSTXT; ECDOSE	ECDOSTXT / ECDOSE				Prompt
ECDOSU	11	What were the units for the dose?	Units	Record the unit of dose or amount taken per period recorded (e.g., tablet, capsule).	Text	ECDOSU		(UNIT)	TABLET; CAPSULE		Prompt	Radio
ECDOSFRQ	12	What was the frequency of study treatment dosing?	Frequency	Record the frequency the study treatment was administered for a defined period of time (e.g., QD, BID, TID).	Text	ECDOSFRQ		(FREQ)	QD; BID; TID		Prompt	Radio
ECROUTE	13	What was the route of administration of the study treatment?	Route	Record the route of administration (e.g., Oral, Sublingual).	Text	ECROUTE		(ROUTE)	ORAL; SUBLINGUAL		Prompt	Radio
ECDOSADJ	14	Was the dose adjusted?	Dose Adjusted	Select either Yes or No to indicate whether there was a change in dosing.	Text	N/A		(NY)	Yes; No			Radio
ECADJ	15	What was the reason the dose was adjusted?	Reason Adjusted	If there was a change in dosing, record the reason for change.	Text	ECADJ

Example 2

Title: Exposure as Collected – Missed Dose



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
ECOCCUR	1	Was study treatment administered?	Study Treatment	Indicate if the subject took study treatment. If Yes, include the appropriate details where indicated.	Text	ECOCCUR		(NY)		No			Y
ECCAT	2	What is the category of the study treatment?	Study Treatment Category	Record the study treatment category, if not pre-printed on the CRF.	Text	ECCAT				MISSED DOSE	Prompt		Y
ECTRT	3	What was the study treatment name?	Study Treatment Name	Record the name of study treatment.	Text	ECTRT				DRUG Z	Prompt		Y
ECSPID	4	What is the observation identifier?	Line Number	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Text	ECSPID				001	Prompt
ECSTDAT	5	What was the intended dose date?	Date	Record the intended start date of the study treatment administration using this format (DD-MON- YYYY).	Date	ECSTDTC					QText
ECREASOC	6	What was the reason that the study treatment was not taken?	Reason Not Taken	Indicate why the study treatment was not taken.	Text	SUPPEC.QVAL	SUPPEC.QVAL where SUPPEC.QNAM = "ECREASOC" and SUPPEC.QLABEL = "Reason for Occur Value"

Example 3

Title: Exposure as Collected - Scheduled vs Performed



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target	SDTM Variable Target	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
ECSTDAT	1	What was the intended dose date?	Date	Record the scheduled start date of the study treatment administration using this format (DD- MON-YYYY).	Date	ECSTDTC	ECSTDTC where ECMOOD = SCHEDULED
ECDOSE_SCHEDULED	2	What was the intended dose per administration of study treatment?	Intended Dose	Record the dose or amount of study treatment that is scheduled to be administered to/taken by the subject in the period recorded.	Float	ECDOSE	ECDOSE where ECMOOD = SCHEDULED				prompt
ECDOSU_SCHEDULED	3	What were the units for the dose?	Units	Record the unit of dose or amount taken per period recorded (e.g., ng, mg, mg/kg).	Text	ECDOSU	ECDOSU where ECMOOD = SCHEDULED	(UNIT)		mg/kg	prompt

Title: Exposure as Collected



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
ECOCCUR	3	Was the dose administered?	Dose Aministered	Indicate if the subject took study treatment. If Yes, include the appropriate details where indicated.	Text	ECOCCUR	ECOCCUR where ECMOOD = "PERFORMED"	(NY)	No; Yes		qtext
ECREASOC	4	What was the reason that the study treatment was not taken?	Reason Not Taken	Indicate why the study treatment was not taken.	Text	SUPPEC.QVAL					prompt
ECSTDAT	5	What was the start date?	Start Date	Record the start date of the study treatment administration using this format (DD- MON-YYYY).	Date	ECSTDTC	ECSTDTC where ECMOOD = "PERFORMED"				prompt
ECSTTIM	6	What was the start time?	Start Time	Record the start time (as complete as possible) when administration of study treatment started.	Time	ECSTDTC	ECSTDTC where ECMOOD = "PERFORMED"				prompt
ECENDAT	7	What was the end date?	End Date	Record the end date of the study treatment administration using this format (DD- MON-YYYY).	Date	ECENDTC	ECENDTC where ECMOOD = "PERFORMED"				prompt
ECENTIM	8	What was the end time?	End Time	Record the time (as complete as possible) when study treatment administration stopped (e.g., for infusions this is the time when the infusion ended).	Time	ECENDTC	ECENDTC where ECMOOD = "PERFORMED"				prompt
ECDOSE	11	What was the amount of study treatment administered?	Amount	Record the dose or amount of study treatment that was administered to/taken by the subject in the period recorded, from the start date/time to the end date/time inclusive.	Float	ECDOSE	ECDOSE where ECMOOD = "PERFORMED				prompt
ECDOSU	12	What was the unit for the dose?	Unit	Record the unit of dose or amount taken per period recorded (e.g., ng, mg, mg/kg).	Text	ECDOSU	ECDOSU where ECMOOD = PERFORMED"	(UNIT)		mL	prompt
ECPSTRG	13	What was the pharmaceutical strength of the study treatment?	Pharmaceutical Strength	Record the pharmaceutical strength or concentration of the study treatment that was administered to/taken by the subject in the period recorded.	Float	ECPSTRG	ECPSTRG where ECMOOD = "PERFORMED"
ECPSTRGU	14	What was the unit of the pharmaceutical strength of the study treatment?	Unit	Record the unit of concentration or strength of the study treatment per period recorded (e.g., ng, mg, mg/kg).	Text	ECPSTRGU	ECPSTRGU where ECMOOD = "PERFORMED"	(UNIT)		mg/mL

Example 4

Title: Exposure Start and Stop Dates



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Value	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
EPOCH	1	What is the trial period?	Trial Period	[protocol specific]	Text	EPOCH		(EPOCH)		TREATMENT	Prompt		Y
EXTRT	2	What was the study treatment?	Study Treatment Name	Record the name of study treatment.	Text	EXTRT				Sponsor Defined	Prompt		Y
EXSTDAT	3	What was the study treatment start date?	Start Date	Record the start date of the study treatment administration using this format (DD-MON-YYYY).	Date	EXSTDTC					Prompt
EXSTTIM	4	What was the study treatment start time?	Start Time	Record the start time (as complete as possible) when administration of study treatment started.	Time	EXSTDTC					Prompt
EXENDAT	5	What was the study treatment end date?	End Date	Record the end date or last date of administration of study treatment using this format (DD-MON-YYYY).	Date	EXENDTC					Prompt
EXENTIM	6	What was the study treatment end time?	End Time	Record the time (as complete as possible) when study treatment administration stopped (e.g., for infusions this is the time when the infusion ended).	Time	EXENDTC					Prompt

8.1.4 PR - Procedures

Description/Overview for the CDASHIG PR - Procedures Domain

The Procedures (PR) domain should be used to collect details describing a subject’s therapeutic and diagnostic procedures conducted before, during, and/or after the study. Measurements obtained from procedures are to be represented in the appropriate Findings domain(s). For example, the details of an endoscopy (e.g., date and time of start and stop) are represented in the PR domain; microscopic results would be represented in the Microscopic (MI) domain.

Specification for the CDASHIG PR - Procedures Domain

Procedures Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variablev	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Interventions	PR	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or created during SDTM-based dataset creation before submission.
Interventions	PR	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Interventions	PR	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Interventions	PR	N/A	N/A	4	PRYN	Any Procedures Performed	An indication whether or not the subject had any procedures performed.	Were any surgical, therapeutic, or diagnostic procedures performed?	Any Procedures	Char	O	Indicate if the subject had any surgical, therapeutic or diagnostic procedures. If "Yes", include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Interventions	PR	N/A	N/A	5	PRCAT	Procedure Category	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the procedure?	[Procedure Category]; NULL	Char	O	Record the procedure category, if not preprinted on the CRF.	PRCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Interventions	PR	N/A	N/A	6	PRSCAT	Procedure Subcategory	A sub-division of the PRCAT values based on user-defined characteristics.	What was the subcategory of the procedure?	[Procedure Subcategory]; NULL	Char	O	Record the procedure subcategory, if not preprinted on the CRF.	PRSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. PRSCAT can only be used if there is a PRCAT and it must be a subcategorization of PRCAT.
Interventions	PR	N/A	N/A	7	PRSPID	Procedure Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	PRSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile procedure records with medical history and/or with AEs. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Interventions	PR	N/A	N/A	8	PRTRT	Reported Name of Procedure	The verbatim surgical, therapeutic, or diagnostic procedure's name.	What was the procedure name?	[Procedure Name]; (Specify) Other	Char	HR	Record only one procedure per line.	PRTRT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	In most cases, the verbatim procedure names or therapy will be coded to a standard dictionary (e.g., MedDRA, SNOMED) after the data have been collected on the CRF.
Interventions	PR	N/A	N/A	9	PRDECOD	Standardized Procedure Name	The dictionary- or sponsor-defined standardized text description of PRTRT, or the modified topic variable (PRMODIFY), if applicable.	N/A	[Standardized Procedure Name]	Char	O	N/A	PRDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PROCEDUR)	N/A	This is typically not a data collection field that will appear on the CRF. If the sponsor chooses to code the procedure, the sponsor will populate this through the coding process. If PRPRESP is used, and the information about a specific standardized procedure name is being solicited, the data from PRTRT may map directly to the SDTMIG PRDECOD variable.
Interventions	PR	N/A	N/A	10	PRMODIFY	Modified Procedure Name	If the value for PRTERM is modified for coding purposes, then the modified text is placed here.	N/A	N/A	Char	O	N/A	PRMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that will appear on the CRF. If the sponsor chooses to code the procedure, the sponsor will populate this through the coding process.
Interventions	PR	N/A	N/A	11	PRPRESP	Procedure prespecified	An indication that a specific intervention or a group of interventions is prespecified on a CRF.	N/A	N/A	Char	O	N/A	PRPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	For prespecified interventions, a hidden field on a CRF defaulted to "Y", or added during the SDTM dataset creation. If a study collects both prespecified interventions as well as free-text interventions, the value of PRPRESP should be "Y" for all prespecified interventions and null for interventions reported as free text.
Interventions	PR	N/A	N/A	12	PROCCUR	Procedure Occurrence	An indication whether a prespecified procedure (PRTRT) happened when information about the occurrence of a specific intervention is solicited.	Was [PRDECOD/PRTRT] performed?; Has the subject had [PRDECOD/PRTRT]?	[PRDECOD/PRTRT] Performed	Char	O	Indicate if [specific procedure] was performed by checking Yes or No.	PROCCUR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. If the response was not asked or answered, populate the SDTMIG variable PRSTAT with "NOT DONE".	(NY)	N/A	PROCCUR is used to report the occurrence of a prespecified procedure or a group of procedures. PROCCUR is not used for spontaneously free text- reported procedures. The site should be able to indicate that the response was not asked or answered.
Interventions	PR	N/A	N/A	13	PRREASOC	Procedure Reason for Occur Value	An explanation of why a scheduled procedure did or did not occur.	What was the reason that the procedure was (not) performed?	Reason (Not) Performed	Char	O	Indicate why the procedure was or wasnot performed.	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM = "PRREASOC" and SUPPPR.QLABEL="Reason for Occur Value". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	The reason the scheduled procedure was or was not performed may be chosen from a sponsor-defined codelist (e.g., SUBJECT REFUSED) or entered as free text. When --REASOC is used, --OCCUR must also be populated in the SDTM dataset with a value of "Y" or "N".
Interventions	PR	N/A	N/A	14	PRREASND	Procedure Reason Not Done	An explanation of why the data are not available.	What was the reason not done?	Reason not done	Char	O	Provide the reason why the procedure was not done.	PRREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor-defined list (e.g., broken equipment, subject refused) or entered as free text. When PRREASND is used, the SDTMIG variable PRSTAT should also be populated in the SDTM-based dataset. The value "NOT DONE" here indicates that the subject was not questioned/data was not collected. It does not mean that the subject did not have the procedure.
Interventions	PR	N/A	N/A	15	PRPRIOR	Prior Procedure	Indication the procedure occurred prior to [PRSTTPT] or prior to the date in DM.RFSTDTC.	Was the procedure performed prior to [PRSTTPT]?; Was the procedure performed prior to study start?	Prior to [PRSTTPT]; Prior to study	Char	O	Check if the procedure was started before the specified point in time.	PRSTRTPT; PRSTRF	This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTM relative timing variable such as PRSTRF or PRSTRTPT. When populating PRSTRF, or PRSTRTPT, if the value of the CDASH field PRPRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When PRPRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable PRSTRF should be populated. When PRPRIOR is compared to another time point, the SDTM variables PRSTRTPT and PRSTTPT should be used. Note: PRSTRTPT must refer to the time point anchor described in PRSTTPT.	(NY)	N/A	See Section 3.7, Mapping Relative Times from Collection to Submissions, and and SDTMIG v3.2 Section 4.1.4.7 for more information. for information about mapping relative times.
Interventions	PR	N/A	N/A	16	PRSTDAT	Procedure Start Date	The date or start date of when the procedure started or was performed, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the procedure (start) date ?	(Start) Date	Char	R/C	Record the date the procedure was started or performed using this format (DD- MON-YYYY). Procedures performed during the study are expected to have a complete start date. Prior procedures that are exclusionary should have both a start and end date.	PRSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable PRSTDTC in ISO 8601 format.	N/A	N/A	The preferred method is to collect a complete Start Date. Partial dates (e.g., providing year only) for procedures started a considerable amount of time prior to the start of study are acceptable.
Interventions	PR	N/A	N/A	17	PRONGO	Ongoing Procedure	Indication the procedure is ongoing when no end date is provided.	Was the procedure ongoing (as of the [study-specific timepoint or period])?	Ongoing (as of the [study-specific timepoint or period])	Char	O	Indicate if the procedure has not ended at the time of data collection and the end date should be left blank.	PRENRTPT; PRENRF	This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as PRENRF or PRENRTPT. When populating PRENRF, if the value of PRONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating PRENRTPT, if the value of PRONGO is "Y", the value of "ONGOING" may be used. When PRONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable PRENRF should be populated. When PRONGO is used in conjunction with another time point, the SDTM variables PRENRTPT and PRENTPT should be used. Note: PRENRTPT must refer to a time point anchor described in PRENTPT.	(NY)	N/A	Completed to indicate that the procedure has not stopped at the time point defined by the study. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the End Date was deliberately left blank. See Section 3.7, Mapping Relative Times from Collection to Submissions, and and SDTMIG v3.2 Section 4.1.4.7 for more information. for information about mapping relative times.
Interventions	PR	N/A	N/A	18	PRENDAT	Procedure End Date	The end date of the procedure, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the procedure (end) date?	(End) Date	Char	R/C	Record the end date of the procedure using this format (DD- MON-YYYY). If the procedure has not ended, leave this field blank and populate PRONGO as "Y".	PRENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTM variable PRENDTC in ISO 8601 format.	N/A	N/A	The assumption is that sponsors should either have an End Date or will indicate that the procedure was ongoing at the time of collection or at the end of the study. However, in cases where the End Date can be determined from dates collected elsewhere in the CRF it is not necessary to include an End Date in the CRF. For example, if the procedure is started and stopped within the same day, the End Date will be the same as the Start Date.
Interventions	PR	N/A	N/A	19	PRINDC	Procedure Indication	The condition, disease, symptom, or disorder that the procedure was used to address or investigate (e.g., why the therapy was taken or administered, why the procedure was performed).	For what indication was the [PRTRT] performed?	Indication	Char	O	Record the reason the procedure was performed based on clinical investigator's evaluation. If performed to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If performed to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for " and include a description of the condition(s).	PRINDC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This additional information is collected on the CRF when the sponsor wants to capture the reason(s) why a procedure was performed. This information can then be used as deemed appropriate for coding, analysis (e.g., in the classification of procedures), for reconciling the procedures performed on a subject with their provided medical history, and/or AEs/SAEs as part of the data clean-up and monitoring process.
Interventions	PR	N/A	N/A	20	PRAENO	Related Adverse Event ID	Identifier for the adverse event that is the indication for this procedure.	What was the identifier for the adverse event(s) for which the procedure was performed?	Related Adverse Event Identifier	Char	O	Record the identifier of the adverse event for which this procedure was performed.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Adverse Events domain.	N/A	N/A	The intent is to establish a link between the adverse event and the procedure performed for the adverse event. PRAENO can be used to identify a relationship between records in the PR dataset and records in the AE dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Interventions	PR	N/A	N/A	21	PRMHNO	Related Medical History Event ID	Identifier for the medical history event that is the indication for this procedure.	What was the identifier for the medical history event(s) for which the procedure was performed?	Related Medical History Event Identifier	Char	O	Record the identifier of the medical history event for which this procedure was performed.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Medical History domain.	N/A	N/A	The intent is to establish a link between the medical history condition and the procedure undergone for the medical history condition. PRMHNO can be used to identify a relationship between records in the PR dataset and records in the MH dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Interventions	PR	N/A	N/A	22	PRDSTXT	Procedure Dose Description	The dose/amount administered during the procedure.	What was the [dose/amount] of [PRTRT] (per administration/for the procedure)?	[Dose/Amount]	Char	O	Record the [dose/amount] of [PRTRT] per administered.	PRDOSE; PRDOSTXT	This does not map directly to an SDTMIG variable. Numeric values map to PRDOSE in SDTM. Non-numeric values (e.g., 200-400) map to PRDOSTXT in SDTM.	N/A	N/A	Defining this data collection field as a dose text field allows for flexibility in capturing dose entries as numbers, text or ranges. The data collected in this dose text-format field should be separated or mapped to either SDTMIG PRDOSE if numeric or PRDOSTXT if text.
Interventions	PR	N/A	N/A	23	PRDOSU	Procedure Dose Unit	The unit for intended dose/amount for PRDOSE, PRDOSTOT, or PRDOSTXT.	What was the unit?	Unit	Char	O	Record the unit for the amount of [PRTRT] performed or administered.	PRDOSU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	When sponsors collect data for amount of [PRTRT] performed or administered, Unit should be collected as well (if applicable).
Interventions	PR	N/A	N/A	24	PRDOSFRQ	Procedure Frequency per Interval	The number/amount of the procedure that was given/administered/taken during a specific interval.	What was the frequency of [PRTRT]?	Frequency	Char	O	Record how often the procedure was performed.	PRDOSFRQ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FREQ)	N/A	This may be collected if it cannot be determined from other sources or if there are multiple options. Usually expressed as the number of procedures given per a specific interval.
Interventions	PR	N/A	N/A	25	PRROUTE	Procedure Route of Administration	The route of administration of the procedure.	What was the route of administration of the procedure?	Route	Char	O	Provide the route of administration for the procedure.	PRROUTE	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ROUTE)	N/A	This additional information may be important to collect on the CRF when the sponsor would want to capture a procedure's route of administration for comparative analysis purposes.
Interventions	PR	N/A	N/A	26	PRLOC	Location of Procedure	A description of the anatomical location of an procedure, such as location of a biopsy.	What was the anatomical location where the procedure was performed?	Anatomical Location	Char	O	Record the body location where the procedure was performed.	PRLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected when the sponsor needs to identify the specific anatomical location (e.g., Liver for the Biopsy). LAT, DIR, PORTOT are used to further describe the anatomical location.
Interventions	PR	N/A	N/A	27	PRLAT	Procedure Laterality	Qualifier for anatomical location further detailing side of the body for the procedure administration.	What was the side of the anatomical location of the administration?	Side	Char	O	Record the side of the anatomical location where the procedure was administered.	PRLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	Further details the laterality of the location where the procedure was administered/taken. This may be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	PR	N/A	N/A	28	PRDIR	Procedure Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the procedure?	Directionality	Char	O	Record the direction of the anatomical location where the procedure was administered.	PRDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	PR	N/A	N/A	29	PRPORTOT	Procedure Portion or Totality	Qualifier for anatomical location further detailing the distribution (i.e., arrangement of, apportioning of).	What was the portion or totality of the anatomical location that was treated?	Portion or Totality	Char	O	Record the portion of the body location that was treated.	PRPORTOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Interventions	PR	N/A	N/A	30	PRFAST	Procedure Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	O	Record whether the subject was fasting prior to the procedure being performed.	PRFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	This information is collected when the procedure may be affected by whether the subject was fasting. This may not be relevant for all procedures.
Interventions	PR	N/A	N/A	31	PRDOSRGM	Procedure Intended Dose Regimen	The text description of the (intended) schedule or regimen for the procedure.	What was the intended procedure regimen?	Intended Procedure Regimen	Char	O	Record the intended regimen for the procedure to be performed.	PRDOSRGM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The regimen information may further clarify the dose administration and dose frequency (e.g., TWO WEEKS ON, TWO WEEKS OFF). This may be prespecified or collected. The sponsor may wish to create a codelist to collect this data consistently.
Interventions	PR	N/A	N/A	32	PRDOSADJ	Procedure Adjusted	An indication whether or not the procedure dose/amount was adjusted.	Was the procedure dose adjusted?	(Dose) Adjusted	Char	O	Record if the procedure was adjusted from planned.	N/A	When PRADJ is collected, does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED. When PRADJ is not collected, the sponsor may submit this variable as a SUPPQ.	(NY)	N/A	Typically, the intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the associate field on the CRF (PRADJ) was deliberately left blank. However, the sponsor may collect whether the procedure dose/amount was adjusted, without collecting the reason for the change.
Interventions	PR	N/A	N/A	33	PRADJ	Reason for Procedure Adjustment	Description or explanation of why a procedure dose/amount was adjusted.	What was the reason the procedure dose was adjusted?	Reason Adjusted	Char	O	Record why the procedure dose was adjusted from planned.	PRADJ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Captures reason [PRTRT] dose was changed or modified. The reason may be chosen from a sponsor- defined list (e.g., adverse event, insufficient response) or entered as free text.
Interventions	PR	N/A	N/A	34	PRTRTCMP	Completed Procedure	Indication whether the subject completed the intended regimen.	Did the subject complete the full course of the [PRTRT]?	Completed [PR Intervention Topic]	Char	O	Record if the subject completed the intended regimen.	SUPPPR.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM= "PRTRTCMP" and SUPPPR.QLABEL="Treatment Completed". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Depending on how the [PTTRT] dose details are collected via the CRF/eCRF, it may be possible to derive those data if the regimen data are collected.
Interventions	PR	N/A	N/A	35	PRITRPYN	Procedure Interrupted	An indication whether the procedure was interrupted.	Was the procedure interrupted?	Procedure Interrupted	Char	O	Record if the procedure was interrupted.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	Provides a definitive response regarding any procedure interruption. The intent/purpose of collecting this field is to help with data cleaning and monitoring when the duration of the interruption is collected. In some situations, if the actual duration of the interruption is not collected, or not derived, this information could be submitted in a SUPPPR dataset.
Interventions	PR	N/A	N/A	36	PRITRPRS	Reason Procedure Interrupted	An indication of why the intervention was interrupted.	Why was the procedure interrupted?	Reason Procedure Interrupted	Char	O	Record the reason the procedure was interrupted.	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRITRPRS" and SUPPPR.QLABEL ="Reason Intervention Interrupted". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	This CDASH field is use to collected the reason why an intervention was interrupted. The sponsor may define controlled terminology.
Interventions	PR	N/A	N/A	37	PRCINTD	Procedure Interruption Duration	The collected duration of the procedure interruption.	What was the duration of the procedure interruption?	(Interruption) Duration	Char	O	Record how long the procedure was interrupted before it resumed.	SUPPPR.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRITRPD" and SUPPPR.QLABEL= "Interruption Duration". Concatenate the collected procedure interruption duration and the duration unit components and create PRITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	This field is used to collect the duration of procedure interruption. In some situations, the duration of the interruption may not be collected but calculated from the procedure start and end times recorded elsewhere in the CRF.
Interventions	PR	N/A	N/A	38	PRCINTDU	Procedure Interruption Duration Units	The unit for the collected duration of the procedure interruption.	What was the interruption duration unit?	(Interruption Duration) Unit	Char	O	Record the unit for the duration of interruption of the procedure.	SUPPPR.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRITRPD" and SUPPPR.QLABEL= "Interruption Duration". Concatenate the collected procedure interruption duration and the duration unit components and create PRITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(UNIT)	N/A	The unit should be collected as a qualifier to the number for duration.
Interventions	PR	N/A	N/A	39	PRLLT	Procedure Lowest Level Term	MedDRA text description of the Lowest Level Term.	N/A	N/A	Char	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRLLT" and SUPPPR.QLABEL="Lower Level Term". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This variable could be used in the PR domain for coding. Another dictionary can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	40	PRLLTCD	Procedure Lowest Level Term Code	MedDRA Lowest Level Term code.	N/A	N/A	Num	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRLLTCD" and SUPPPR.QLABEL="Lower Level Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	41	PRPTCD	Procedure Preferred Term Code	MedDRA code for the Preferred Term.	N/A	N/A	Num	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR.QVAL dataset where SUPPPR.QNAM="PRPTCD" and SUPPPR.QLABEL= "Preferred Term Code Lower Level Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	42	PRHLT	Procedure High Level Term	MedDRA text description of High Level Term from the primary path.	N/A	N/A	Char	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRHLT" and SUPPPR.QLABEL="High Level Term". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	43	PRHLTCD	Procedure High Level Term Code	MedDRA High Level Term code from the primary path.	N/A	N/A	Num	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR.QVAL dataset where SUPPPR.QNAM="PRHLTCD" and SUPPPR.QLABEL="High Level Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	44	PRHLGT	Procedure High Level Group Term	MedDRA text description of the High Level Group Term from the primary path.	N/A	N/A	Char	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM="PRHLTGT" and SUPPPR.QLABEL="High Level Group Term". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	45	PRHLGTCD	Procedure High Level Group Term Code	MedDRA High Level Group Term code from the primary path.	N/A	N/A	Num	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM= "PRHLTGTCD" and SUPPPR.QLABEL="High Level Group Term Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	46	PRSOC	PR Primary System Organ Class	MedDRA Primary System Organ Class description associated with the intervention.	N/A	N/A	Char	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR.QVAL dataset where SUPPPR.QNAM="PRSOC" and SUPPPR.QLABEL="Primary System Organ Class". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.
Interventions	PR	N/A	N/A	47	PRSOCCD	PR Primary System Organ Class Code	MedDRA Primary System Organ Class code.	N/A	N/A	Num	O	N/A	SUPPPR.QVAL	This information could be submitted in a SUPPPR dataset as the value of SUPPPR.QVAL where SUPPPR.QNAM= "PRSOCCD" and SUPPPR.QLABEL="Primary System Organ Class Code". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. Sponsors should include an Origin column in the SUPPQ dataset to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete data management package. This variable could be used in the PR domain for MedDRA coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPPPR.QVAL dataset.

Assumptions for the CDASHIG PR - Domain

1. Information on procedures is generally collected either by recording free text or using a prespecified list of terms.

2. Because the solicitation of information on specific therapeutic and diagnostic procedures may affect the frequency at which they are reported, the fact that a specific procedure was solicited may be of interest to reviewers. PROCCUR is used to indicate whether a prespecified procedure occurred. A value of "Y" indicates that the procedure occurred; "N" indicates that it did not. If a procedure was not prespecified, the value of PROCCUR should not be collected.

Example CRFs for the CDASHIG PR - Procedures Domain

Example 1

Title: Prespecified Procedures



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
PULMANGI_PRCAT	1	What was the category of the procedure?	Procedure Category	Record the procedure category, if not preprinted on the CRF.	Text	PRCAT	PRCAT where PRTRT = "PULMONARY ANGIOGRAM"			OUTPATIENT PROCEDURES	Prompt
PULMANGI_PRTRT	2	What was the procedure name?	Procedure Name	Record only one procedure per line.	Text	PRTRT				PULMONARY ANGIOGRAM	Prompt
PULMANGI_PRPRESP	3	N/A	N/A	N/A	Text	PRPRESP	PRPRESP where PRTRT = "PULMONARY ANGIOGRAM"	(NY)	Yes	Yes		Radio	Y
PULMANGI_PROCCUR	4	Was a pulmonary angiogram performed?	Pulmonary Angiogram Performed	Indicate if a pulmonary angiogram was performed by checking Yes or No.	Text	PROCCUR	PROCCUR where PRTRT = "PULMONARY ANGIOGRAM"	(NY)	Yes; No			Radio
PULMANGI_PRSTDAT	5	What was the procedure Start date?	Start Date	Record the date the procedure was started or performed using this format (DD-MON-YYYY).	Date	PRSTDTC	PRSTDTC where PRTRT = "PULMONARY ANGIOGRAM"				Prompt
PULMANGI_PRINDC	6	For what indication was the pulmonary angiogram performed?	Indication	Record the reason the procedure was performed based on clinical investigator's evaluation. If performed to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If performed to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for" and include a description of the condition(s).	Text	PRINDC	PRINDC where PRTRT = "PULMONARY ANGIOGRAM"
PULMANGI_PRAENO	7	What was the identifier for the adverse event(s) for which the procedure was performed?	Adverse Event Identifier	Record the identifier of the adverse event for which this procedure was performed.	Text	N/A	Associate with related AE record in RELREC where PRTRT = "PULMONARY ANGIOGRAM"				Prompt
CARDCATH_PRCAT	8	What was the category of the procedure?	Procedure Category	Record the procedure category, if not preprinted on the CRF.	Text	PRCAT	PRCAT where PRTRT = "CARDIAC CATHETERIZATION"			INPATIENT PROCEDURES	Prompt
CARDCATH_PRTRT	9	What was the procedure name?	Procedure Name	Record only one procedure per line.	Text	PRTRT				CARDIAC CATHETERIZATION	Prompt
CARDCATH_PRPRESP	10	N/A	N/A	N/A	Text	PRPRESP	PRPRESP where PRTRT = "CARDIAC CATHETERIZATION"	(NY)	Yes	Yes		Radio	Y
CARDCATH_PROCCUR	11	Was cardiac catheterization performed?	Cardiac Catheterization Performed	Indicate if cardiac catheterization was performed by checking Yes or No.	Text	PROCCUR	PROCCUR where PRTRT = "CARDIAC CATHETERIZATION"	(NY)	Yes; No			Radio
CARDCATH_PRSTDAT	12	What was the procedure start date?	Start Date	Record the date the procedure was started or performed using this format (DD-MON-YYYY).	Date	PRSTDTC	PRSTDTC where PRTRT = "CARDIAC CATHETERIZATION"
CARDCATH_PRITRPYN	13	Was the procedure interrupted?	Procedure Interrupted	Record if the procedure was interrupted.	Text	N/A		(NY)	Yes; No			Radio
CARDCATH_PRCINTD	14	What was the duration of the procedure interruption?	Collected Interruption Duration	Record how long the procedure was interrupted before it resumed.	Text	SUPPPR.QVAL	SUPPPR.QVAL where SUPPPR.QNAM="PRITRPD" and SUPPPR.QLABEL= "Interruption Duration" and PRTRT = "CARDIAC CATHETERIZATION"
CARDCATH_PRCINTDU	15	What was the interruption duration unit?	Interruption Duration Unit	Record the unit for the duration of interruption of the procedure.	Text	N/A	SUPPPR.QVAL where SUPPPR.QNAM="PRITRPD" and SUPPPR.QLABEL= "Interruption Duration" and PRTRT = "CARDIAC CATHETERIZATION"	(UNIT)	HOURS; min		Prompt	Radio
CARDCATH_PRINDC	16	For what indication, was the cardiac catheterization performed?	Indication	Record the reason the procedure was performed based on clinical investigator's evaluation. If performed to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If performed to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for" and include a description of the condition(s).	Text	PRINDC	PRINDC where PRTRT = "CARDIAC CATHETERIZATION"
CARDCATH_PRAENO	17	What was the identifier for the adverse event(s) for which the procedure was performed?	Adverse Event Identifier	Record the identifier of the adverse event for which this procedure was performed.	Text	N/A	Associate with related AE record in RELREC where PRTRT = "CARDIAC CATHETERIZATION"				Prompt

Example 2

Title: Spontaneously Reported Procedures



CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
PRYN	1	Were any surgical, therapeutic or diagnostic procedures performed?	Any Procedures	Indicate if the subject had any surgical, therapeutic or diagnostic procedures. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	Yes; No			Radio
PRTRT	2	What was the procedure name?	Procedure Name	Record only one procedure per line.	Text	PRTRT					Prompt
PRINDC	3	For what indication, was the procedure performed?	Indication	Record the reason the procedure was performed based on clinical investigator's evaluation. If performed to treat a condition, and a diagnosis was made, the indication should be the diagnosis. If performed to treat a condition, and no diagnosis was made, the indication should be the signs and symptoms. If taken as prophylaxis, report as "Prophylaxis for" and include a description of the condition(s).	Text	PRINDC					Prompt
PRSTDAT	4	What was the procedure start date?	Start Date	Record the date the procedure was started or performed using this format (DD-MON- YYYY). Procedures performed during the study are expected to have a complete start date. Prior procedures that are exclusionary should have both a start and end date.	Date	PRSTDTC					Prompt
PRSTTIM	5	What was the procedure start time?	Start Time	Record the start time (as complete as possible) when the procedure started.	Time	PRSTDTC					Prompt
PRENDAT	6	What was the procedure end date?	End Date	Record the end date of the procedure using this format (DD-MON-YYYY). If the procedure has not ended, leave this field blank.	Date	PRENDTC					Prompt
PRENTIM	7	What was the procedure end time?	End Time	Record the start time (as complete as possible) when the procedure ended.	Time	PRENDTC					Prompt

8.1.5 SU - Substance Use

Description/Overview for the CDASHIG SU - Substance Use Domain

This domain is used to collect information on substance use when this information is relevant to the assessment of the efficacy and safety of therapies. The amount of information collected for this domain depends upon the sponsor's protocol. In many protocols, only information on the use of the substance is required. In this case, many of the variables in this domain (e.g., duration, amount) would not be collected.

CDASH recommends the use of the more descriptive CDASHIG variable SUNCF with responses of “Never", "Current", or "Former” for each substance use type, rather than a simple "Yes/No" response. Based on the wide variability of protocol definitions of use, the specific definitions and timeframes for the SUNCF responses would be sponsor/protocol-defined. By using the SUNCF response 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 SU domain. More detailed information about duration, amount, and start and end dates are optionally captured.

Specification for the CDASHIG SU - Substance Use Domain

Substance Use Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Interventions	SU	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Interventions	SU	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Interventions	SU	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Interventions	SU	N/A	N/A	4	SUTRT	Reported Name of Substance	The type of substance (e.g., TOBACCO, ALCOHOL, CAFFEINE or CIGARETTES, CIGARS, COFFEE).	What [is/was] the [name/type] of (the) substance used?	[Type of Substance]	Char	HR	N/A	SUTRT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsors may require different types of substance use data (e.g., illicit drug use, cigarettes); the value for category may be preprinted 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.
Interventions	SU	N/A	N/A	5	SUCAT	Category for Substance Use	A grouping of topic-variable values based on user-defined characteristics.	What is/was the category of the substance (used)?	[Substance (Used) Category]; NULL	Char	R/C	Record the Substance Used category, if not preprinted on the CRF.	SUCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology (e.g., TOBACCO, ALCOHOL, CAFFEINE). Sponsors may require different types of substance use data (e.g., illicit drug use, cigarettes); the value for category may be preprinted on the CRF. If a more detailed type of substance appears on the CRF (e.g., CIGARETTES, CIGARS, rather than TOBACCO), SUCAT is TOBACCO and SUTRT is CIGARETTES. If the sponsor does not specify a type of tobacco on the CRF, SUTRT is TOBACCO. If SUCAT is not collected (e.g. it is self- evident from the protocol design), it could be populated during the SDTM-based dataset creation process.
Interventions	SU	N/A	N/A	6	SUSCAT	Subcategory for Substance Use	A sub-division of the SUCAT values based on user-defined characteristics.	What was the subcategory of the substance (used)?	[Substance (Used) Subcategory]; NULL	Char	O	Record the Substance Use subcategory, if not preprinted on the CRF.	SUSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. The value for subcategory may be preprinted on the CRF or hidden. SUSCAT can only be used if there is a SUCAT and it must be a subcategorization of SUCAT.
Interventions	SU	N/A	N/A	7	SUPRESP	SU prespecified	An indication that a specific intervention or a group of interventions is prespecified on a CRF.	N/A	N/A	Char	O	N/A	SUPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	For prespecified interventions, a hidden field on a CRF defaulted to Y, or added during the SDTM dataset creation. If a study collects both prespecified interventions as well as free- text interventions, the value of SUPRESP should be Y for all prespecified interventions and null for interventions reported as free-text.
Interventions	SU	N/A	N/A	8	SUYN	Any Substance Used	An indication whether or not any data was collected for the intervention topic.	Were any [sponsor- phrase/substance name/recreational drugs] used?	Any [Substance Name (Used)]	Char	O	Indicate if the subject had used any (sponsor-defined phrase/recreational drugs/alcohol/substance name).	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	General prompt question to aid in monitoring and data cleaning. This provides verification that all other fields on the CRF were deliberately left blank. This is a field that can be used on any interventions CRF to indicate whether or not there is data to record.
Interventions	SU	N/A	N/A	9	SUNCF	Never Current Former Usage	Indication the prespecified substance was used.	Has the subject ever [used/consumed] [SUTRT/SUCAT]?	([Substance]) Usage	Char	R/C	Check the appropriate box to indicate if the subject has ever used/consumed tobacco/alcohol/caffeine, currently consumes tobacco/alcohol/caffeine, or formerly used/consumed tobacco/alcohol/caffeine.	SUOCCUR; SUSTRTPT; SUSTRF; SUENRTPT; SUENRF; SUPPSU.QVAL	This does not map directly to an SDTMIG variable. May be used to populate SUOCCUR and relative timing variables.	(NCF)	(SUNCF)	The 3 options (NEVER, CURRENT, FORMER) are sponsor-defined in relation to the protocol. If the sponsor has specific definitions, these definitions are detailed in the instructions to the site. As this type of response does not correspond exactly to an SDTM variable, CDASH recommends using the CDASHIG variable SUNCF. Sponsors must decide how to populate the appropriate relative timing variables when the SDTM-based datasets are created. For example, If SUNCF ="Never", the value of SUOCCUR will be "N" and all relative timing variables will be null. If the sponsor chooses to populate the relative start references (SUSTRTPT, SUSTRF) the value will be "BEFORE" when SUNCF= "CURRENT" and "FORMER". If the sponsor also chooses to use relative end references (SUENRF, SUENRTPT) , the SUENRTPT value will be "ONGOING" when SUNCF="CURREN" while the value of SUENRF will be "DURING/AFTER". Note: When using SUSTRTPT and/or SUENRTPT, these must refer to a "time point anchor" such as SCREENING in SUSTTPT/SUENTPT.
Interventions	SU	N/A	N/A	10	SUSPID	Substance Use Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	SUSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Since SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Interventions	SU	N/A	N/A	11	SUREASND	Reason Substance Use Not Collected	An explanation of why the data are not available.	What was the reason the data was not collected?	Reason Not Collected	Char	O	Provide the reason why the substance used data were not collected.	SUREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor defined list (e.g., subject refused) or entered as free text. When PRREASND is used, the SDTMIG variable PRSTAT should also be populated in the SDTM-based dataset.
Interventions	SU	N/A	N/A	12	SUDSTXT	Substance Dose Description	The amount of substance used (e.g., 1-2 packs, 8 ounces).	What is/was the amount of [SUTRT] used/consumed?	Amount	Char	O	Check the appropriate box to indicate the amount of tobacco/alcohol/caffeine the subject consumes on a regular basis.	SUDOSE; SUDOSU; SUDOSTXT	This does not map directly to an SDTMIG variable. Numeric values map to SUDOSE in SDTM. Non- numeric values (e.g., 200-400) map to SUDOSTXT in SDTM.	N/A	N/A	Where possible, the options for dose/amount are preprinted on the CRF. In the example given in the Definition, (packs) and (ounces) are included as a point of reference. They would, of course, be submitted as SUDOSU. Care should be taken to map each record to the appropriate SDTM variable SUDOSTXT (text results that cannot be represented in a numeric field) and SUDOSE (numeric results).
Interventions	SU	N/A	N/A	13	SUDOSFRQ	Substance Use Frequency per Interval	The number/amount of the of substance consumed per a specific interval.	What [is/was] the frequency of [SUTRT] [use/consumption]?	Frequency	Char	O	Record how often the subject regularly [uses / consumes] (the) [substance].	SUDOSFRQ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(FREQ)	N/A	When possible, the options for dose/amount frequency are preprinted on the CRF. (e.g., PER DAY, PER WEEK, OCCASIONAL).
Interventions	SU	N/A	N/A	14	SUSTDAT	Substance Use Start Date	The date substance use started, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the start date of [SUTRT/SUCAT] use/consumption?	Start Date	Char	O	Record the start date of the substance use using this format (DD-MON-YYYY).	SUSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable SUSTDTC in ISO 8601 format.	N/A	N/A	The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).
Interventions	SU	N/A	N/A	15	SUENDAT	Substance Use End Date	The date substance use ended, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the end date of [SUTRT/SUCAT] use/consumption?	End Date	Char	O	Record the end date of the substance use using this format (DD-MON-YYYY).	SUENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable SUENDTC in ISO 8601 format.	N/A	N/A	The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).
Interventions	SU	N/A	N/A	16	SUCDUR	Substance Use Collected Duration	Collected duration of the substance use.	What was the duration of [SUTRT/SUCAT] use/consumption?	Duration	Char	O	Provide the duration of the substance use (e.g., Record how long the subject has smoked).	SUDUR	This does not map directly to an SDTMIG variable. For the SDTM- based dataset, concatenating the CDASH collected duration and collected duration unit and populate the SDTMIG variable SUDUR in ISO 8601 format. Example: P1DT2H (for 1 day, 2 hours).	N/A	N/A	This is only collected on the CRF if this level of detail is needed and if SUSTDAT and SUENDAT are not collected on the CRF.
Interventions	SU	N/A	N/A	17	SUCDURU	Substance Use Collected Duration Unit	Unit of the collected duration of the substance use. Used only if duration was collected on the CRF.	What was the unit of duration of [SUTRT/SUCAT] use/consumption?	(Duration) Unit	Char	O	Select the appropriate duration unit of the substance use.	SUDUR	This does not map directly to an SDTMIG variable. For the SDTM- based dataset, concatenating the CDASH collected duration and collected duration unit and populate the SDTMIG variable SUDUR in ISO 8601 format. Example: P1DT2H (for 1 day, 2 hours).	(UNIT)	N/A	The sponsor-defined options should be preprinted on the CRF to avoid making this a free text field. This will allow the response to be translated into ISO 8601 format.
Interventions	SU	N/A	N/A	18	SUMODIFY	Modified Substance Name	If the value for SUTERM is modified for coding purposes, then the modified text is placed here.	N/A	N/A	Char	O	N/A	SUMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that would appear on the CRF. If the sponsor chooses to code the substance use, the sponsor will populate this through the coding process.
Interventions	SU	N/A	N/A	19	SUDECOD	Standardized Substance Name	The dictionary or sponsor-defined standardized text description of SUTRT, or the modified topic variable (SUMODIFY), if applicable.	N/A	N/A	Char	O	N/A	SUDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata to indicate that the data was "ASSIGNED".	N/A	N/A	This is typically not a data collection field that will appear on the CRF. If the sponsor chooses to code the substance use, the sponsor will populate this through the coding process. Equivalent to the generic drug name in WHODrug, or a term in SNOMED, ICD9, or other published or sponsor-defined dictionaries. If SUPRESP is used, and the information about a specific standardized substance name is being solicited, the data from SUTRT may map directly to the SDTMIG SUDECOD variable.

Assumptions for the CDASHIG SU - Substance Use Domain

1. Categories SUCAT and SUSCAT

a. Sponsors may require different types of substance use data (e.g., illicit drug use, cigarettes) to be collected; the value for category may be preprinted on the CRF.

b. SUCAT and SUSCAT should not be redundant with SUTRT. For example, if a more detailed type of substance usage is collected on the CRF (e.g., “CIGARETTES”, “CIGARS”), SUCAT should be “TOBACCO” and SUTRT could be “CIGARETTES”, "CIGARS". If the sponsor does not solicit responses about specific types of substance used, on the CRF (e.g., “CIGAR”, “CIGARETTE”), the value of SUTRT is the more general description of the substance (e.g., “TOBACCO") and SUCAT is generally null. This practice avoids assigning the same value to both SUTRT and SUCAT. However, for consistency across studies, the sponsor may elect to repeat the values of SUTRT in SUCAT.

2. The SDTMIG variable SUPRESP should be prepopulated to the value of "Y" when information about the use of a specific substance is solicited on the CRF.

3. Relative Timing Variables

a. Relative timing variables are used to represent collected data in the SDTM tabulations in those cases where a Start Date or an End Date has not been collected, but some indication of when/if the intervention or event started or ended has been collected. In the CDASHIG SU domain, if the CDASHIG variable SUNCF is used (with the possible responses of "Never", "Current", or "Former"), the collected values may be used to derive a value into an SDTMIG relative timing variable to represent when the subject started or stopped using the substance relative to either a time point or to a period of time in the study. For example, if the value collected in SUNCF is "Current", the value of "ONGOING" may be represented in the SDTMIG Variable SUENRTPT to indicate that the subject was still using cigarettes as of the time point described in SUENTPT. It is recommended that the sponsor collect either a date or a description of a time point that will be used in conjunction with relative timing variables. See SDTMIG v3.2 Section 4.1.4.7 for more information about relative timing variables.

b. If the actual, complete start date or end date of the substance use has been collected, there is no need to use relative timing variables.

4. Start and End Dates

a. Start and end dates can be collected if this level of detail is required by the protocol. Partial dates may be collected when the subject does not remember the complete date of when substance use started or ended. The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).

b. Sponsors may elect to capture only a start date, or only an end date, and use the associated SDTMIG relative timing variables to represent information about the date not collected.

c. If the sponsor is only interested in collecting whether or not the subject is consuming a particular substance, start and end dates are optional and may be omitted, and SUNCF may be collected as described above.

5. Coding

a. Coding may be performed if deemed necessary by the sponsor. The SDTMIG variable SUDECOD is a permissible variable in the SDTMIG SU domain.

b. Coding variables are not usually displayed on CRFs. If a sponsor chooses to display coding on the form, CDASH does not advocate using that as a field for entry by site personnel.

Example CRFs for the CDASHIG SU - Substance Use Domain

Example 1

Title: Recreational Drug Substance Use

Example CRF Completion Instructions Record the substance(s) used by the subject.



CRF Metatadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
SUCAT	1	What is the category of the substance used?	Substance Use Category	Record the Substance Used category, if not pre-printed on the CRF.	Text	SUCAT				Recreational Drugs
SUYN	2	Were any recreational drugs used?	Any Recreational Drugs Used	Indicate if the subject had used any recreational drugs.	Text	N/A		(NY)	Yes; No
SUTRT	3	What was the substance used?	Type of Recreational Drug Used	Record the name of the recreational drug used.	Text	SUTRT
SUNCF	4	Does subject use recreational drugs?	Usage	Check the appropriate box to indicate if the subject currently or formerly used recreational drugs.	Text	SUOCCUR; SUSTRTPT; SUSTRF; SUENRTPT; SUENRF	SUOCCUR = "Y" WHEN SUNCF = "CURRENT". SUOCCUR = "Y" WHEN SUNCF = "FORMER".	(NCF)	Current; Former		Prompt
SUDSTXT	5	What was the amount of substance used?	Amount	Indicate the amount of recreational drugs the subject consumes on a regular basis.	Text	SUDOSE; SUDOSTXT
SUDOSFRQ	6	What was the frequency of recreational drug use?	Frequency	Record how often the subject regularly uses recreational drugs.	Text	SUDOSFRQ		(FREQ)	QD; EVERY WEEK; QM; PA		Prompt
SUCDUR	7	What was the duration of recreational drug use consumption?	Duration	Provide the duration of the substance use (e.g., how long the subject has smoked).	Text	SUDUR					Prompt
SUCDURU	8	What was the unit of duration of recreational drug use?	Unit	Select the appropriate duration unit of the substance use.	Text	SUDUR		(UNIT)	DAYS; MONTHS; YEARS		Prompt

Example 2

Title: Alcohol Substance Use

Example CRF Completion Instructions The amount of each type of alcohol consumed should be an integer. The following description should be used in determining the amount consumed: 1 Beer Unit = 12 oz or 360 ml 1 Wine Unit = 5 oz or 150 ml 1 Spirits Unit = 1.5 oz or 45 ml



CRF Metatadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
SUCAT	1	What is the category of the substance used?	Substance Use Category	The amount of each type of alcohol consumed should be an integer. The following description should be used in determining the amount consumed: 1 Beer Unit = 12 oz or 360 ml. 1 Wine Unit = 5 oz or 150 ml. 1 Spirits Unit = 1.5 oz or 45 ml.	Text	SUCAT				ALCOHOL	Prompt		Yes
ALCOHOL_SUNCF	2	Has the subject ever consumed alcohol?	Usage	Check the appropriate box to indicate if the subject currently or formerly consumed alcohol.	Text	SUOCCUR	SUOCCUR = "N" WHERE SUNCF = "NEVER". SUOCCUR = "Y" WHERE SUNCF = "CURRENT". SUOCCUR = "Y" WHERE SUNCF = "FORMER".	(NCF)	Never; Current; Former
ALCOHOL_SUSTDAT	3	What was the start date of alcohol consumption?	Start Date	Record the start date of the alcohol consumption using this format (DD-MON-YYYY).	Date	SUSTDTC					Prompt
ALCOHOL_SUENDAT	4	What was the end date of alcohol consumption?	End Date	Record the end date of the alcohol consumption using this format (DD-MON-YYYY).	Date	SUENDTC					Prompt
BEER_SUDOSE	5	What was the amount of beer consumed?	Amount	Indicate the amount of beer the subject consumes on a regular basis. 1 Beer Unit = 12 oz or 360 ml.	Text	SUDOSE; SUDOSTXT	SUDOSE/SUDOSTXT WHERE SUTRT = "BEER"
BEER_SUDOSU	6	What was the unit for the amount of beer consumption?	Unit	N/A	Text	SUDOSU	SUDOSU WHERE SUTRT = "BEER"	(UNIT)		UNIT			Yes
BEER_SUDOSFRQ	7	What was the frequency of beer consumption?	Frequency	Record how often the subject regularly consumes beer.	Text	SUDOSFRQ	SUDOSFRQ WHERE SUTRT = "BEER"	(FREQ)	QD; EVERY WEEK; QM; PA			Prompt
WINE_SUDOSE	8	What was the amount of wine consumed?	Amount	Indicate the amount of wine the subject consumes on a regular basis. 1 Wine Unit = 5 oz or 150 ml.	Text	SUDOSE; SUDOSTXT	SUDOSE/SUDOSTXT WHERE SUTRT = "WINE"
WINE_SUDOSU	9	What was the unit for the amount of wine consumption?	Unit	N/A	Text	SUDOSU	SUDOSU WHERE SUTRT = "WINE"	(UNIT)		UNIT			Yes
WINE_SUDOSFRQ	10	What was the frequency of wine consumption?	Frequency	Record how often the subject regularly consumes wine.	Text	SUDOSFRQ	SUDOSFRQ WHERE SUTRT = "WINE"	(FREQ)	QD; EVERY WEEK; QM; PA			Prompt
SPIRITS_SUDOSE	11	What was the amount of spirits consumed?	Amount	Indicate the amount of spirits the subject consumes on a regular basis. 1 Spirits Unit = 1.5 oz or 45 ml.	Text	SUDOSE; SUDOSTXT	SUDOSE/SUDOSTXT WHERE SUTRT = "SPIRITS"
SPIRITS_SUDOSU	12	What was the unit for the amount of spirits consumption?	Unit	N/A	Text	SUDOSU	SUDOSU WHERE SUTRT = "SPIRITS"	(UNIT)		UNIT			Yes
SPIRITS_SUDOSFRQ	13	What was the frequency of spirits consumption?	Frequency	Record how often the subject regularly consumes spirits.	Text	SUDOSFRQ	SUDOSFRQ WHERE SUTRT = "SPIRITS"	(FREQ)	QD; EVERY WEEK; QM; PA			Prompt

8.2 Events Class Domains

The Events class includes CDASH domains that define standards for the collection of occurrences or incidents occurring during a trial (e.g., adverse events, disposition) or prior to a trial (e.g., medical history).

8.2.1 General CDASH Assumptions for Events Domains

1. CDASH --YN variables with the question text "Were there any <'events'>?" (e.g., “Were there any adverse events?”, “Were there any healthcare encounters?”) are intended to assist in the cleaning of data and in confirming there are no missing values. These questions can be added to any CRF in order to capture this information.

2. CDASH --CAT and/or -SCAT are generally not entered on the CRF by sites. Implementers may prepopulate and display these category values to help sites understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories are typically self-evident from the protocol design, and could be populated during SDTM dataset creation.

3. Date and Time Variables

a. CDASH date variables (e.g., --DAT, --STDAT,--ENDAT) are concatenated with the CDASH time variables (e.g., --TIM, --STTIM, --ENTIM, if time is collected) into the appropriate SDTM --DTC variables (e.g., --DTC, – STDTC, --ENDTC) using the ISO 8601 format.

b. Collecting the time of an event is only appropriate if it can be easily obtained and if there is a scientific reason, such as the need to know the order of events (e.g., the adverse event started after dosing). An example of this would be a study where the subject is confined to a phase 1 unit and under the direct care of the unit staff at the time that the event started or using time to tie together dosing and pharmacokinetic (PK) sample collection.

4. CDASH --COCCUR variable is used only if a specific event is solicited (preprinted) on the CRF and the CRF elicits a response from the CDASH Codelist --COCCUR. As of the time of publication, CDASH Controlled Terminology includes values that indicate that the data was not collected (Not Done). Whereas the SDTM Controlled Terminology for --OCCUR only includes "N"," Y", and "UNKNOWN" responses, if the CDASH variable --OCCUR is used, the CRF would require a second question to indicate that the data was not collected. In STDM, the CDASH --COCCUR variable will be mapped to the SDTM variable --OCCUR and --STAT variables. Responses of "Y" or "N" map directly to SDTM -- OCCUR. Responses of "NOT DONE" or "NOT COLLECTED" map to SDTM --STAT as "NOT DONE". - -COCCUR is not used if the events are not prespecified.

5. The CDASH variable --REASND is used in conjunction with SDTM variable --STAT. The value "NOT DONE" in --STAT indicates that the subject was not questioned about the event or that data was not collected; it does not mean that the subject had no events.

6. The CDASH --SPID variable may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system.

7. Coding

a. The CDASH variables used for coding are not data collection fields that will appear on the CRF itself. Sponsors will populate these through the coding process.

b. When free-text event terms are entered, the location may be included in --TERM to facilitate coding and further clarify the event. This location information does not need to be removed from the verbatim term when the SDTM submission datasets are created.

c. The CDASH variables --LLT, --LLTCD, --PTCD, --HLT, --HLTCD, --HLGT, --HLGTCD, --SOC, and --SOCCD are only applicable to events coded in MedDRA.

8. Location (--LOC, --LAT, --DIR, --PORTOT)

a. Location is collected when the sponsor needs to identify the specific anatomical location of the event.

b. Implementers may collect the location information using a subset list of controlled terminology on the CRF. Location variables can be pre-populated as needed. There is currently some overlap across the LOC, LAT, and DIR variables for controlled terminology. While the overlap exists, ensure that this overlap for these variables is not part of database design.

8.2.2 AE - Adverse Events

Description/Overview for the CDASHIG AE - Adverse Events Domain

The Adverse Events (AE) domain includes clinical data describing "any untoward medical occurrence in a patient or clinical investigation subject administered a pharmaceutical product and which does not necessarily have to have a causal relationship with this treatment" (ICH E2A). In consultation with regulatory authorities, sponsors may extend or limit the scope of adverse event collection (e.g., collecting pre-treatment events related to trial conduct, not collecting events that are assessed as efficacy endpoints). The events included in the AE domain should be consistent with the protocol requirements. Adverse event terms may be captured either as free text or via a prespecified list of terms. The structure of the SDTMIG AE domain is 1 record per adverse event per subject. It is the sponsor's responsibility to define an event. This definition may vary based on the sponsor's requirements for characterizing and reporting product safety and is usually described in the protocol.

As with all the data collection variables recommended in CDASH, 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, or operating procedures). Sponsors should define the appropriate collection period for adverse events.

Specification for the CDASHIG AE - Adverse Events Domain

Adverse Events Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	AE	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Events	AE	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted for the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	AE	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	AE	N/A	N/A	4	AEYN	Any Adverse Event	An indication whether or not any AEs were experienced during the study.	Were any adverse events experienced?	Any Adverse Events	Char	O	Indicate if the subject experienced any adverse events. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Events	AE	N/A	N/A	5	AECAT	Category for Adverse Event	A grouping of topic- variable values based on user-defined characteristics.	What is the category of the adverse event?	[Adverse Event Category]; NULL	Char	O	Record the adverse event category, if not preprinted on the CRF.	AECAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Events	AE	N/A	N/A	6	AESCAT	Subcategory for Adverse Event	A sub-division of the AECAT values based on user-defined characteristics.	What is the subcategory of the adverse event?	[Adverse Event Subcategory]; NULL	Char	O	Record the adverse event subcategory, if not preprinted on the CRF.	AESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. AESCAT can only be used if there is an AECAT and it must be a subcategorization of AECAT.
Events	AE	N/A	N/A	7	AESPID	AE Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	Sponsor defined	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	AESPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medications, procedures and/or medical history records with AEs. If CMAENO or PRAENO is used, this is the identifier to which CMAENO or PRAENO refers. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Events	AE	N/A	N/A	8	AETERM	Reported Term for the Adverse Event	The reported or prespecified name of the adverse event.	What is the adverse event term?	Adverse Event	Char	HR	Record only 1 diagnosis, sign or symptom per line (e.g., nausea and vomiting should not be recorded in the same entry, but as 2 separate entries). Using accepted medical terminology, enter the diagnosis (if known); otherwise enter a sign or symptom.	AETERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Can be represented either as an open- entry field to capture verbatim terms reported by subjects or could be preprinted in the situation where solicited AEs of interest are captured. In most cases, the verbatim term (i.e., investigator-reported term) will be coded to a standard medical dictionary such as MedDRA or WHO ART, after the data have been collected on the CRF.
Events	AE	N/A	N/A	9	AEOCCUR	Adverse Event Occurrence	An indication whether a prespecified adverse event or a group of adverse events occurred when information about the occurrence of a specific event is solicited.	Did the subject have [prespecified adverse event/group of adverse events]?	[Specific Adverse Event]	Char	O	Indicate if [specific adverse event] has occurred/is occurring by checking Yes or No.	FAORRES	This does not map directly to an SDTMIG variable. Because the SDTM AE domain is intended to hold only adverse events that actually happen, all values collected in AEOCCUR for prespecified AEs should be submitted in a Findings About Adverse Events data set (FAAE) where FAORRES=the value of AEOCCUR where FATESTCD="OCCUR". In addition, where AEOCCUR="Y", there should be a corresponding record in the AE domain.	(NY)	N/A	The CDASH variable AEOCCUR is used to indicate the occurrence of prespecified adverse events (e.g., "Did the subject have high blood pressure?"). AEOCCUR should not be used for spontaneously reported adverse events. The site should be able to indicate that the response was not asked or answered.
Events	AE	N/A	N/A	10	AEPRESP	prespecified Adverse Event	An indication that a specific event, or group of events, are prespecified on a CRF.	N/A	N/A	Char	O	N/A	AEPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	A hidden field on a CRF defaulted to "Y", or added during SDTM-based dataset creation, when the AE is prespecified. Null for spontaneously reported events. If a study collects both prespecified adverse events as well as free-text events, the value of AEPRESP should be "Y" for all prespecified events and null for events reported as free- text. AEPRESP is a permissible field in SDTM and may be omitted from the SDTM-based dataset if all events were collected as free text.
Events	AE	N/A	N/A	11	AESTDAT	Adverse Event Start Date	The start date of the adverse event, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What is the adverse event start date?	Start Date	Char	HR	Record the start date of the AE using this format (DD-MON- YYYY).	AESTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable AESTDTC in ISO 8601 format.	N/A	N/A	N/A
Events	AE	N/A	N/A	12	AESTTIM	Start Time of Adverse Event	The start time of the adverse event, represented in an unambiguous time format (e.g., hh:mm:ss)	What is the adverse event start time?	Start Time	Char	R/C	Record the start time (as complete as possible) of the AE.	AESTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable AESTDTC in ISO 8601 format.	N/A	N/A	Collecting the time an AE started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event started and the study design is such that it is important to know the AE start time with respect to dosing.
Events	AE	N/A	N/A	13	AELOC	AE Location of Event	A description of the anatomical location relevant for the adverse event.	What is the anatomical location of the adverse event?	Anatomical Location	Char	O	Indicate the anatomical location of the adverse event.	AELOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, PORTOT are used to further describe the anatomical location.
Events	AE	N/A	N/A	14	AELAT	Adverse Event Laterality	Qualifier for anatomical location further detailing the side of the body relevant for the event.	What is the side of the anatomical location of the adverse event?	Side	Char	O	Record the side of the anatomical location of the adverse event.	AELAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	AE	N/A	N/A	15	AEDIR	Adverse Event Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What is the directionality of the anatomical location of the adverse event?	Directionality	Char	O	Record the directionality of the anatomical location of the adverse events.	AEDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	AE	N/A	N/A	16	AEPORTOT	AE Location Portion or Totality	Qualifier for anatomical location further detailing the distribution (i.e., arrangement of, apportioning of).	What is the portion or totality of the anatomical location of the adverse event?	Portion or Totality	Char	O	Indicate the portion or totality anatomical location of the adverse event.	AEPORTOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	AE	N/A	N/A	17	AEONGO	Ongoing Adverse Event	Indication that an adverse event is ongoing when no End Date is provided.	Is the adverse event ongoing (as of [the study- specific time point or period])?	Ongoing (as of [the study-specific time point or period])	Char	O	Indicate if the adverse event has not resolved at the time of data collection; leave the End Date blank.	AEENRTPT; AEENRF	This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as AEENRF or AEENRTPT. When populating AEENRF, if the value of AEONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating AEENRTPT, if the value of AEONGO is "Y", the value of "ONGOING" may be used. When AEONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable AEENRF should be populated. When	AEONGO is compared to another time point, the SDTMIG variables AEENRTPT and AEENTPT should be used. Note: AEENRTPT must refer to a time point anchor described in AEENTPT. (NY)	N/A	Completed to indicate that the AE has not resolved at the time of data collection, when no End Date is collected. In some cases the ongoing status may be determined from AE Outcome. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the End Date was deliberately left blank. Often used as a tick/checkbox.
Events	AE	N/A	N/A	18	AEENDAT	Adverse Event End Date	The date when the adverse event resolved/ended, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the adverse event end date?	End Date	Char	R/C	Record the date that the AE resolved using this format (DD-MON-YYYY). If the AE is ongoing, leave the field blank.	AEENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable AEENDTC in ISO 8601 format.	N/A	N/A	The definition of resolved is sponsor- specific. The preferred method is to collect a complete end date (if applicable). Partial dates (e.g., providing year only, month and year only) may be acceptable.
Events	AE	N/A	N/A	19	AEENTIM	End Time of Adverse Event	The time when the adverse event ended/resolved, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the adverse event end time?	End Time	Char	R/C	Record the time (as complete as possible) that the AE resolved.	AEENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable AEENDTC in ISO 8601 format.	N/A	N/A	Collecting the time an AE resolved is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event resolved and the study design is such that it is important to know the AE end time with respect to dosing.
Events	AE	N/A	N/A	20	AESEV	AE Severity/Intensity	The severity or intensity of the event.	What is the severity of the adverse event?	Severity	Char	R/C	The reporting physician/healthcare professional will assess the severity of the event using the sponsor-defined categories. This assessment is subjective and the reporting physician/ healthcare professional should use medical judgment to compare the reported AE to similar type events observed in clinical practice. Severity is not equivalent to seriousness.	AESEV	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(AESEV)	N/A	Either AESEV or AETOXGR must appear on the CRF. Some studies may mandate the collection of both. Refer to ICH E3 Section 12.2.4 guidelines for Clinical Study Reports.
Events	AE	N/A	N/A	21	AETOXGR	AE Standard Toxicity Grade	The grade of the severity of the event using a standard "toxicity" scale (e.g., NCI CTCAE).	What is the [NCI CTCAE/Name of scale (toxicity) grade] of the adverse event?	[NCI CTCAE/ Name of the scale] (Toxicity) Grade	Char	R/C	The reporting physician/healthcare professional will assess the severity of the adverse event using the specified grades scale.	AETOXGR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	Either AESEV or AETOXGR must appear on the CRF. Some studies may mandate the collection of both. Refer to ICH E3 Section 12.2.4 guidelines for CSR. CTCAE grade is commonly used in oncology studies, although it can also be used elsewhere. Other published "toxicity- like" scales can also be used.
Events	AE	N/A	N/A	22	AESER	AE Serious Event	An indication whether or not the adverse event is determined to be "serious" based on what is defined in the protocol.	Was the adverse event serious?	Serious	Char	R/C	Assess if an adverse event should be classified as serious based on the serious criteria defined in the protocol.	AESER	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	This field is related to the individual serious adverse event type fields, which may or may not be collected on the CRF. Either AESER or all the Adverse Serious type fields must be present on the CRF. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	23	AESDTH	Results in Death	An indication the serious adverse event resulted in death.	Did the adverse event result in death?	Death	Char	R/C	Record whether the serious adverse event resulted in death.	AESDTH	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	24	DTHDAT	Death Date	Date of death for any subject who died.	What [is/was] the subject's date of death?	Death Date	Char	O	Record the date of death.	DM.DTHDTC	This field does not map directly to an SDTMIG variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DTHDTC in ISO 8601 format.	N/A	N/A	The CDASH model defines Death Date as a timing variable; this is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the sponsor, but should only be collected once. The SDTMIG variable DTHDTC is mapped to the DM domain during the SDTM submission dataset creation process. The SDTMIG variable DM.DTHFLG is not a CDASH variable, but it is typically populated during the SDTM submission dataset creation process. Death Date may be mapped to other SDTM domains, as deemed appropriate by the sponsor (e.g., DS).
Events	AE	N/A	N/A	25	AESLIFE	Is Life Threatening	An indication the serious adverse event was life threatening.	Was the adverse event life threatening?	Life Threatening	Char	R/C	Record whether the serious adverse event is life threatening.	AESLIFE	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	26	AESHOSP	Requires or Prolongs Hospitalization	An indication the serious adverse event resulted in an initial or prolonged hospitalization.	Did the adverse event result in initial or prolonged hospitalization for the subject?	Hospitalization (initial or prolonged)	Char	R/C	Record whether the serious adverse event resulted in an initial or prolonged hospitalization.	AESHOSP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	27	AESDISAB	Persist or Signif Disability/Incapacity	An indication the serious adverse event was associated with a persistent or significant disability or incapacity.	Did the adverse event result in disability or permanent damage?	Disability or Permanent Damage	Char	R/C	Record whether the serious adverse event resulted in a persistent or significant disability or incapacity.	AESDISAB	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	28	AESCONG	Congenital Anomaly or Birth Defect	An indication the serious adverse event was associated with a congenital anomaly or birth defect.	Was the adverse event associated with a congenital anomaly or birth defect?	Congenital Anomaly or Birth Defect	Char	R/C	Record whether the serious adverse event was associated with congenital anomaly or birth defect.	AESCONG	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	29	AESINTV	Needs Intervention to Prevent Impairment	An indication an adverse event required medical or surgical intervention to preclude permanent impairment of a body function, or prevent permanent damage to a body structure, due to the use of a medical product.	Did the adverse event require intervention to prevent permanent impairment or damage resulting from the use of a medical product?	Needs Intervention to Prevent Impairment	Char	O	Record whether the serious adverse event required intervention to prevent permanent impairment or damage due to the use of a medical product.	SUPPAE.QVAL	This does not map directly to an SDTMIG variable. Sponsors should see requirements for the reporting of adverse events involving medical devices. Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	30	AESMIE	Other Medically Important Serious Event	An indication additional categories for seriousness apply.	Was the adverse event a medically important event not covered by other serious criteria?	Other Serious (Important Medical Events)	Char	R/C	Record whether the serious adverse event is an important medical event, which may be defined in the protocol or in the Investigator Brochure.	AESMIE	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data.
Events	AE	N/A	N/A	31	AESCAN	Involves Cancer	An indication the serious event was associated with the development of cancer.	Was the adverse event associated with the development of cancer?	Cancer	Char	O	Record whether the serious adverse event was associated with development of cancer.	AESCAN	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data. "Involves cancer" (AESCAN) and "Occurred with overdose" (AESOD) are not part of the ICH definition of a serious adverse event, but these categories are available for use in studies conducted under guidelines that existed prior to the FDA's adoption of the ICH definition.
Events	AE	N/A	N/A	32	AESOD	Occurred with Overdose	An indication the serious event occurred with an overdose.	Did the adverse event occur with an overdose?	Overdose	Char	O	Record whether the serious adverse event occurs with an overdose.	AESOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If the details regarding Serious AEs are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Sponsors may only collect the AESER field because the individual serious adverse event types might be collected in a separate pharmacovigilance database and therefore are not collected in the clinical database. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data. "Involves cancer" (AESCAN) and "Occurred with overdose" (AESOD) are not part of the ICH definition of a serious adverse event, but these categories are available for use in studies conducted under guidelines that existed prior to the FDA's adoption of the ICH definition.
Events	AE	N/A	N/A	33	AEREL	AE Causality	An indication the study treatment had a causal effect on the adverse event, as determined by the clinician/investigator.	Was this adverse event related to study treatment?	Relationship to Study Treatment	Char	HR	Indicate if the cause of the adverse event is related to the study treatment and cannot be reasonably explained by other factors (e.g., subject's clinical state, concomitant therapy, other interventions).	AEREL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsored-defined controlled terminology is used to indicate the relationship between the AE and the study treatment (e.g., ICH E2B examples include "Not Related", "Unlikely Related", "Possibly Related", "Related"). Another possibility is the use of "Y" and "N". CDISC Controlled Terminology may be defined in the future. It is recommended that sponsors check with the appropriate regulatory authority for population of this variable to ensure it meets expectations for submission.
Events	AE	N/A	N/A	34	AEACN	Action Taken with Study Treatment	A description of the action taken with study treatment as a result of the event.	What action was taken with study treatment?	Action Taken with Study Treatment	Char	R/C	Record changes made to the study treatment resulting from the adverse event.	AEACN	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ACN)	N/A	CDISC Controlled Terminology is used to indicate the action taken with the study treatment in response to the AE. How to handle multiple actions taken is a sponsor- specific decision. If this information is collected elsewhere (e.g., on the Exposure CRF), then it is not required to be collected on the AE CRF. This variable is not to be used for actions taken with devices. See the SDTMIG for Medical Devices for information on reporting multiple actions, or actions with multiple devices.
Events	AE	N/A	N/A	35	AEACNDEV	Actions Taken with Device	A description of the action taken, with respect to a device used in a study (which may or may not be the device under study), as a result of the event.	What action was taken with a device used in the study?	Action Taken with Device	Char	O	Record the action taken resulting from the adverse event that are related to a study or non-study device.	SUPPAE.QVAL	This does not map directly an SDTMIG variable. The sponsor may submit this data in a SUPPAE dataset where SUPPAE.QNAM = "AEACNDEV" and SUPPAE.QLABEL = "Actions Taken with Device". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	Sponsor-controlled terminology for actions that are related to the device (e.g., Device Removed, Primary Care Physician Notified). See the SDTMIG-MD for information on reporting multiple actions, or actions with multiple devices.
Events	AE	N/A	N/A	36	AEACNOTH	Other Action Taken	A description of other action taken as a result of the event that is unrelated to dose adjustments of the study treatment.	What other action was taken?	Other Action Taken	Char	O	Record all other action(s) taken resulting from the adverse event that are unrelated to study treatments given because of this adverse event.	AEACNOTH	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This field is usually collected as a free text field. If possible/desired, the sponsor can create controlled terminology (e.g., Treatment Unblinded, Primary Care Physician Notified).
Events	AE	N/A	N/A	37	AEOUT	Outcome of Adverse Event	A description of the outcome of an event.	What is the outcome of this adverse event?	Outcome	Char	R/C	Record the appropriate outcome of the event in relation to the subject's status.	AEOUT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(OUT)	N/A	CDISC Controlled Terminology is used to indicate the outcome of the event as it relates to the subject's status. The Outcome controlled terminology includes ICH E2B values. The use of this field is the recommended way to describe whether and how the AE resolved. Since the outcome of an AE may be "Death", if this field is NOT used, be sure to provide another form, such as Disposition, with clear instructions to record deaths there.
Events	AE	N/A	N/A	38	AEDIS	AE Caused Study Discontinuation	An indication whether the event caused the subject to discontinue from the study.	Did the adverse event cause the subject to be discontinued from the study?	Caused Study Discontinuation	Char	O	Record if the AE caused the subject to discontinue from the study.	SUPPAE.QVAL	This does not map directly an SDTMIG variable. May be used to create a RELREC to link the Adverse Event to the Disposition record (see SDTMIG v3.2 Section 8.2). The sponsor may also submit this data in a SUPPAE dataset where SUPPAE.QNAM = "AEDIS" and SUPPAE.QLABEL = "Caused Study Discontinuation", if appropriate. Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	Because the Action Taken field was defined to only collect the changes made to the study treatment due to the AE, an additional field was created to identify the AE(s) that caused the subject to discontinue from the study. Some sponsors opt to capture this information only on the Subject Disposition CRF, whereas others choose to collect this data on both the Subject Disposition and AE CRFs, so the specific AE term(s) and related data can be identified. If the CRF is designed to link the DS and AE records, then RELREC can be used to identify that relationship.
Events	AE	N/A	N/A	39	AERLNSYN	AE Related to Non- Study Treatment	An indication whether in the investigator's opinion the event may have been due to a treatment other than study treatment.	Was this adverse event due to treatment other than study treatment?	Related to Non- Study Treatment	Char	O	Indicate if this adverse event was due to treatment other than study treatment. If yes, briefly describe this non-study treatment relationship.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the CDASH AERELNST field on the CRF was deliberately left blank.
Events	AE	N/A	N/A	40	AERELNST	AE Relationship to Non-Study Treatment	Description of the investigator's opinion as to whether the adverse event may have been due to a treatment other than study treatment.	What is the relationship to non- study treatment?	Relationship to Non-Study Treatment	Char	O	Record the investigator's opinion as to whether the event may have been due to a treatment other than study drug.	AERELNST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	May be reported as free text (e.g., "MORE LIKELY RELATED TO ASPIRIN USE"). If possible/desired, sponsors can create controlled terminology.
Events	AE	N/A	N/A	41	AESI	Adverse Event of Special Interest	An adverse event of special interest (serious or non- serious) is one of scientific and medical concern specific to the sponsor's product or program, for which ongoing monitoring and rapid communication by the investigator to the sponsor can be appropriate. Such an event might warrant further investigation in order to characterize and understand it. Depending on the nature of the event, rapid communication by the trial sponsor to other parties (e.g., regulators) might also be warranted.	Is this event of special interest?	Adverse Event of Special Interest	Char	O	Record the investigator's opinion as to whether the event is an adverse event of special interest by the sponsor.	N/A	Does not map to an SDTM variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	This CDASH field may be used just to trigger other CRF pages, or populate a value in AECAT or AESCAT. If submitted, this information could be submitted in a SUPPAE dataset where SUPPAE.QNAM = "AESI" and SUPPAE.QLABEL = "Adverse Event of Special Interest. Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.
Events	AE	N/A	N/A	42	AEPATT	Pattern of Adverse Event	Used to indicate the pattern of the event over time.	What is the adverse event pattern?	Pattern	Char	O	For each AE, check the pattern of the AE. If a single event, choose single.	AEPATT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Used to report the pattern of the AE (e.g., INTERMITTENT, CONTINUOUS, SINGLE EVENT). For crossover trials, it is NOT recommended to capture this field for intermittent AEs. Instead, the AE should have corresponding Start and Stop dates to capture when the AE started and stopped.
Events	AE	N/A	N/A	43	AECONTRT	Concomitant or Additional Trtmnt Given	An indication whether a concomitant or additional treatment given because of the occurrence of the event.	Was a concomitant or additional treatment given due to this adverse event?	Concomitant or Additional Trtmnt Given	Char	O	Indicate if any non- study treatments were received because of this adverse event. If "Yes" is answered for this question, medications should be recorded on the ConMed CRF and procedures recorded on the Procedures CRF.	AECONTRT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	If medication data are reported, the CMAENO variable (on the ConMed CRF) may be used to collect the associated AE Identifier in order to populate RELREC. If procedures are reported, the PRAENO variable (on the Procedures CRF) may be used to collect the associated AE Identifier in order to populate RELREC.
Events	AE	N/A	N/A	44	AEMODIFY	AE Modified Reported Term	If the value for AETERM is modified to facilitate coding, then AEMODIFY will contain the modified text.	N/A	N/A	Char	R/C	N/A	AEMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process.
Events	AE	N/A	N/A	45	AEDECOD	AE Dictionary- Derived Term	The dictionary or standardized text description of AETERM or the modified topic variable (AEMODIFY), if applicable.	N/A	N/A	Char	O	N/A	AEDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define- XML external codelist attributes.	N/A	N/A	This is typically not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. Equivalent to the Preferred Term (PT in MedDRA).
Events	AE	N/A	N/A	46	AELLT	AE Lowest Level Term Code	MedDRA text description of the Lowest Level Term.	N/A	N/A	Char	R/C	N/A	AELLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	47	AELLTCD	AE Lowest Level Term Code	MedDRA Lowest Level Term code.	N/A	N/A	Num	R/C	N/A	AELLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	48	AEPTCD	AE Preferred Term Code	MedDRA code for the Preferred Term.	N/A	N/A	Num	R/C	N/A	AEPTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	49	AEHLT	AE High Level Term	MedDRA text description of the High Level Term from the primary path.	N/A	N/A	Char	R/C	N/A	AEHLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	50	AEHLTCD	AE High Level Term Code	MedDRA High Level Term code from the primary path.	N/A	N/A	Num	R/C	N/A	AEHLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	51	AEHLGT	AE High Level Group Term	MedDRA text description of the High Level Group Term from the primary path.	N/A	N/A	Char	R/C	N/A	AEHLGT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	52	AEHLGTCD	AE High Level Group Term Code	MedDRA High Level Group Term code from the primary path.	N/A	N/A	Num	R/C	N/A	AEHLGTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	53	AESOC	AE Primary System Organ Class	MedDRA Primary System Organ Class text description associated with the event.	N/A	N/A	Char	R/C	N/A	AESOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	54	AESOCCD	AE Primary System Organ Class Code	MedDRA code for the primary System Organ Class.	N/A	N/A	Num	R/C	N/A	AESOCCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	AE	N/A	N/A	55	AEACNOYN	Any Other Actions Taken	An indication whether any other actions were taken in response to the adverse event that were unrelated to study treatment dose changes or other non- study treatments given because of this adverse event.	Were any other actions taken in response to this adverse event?	Any Other Action(s) Taken	Char	O	Indicate whether any other action(s) were taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatments given because of this adverse event. If yes, briefly describe these actions.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the AEACNOTH field on the CRF was deliberately left blank.

Assumptions for the CDASHIG AE - Adverse Events Domain

1. The CDASHIG AEYN variable with the question text “Were any adverse events experienced?” is intended to assist in the cleaning of data and in confirming that there are no missing values. This CDASHIG variable is not included as part of the SDTMIG AE domain for submission. This question is annotated as "NOT SUBMITTED" on the CRF.

2. Categories AECAT and AESCAT

a. AECAT and AESCAT should not be redundant with the dictionary coding provided by AEDECOD and AESOC (i.e., they should provide a different means of defining or classifying AE records).
b. AECAT and AESCAT are intended for categorizations that are defined in advance. Forexample, a sponsor may have a separate CRF page for AEs of special interest and then another page for all other AEs. In cases where a category of AEs of special interest resembles a part of the dictionary hierarchy (e.g., "CARDIAC EVENTS"), the categorization represented by AECAT and AESCAT may differ from the categorization derived from the coding dictionary.

3. Presence or Absence of Events

a. AEs are most often collected as free-text, spontaneously reported adverse events. There may be cases where the occurrences of specific adverse events are solicited, per protocol requirements. In that case, the prespecified adverse events would be listed on the CRF with a "Yes/No" question (AEOCCUR) asking about the occurrence of each.
b. The CDASHIG variable AEOCCUR does not map directly to an SDTM variable. Because the SDTM AE domain is intended to hold only adverse events that actually happen, all values collected in AEOCCUR for prespecified AEs should be submitted in a Findings About Adverse Events domain (FAAE), where FAORRES = the value of AEOCCUR where FATESTCD = "OCCUR". In addition, where AEOCCUR = "Y", there should be a corresponding record in the AE domain.
c. It is important to reiterate the distinction between adverse events and clinical events, especially if there may be prespecified terms. In consulting with regulatory authorities, certain events (e.g., events associated with protocol endpoints) may simply be clinical events. (See Section 8.2.3, Clinical Events, for more details.)

4. Coding

a. AEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is a required SDTMIG variable and must have a value. It is expected that the reported term (AETERM) will be coded using a standard dictionary such as MedDRA. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
b. AEMODIFY is a permissible SDTMIG variable and should be included if the sponsor’s coding procedure permits modification of a verbatim term. The modified term is listed in AEMODIFY. The variable should be populated as per the sponsor’s coding procedure.
c. The CDASHIG elements AELLT, AELLTCD, AEPTCD, AEHLT, AEHLTCD, AEHLGT, AEHLGTCD, AEBDSYCD, AESOC, and AESOCCD are only applicable to events coded in MedDRA. These items are not expected for non-MedDRA coding.

5. Relative Timing Variables

a. The AEONGO field does not map directly to an SDTMIG variable but it may be used to derive a value into an SDTMIG relative timing variable such as AEENRF or AEENRTPT. When populating AEENRF, if the AEONGO field is checked, a value of "DURING", "AFTER", or "DURING/AFTER" may be derived, as is appropriate to the study. When populating AEENRTPT, if the AEONGO field is checked, the value of "ONGOING" may be derived. Note: AEENRTPT must refer to a "time point anchor" as described in AEENTPT.
b. Note that AEONGO is a special use case of "Yes/No" where the question is usually presented as a single possible response of "Yes" when there is no applicable end date at the time of collection. In this case, if the box is checked and the end date is blank, the desired SDTMIG relative timing variable can be derived according to note 5a above. If the box is not checked (AEONGO is NULL) and an end date is present, no SDTMIG relative timing variable would be derived. In some cases, unique to AE, the ongoing status may be determined from AE Outcome. AEONGO is only used to derive an appropriate SDTMIG relative timing variable and should not be submitted on its own in the AE or SUPPAE dataset. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the end date was deliberately left blank.

6. CDASHIG Action Taken Variables

a. CDASHIG variables AEACN, AECONTRT, AEACNDEV, AEACNOYN, and AEACNOTH are used to collect the action taken as the result of an AE.
b. AEACN describes action taken with study treatment as a result of the event. It is expected that a response would be provided for this question for all AEs. If multiple treatments are administered, then a corresponding variable should be created to capture the action taken for each treatment.
c. AEACNOTH describes Other Action(s) taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatment given because of this adverse event. This field is usually collected as a free-text field (e.g., Treatment Unblinded, Primary Care Physician Notified). If possible/desired, the sponsor can create sponsor-defined controlled terminology. The CDASHIG variable AEACNOYN is used in conjunction with AEACNOTH to assist in the cleaning of data and in confirming that AEACNOTH is not missing. AEACNOYN is not included as part of the SDTMIG AE domain for submission and is annotated as NOT SUBMITTED on the CRF. The CDASHIG variable AEACNOYN should only be used on the AE CRF.
d. AECONTRT indicates if any non-study treatments were received because of this adverse event. If "Yes" is answered for this question, any drugs used are recorded on the Concomitant Medications CRF and any procedures performed are recorded on the Procedure CRF. On the CM CRF, the CDASHIG variable CMAENO or on the PR CRF the CDASHIG variable PRAENO can be collected to identify the adverse event associated with this treatment by recording the appropriate AESPID. RELREC can be used to identify this relationship.
e. AEACNDEV describes action taken with respect to a device in a study, which may or may not be the device under study. This field is usually collected as a free-text field. If possible/desired, the sponsor can create sponsor-defined controlled terminology. FDA Medical Device Reporting (MDR) guidelines (available at https://www.fda.gov/medicaldevices/) provide controlled terminology for the reporting of device problems.

7. Serious Adverse Events

a. If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate "Yes/No" variable be defined for each Serious AE type (AESCAN, AESCONG, AESDISAB, AESDTH, AESHOSP, AESLIFE, AESOD, AESMIE).
b. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data (see FDA Study Data Technical Conformance Guide, https://www.fda.gov/ForIndustry/DataStandards/StudyDataStandards/default.htm). The serious categories “Involves cancer” (AESCAN) and “Occurred with overdose” (AESOD) are not part of the ICH definition of a serious adverse event, but these categories are available for use in studies conducted under guidelines that existed prior to the FDA’s adoption of the ICH definition.

8. CDASHIG Variables AESEV, AETOXGR

a. In studies using a standard toxicity scale such as the National Cancer Institute's Common Terminology Criteria for Adverse Events v3.0 (CTCAE; available at https://ctep.cancer.gov/protocoldevelopment/), AETOXGR should be used instead of AESEV. In most cases, either AESEV or AETOXGR is populated but not both.
b. There may be cases in which a sponsor may need to populate both variables. Whether populating either AESEV or AETOXGR or both, the sponsor is expected to provide the dictionary name and version or standard toxicity scale name and version used to map the terms utilizing the define.xml external codelist attributes.

9. CDASHIG Variable DTHDAT

a. The CDASH Model allows the Date of Death to be collected on any CRF deemed appropriate by the sponsor. Death Date is mapped to other SDTMIG domains, as deemed appropriate by the sponsor (e.g., DM, DS).
b. The death date should only be collected on one form.

Example CRF for the CDASHIG AE - Adverse Events Domain

Example 1

Title: Adverse Events

Example CRF Completion Instructions Record all AEs except [list of protocol-defined exceptions] on the AE CRF after informed consent is obtained. All Serious Adverse Events (AEs), regardless of relationship to study drug, must be reported via telephone or fax within 24 hours of discovery. Safety information (e.g., AE, SAE) identified for all subjects must be recorded on source documents from the time informed consent is obtained.





CRF Metadata

Order	Question Text	Prompt	CRF Completion Instructions	Type	CDASH Variable	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology CodeList Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	Were any adverse events experienced?	Any Adverse Events	Indicate if the subject experienced any adverse events. If Yes, include the appropriate details where indicated on the CRF.	Text	AEYN	N/A		(NY)	Yes; No
2	What is the category of the adverse event?	Adverse Event Category	Record the adverse event category, if not preprinted on the CRF.	Text	AECAT	AECAT				Sponsor Defined			Yes
3	What is the subcategory of the adverse event?	Adverse Event Subcategory	Record the adverse event subcategory, if not preprinted on the CRF.	Text	AESCAT	AESCAT				Sponsor Defined			Yes
4	What is the adverse event identifier?	AE Number	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Integer	AESPID	AESPID					prompt
5	What is the adverse event term?	Adverse Event	Record only one diagnosis, sign, or symptom per line (e.g., nausea and vomiting should not be recorded in the same entry, but as two separate entries). Using accepted medical terminology, enter the diagnosis (if known); otherwise, enter a sign or symptom.	Text	AETERM	AETERM
6	What is the adverse event start date?	Start Date	Record the start date of the AE using this format (DD-MON- YYYY).	Date	AESTDAT	AESTDTC					prompt
7	Is the adverse event ongoing?	Ongoing	Indicate if the adverse event has not resolved at the time of data collection; leave the End Date blank.	Text	AEONGO	AEENRTPT; AEENRF	AEENRTPT; AEENRF	(NY)	Yes			checkbox
8	What was the adverse event end date?	End Date	Record the date that the AE resolved using this format (DD- MON-YYYY). If the AE is ongoing, leave the field blank.	date	AEENDAT	AEENDTC					prompt
9	What is the severity of the adverse event?	Severity	The reporting physician/healthcare professional will assess the severity of the event using the sponsor-defined categories. This assessment is subjective and the reporting physician/ healthcare professional should use medical judgment to compare the reported AE to similar type events observed in clinical practice. Severity is not equivalent to seriousness.	Text	AESEV	AESEV		(AESEV)	MILD; MODERATE; SEVERE		prompt
10	Was the adverse event serious?	Serious	Assess if an adverse event should be classified as serious based on the serious criteria defined in the protocol.	Text	AESER	AESER		(NY)	Yes; No
11	Did the adverse event result in death?	Death	Record whether the serious adverse event resulted in death.	Text	AESDTH	AESDTH		(NY)	Yes; No
12	What [is/was] the subject’s date of death?	Death Date	Record the date of death.	date	DTHDAT	DM.DTHDTC					prompt
13	Was the adverse event life threatening?	Life Threatening	Record whether the serious adverse event is life threatening.	Text	AESLIFE	AESLIFE		(NY)	Yes; No		prompt
14	Did the adverse event result in initial or prolonged hospitalization for the subject?	Hospitalization (initial or prolonged)	Record whether the serious adverse event resulted in an initial or prolonged hospitalization.	Text	AESHOSP	AESHOSP		(NY)	Yes; No		prompt
15	Did the adverse event result in disability or permanent damage?	Disability or Permanent Damage	Record whether the serious adverse event resulted in a persistent or significant disability or incapacity.	Text	AESDISAB	AESDISAB		(NY)	Yes; No		prompt
16	Was the adverse event associated with a congenital anomaly or birth defect?	Congenital Anomaly or Birth Defect	Record whether the serious adverse event was associated with congenital anomaly or birth defect.	Text	AESCONG	AESCONG		(NY)	Yes; No		prompt
17	Did the adverse event require intervention to prevent permanent impairment or damage resulting from the use of a medical product?	Needs Intervention to Prevent Impairment	Record whether the serious adverse event required intervention to prevent permanent impairment or damage due to the use of a medical product.	Text	AESINTV	SUPPAE.QVAL		(NY)	Yes; No		prompt
18	Was the adverse event a medically important event not covered by other serious criteria?	Other Serious (Important Medical Events)	Record whether the serious adverse event is an important medical event, which may be defined in the protocol or in the Investigator Brochure.	Text	AESMIE	AESMIE		(NY)	Yes; No		prompt
19	Was this adverse event related to study treatment?	Relationship to Study Treatment	Indicate if the cause of the adverse event is related to the study treatment and cannot be reasonably explained by other factors (e.g., subject's clinical state, concomitant therapy, other interventions).	Text	AEREL	AEREL			NOT RELATED; UNLIKELY RELATED; POSSIBLY RELATED; RELATED		prompt
20	What action was taken with study treatment?	Action Taken with Study Treatment	Record changes made to the study treatment resulting from the adverse event.	Text	AEACN	AEACN		(ACN)	DRUG WITHDRAWN; DOSE REDUCED; DOSE INCREASED; DOSE NOT CHANGED; UNKNOWN; NOT APPLICABLE		prompt
21	What is the outcome of this adverse event?	Outcome	Record the appropriate outcome of the event in relation to the subject's status.	Text	AEOUT	AEOUT		(OUT)	RECOVERING / RESOLVING; NOT RECOVERED / NOT RESOLVED; RECOVERED / RESOLVED; RECOVERED / RESOLVED WITH SEQUELAE; FATAL		prompt

8.2.3 CE - Clinical Events

Description/Overview for the CDASHIG CE - Clinical Events Domain

The CE domain includes clinical events of interest that would not be classified as Adverse Events. The clinical events included in the CE dataset should be consistent with the protocol requirements. Clinical events may be captured either as free text or via a prespecified list of terms. The structure of the CE domain is 1 record per clinical event per subject. It is the sponsor's responsibility to define a clinical event, and the event is usually described in the protocol.

As with all the data collection variables recommended in CDASH, 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, or operating procedures). Sponsors should define the appropriate collection period for clinical events.

Specification for the CDASHIG CE - Clinical Events Domain

Clinical Events Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	CE	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Although this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Events	CE	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	CE	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	CE	N/A	N/A	4	CECAT	Category for Clinical Event	A grouping of topic-variable values based on user-defined characteristics.	What is the category of the clinical event?	[Clinical Event Category]; NULL	Char	O	Record the clinical event category, if not preprinted on the CRF.	CECAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Events	CE	N/A	N/A	5	CESCAT	Subcategory for Clinical Event	A sub-division of the CECAT values based on user-defined characteristics.	What is the subcategory of the clinical event?	[Clinical Event Subcategory]; NULL	Char	O	Record the clinical event subcategory, if not preprinted on the CRF.	CESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. CESCAT can only be used if there is an CECAT and it must be a subcategorization of CECAT.
Events	CE	N/A	N/A	6	CEYN	Any Clinical Event	An indication whether or not any clinical events were experienced during the study.	Were any clinical events experienced?	Any Clinical Events	Char	O	Indicate if the subject experienced any clinical events. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Events	CE	N/A	N/A	7	CESPID	CE Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor defined question]	Sponsor defined	Char	O	If collected on the CRF, the sponsor may insert instructions to ensure each record has a unique identifier.	CESPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medications, procedures and/or medical history records with CEs. If CMCENO or PRCENO is used, this is the identifier to which CMCENO or PRCENO refers. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Events	CE	N/A	N/A	8	CETERM	Reported Term for the Clinical Event	The reported or prespecified name of the clinical event.	What is the clinical event term?	[Clinical Event]; Specify (Other/Details)	Char	HR	Record the clinical event or [insert text corresponding to the specific clinical event].	CETERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Can be represented either as an open-entry field to capture verbatim terms reported by subjects or could be preprinted in the situation where solicited CEs of interest are captured. May be used as Specify Other field to collect more details on a prespecified CEDECOD value, or when CEDECOD=Other. In most cases, the verbatim term (i.e., investigator- reported term) will be coded to a standard medical dictionary such as MedDRA or WHO ART, after the data have been collected on the CRF.
Events	CE	N/A	N/A	9	CEOCCUR	Clinical Event Occurrence	An indication whether a prespecified clinical event or a group of clinical events occurred when information about the occurrence of a specific event is solicited.	Did the subject have [prespecified clinical event/group of clinical events ]?	[Specified Clinical Event]	Char	O	Indicate if [specific clinical event] has occurred/is occurring by checking Yes or No.	CEOCCUR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	The CDASH variable CEOCCUR is used to report the occurrence of a prespecified clinical event not considered to be an adverse event by the sponsor. CEOCCUR should not be used for spontaneously reported events. The site should be able to indicate that the response was not asked or answered.
Events	CE	N/A	N/A	10	CEPRESP	Clinical Event prespecified	An indication that a specific event, or group of events, are prespecified on a CRF.	N/A	N/A	Char	O	N/A	CEPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	A hidden field on a CRF defaulted to "Y", or added during the SDTM-based dataset creation when the clinical event is prespecified. Null for spontaneously reported events. If a study collects both prespecified clinical events as well as free-text events, the value of CEPRESP should be "Y" for all prespecified events and null for events reported as free-text. CEPRESP is a permissible field in SDTM and may be omitted from the SDTM-based dataset if all events were collected as free text.
Events	CE	N/A	N/A	11	CESTDAT	Clinical Event Start Date	The start date of the clinical event, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the [clinical event] start date?	Start Date	Char	O	Record the start date of the [clinical event ] using this format (DD- MON-YYYY).	CESTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CESTDTC in ISO 8601 format.	N/A	N/A	N/A
Events	CE	N/A	N/A	12	CESTTIM	Clinical Event Start Time	The start time of the clinical event represented in an unambiguous date format (e.g., hh:mm:ss).	What was the [clinical event] start time?	Start Time	Char	O	If appropriate, record the start time (as complete as possible) of the [clinical event].	CESTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable CESTDTC in ISO 8601 format.	N/A	N/A	Collecting the time a CE started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event started and the study design is such that it is important to know the CE start time with respect to dosing.
Events	CE	N/A	N/A	13	CELOC	Clinical Event Location	A description of the anatomical location relevant for the clinical event.	What was the anatomical location of the [clinical event]?	Anatomical Location	Char	O	Indicate the anatomical location of the clinical event.	CELOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, PORTOT are used to further describe the anatomical location.
Events	CE	N/A	N/A	14	CELAT	Clinical Event Laterality	Qualifier for anatomical location further detailing the side of the body relevant for the event.	What was the side of the anatomical location of the [clinical event]?	Side	Char	O	Record the side of the anatomical location of the clinical event.	CELAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	CE	N/A	N/A	15	CEDIR	Clinical Event Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the [clinical event]?	Directionality	Char	O	Record the directionality of the anatomical location of the clinical event.	CEDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	CE	N/A	N/A	16	CEPORTOT	CE Location Portion or Totality	Qualifier for anatomical location further detailing the distribution (i.e., arrangement of, apportioning of).	What was the portion or totality of the anatomical location of the clinical event?	Portion or Totality	Char	O	Indicate the portion or totality anatomical location of the clinical event.	CEPORTOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	CE	N/A	N/A	17	CEONGO	Ongoing Clinical Event	Indication the clinical event is ongoing when no end date is provided.	Was the [clinical event] ongoing (as of [the study- specific timepoint or period]?	Ongoing (as of the [study-specific timepoint or period])	Char	O	Indicate if the clinical event has not resolved at the time of data collection. If ongoing leave the End Date blank.	CEENRTPT; CEENRF	This does not map directly to an SDTMIG variable. May be used to populate a value into an SDTMIG relative timing variable such as CEENRF or CEENRTPT. When populating CEENRF, if the value of CEONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating CEENRTPT, if the value of CEONGO is "Y", the value of "ONGOING" may be used. When CEONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable CEENRF should be populated. When CEONGO is compared to another time point, the SDTMIG variables CEENRTPT and CEENTPT should be used. Note: CEENRTPT must refer to a time point anchor described in CEENTPT.	(NY)	N/A	Completed to indicate that the CE has not resolved at the time of data collection, when no End Date is collected. In some cases the ongoing status may be determined from CE Outcome. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the End Date was deliberately left blank. Often used as a tick/checkbox.
Events	CE	N/A	N/A	18	CEENDAT	Clinical Event End Date	The date when the clinical event resolved/ ended, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the [clinical event] end date?	End Date	Char	O	Record the date that the [clinical event] resolved using this format (DD- MON-YYYY). If the [clinical event] is ongoing, leave the field blank.	CEENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable CEENDTC in ISO 8601 format.	N/A	N/A	The definition of resolved is sponsor-specific. The preferred method is to collect a complete end date. Partial dates (e.g., providing year only, month and year only) may be acceptable.
Events	CE	N/A	N/A	19	CEENTIM	Clinical Event End Time	The time when the clinical event ended/resolved, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the [clinical event] end time?	End Time	Char	O	Record the time (as complete as possible) that the [clinical event] resolved.	CEENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable CEENDTC in ISO 8601 format.	N/A	N/A	Collecting the time an CE resolved is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the event resolved and the study design is such that it is important to know the CE end time with respect to dosing.
Events	CE	N/A	N/A	20	CESEV	CE Severity/Intensity	The severity or intensity of the event.	What was the severity of the [clinical event]?	Severity	Char	O	The reporting physician/healthcare professional will assess the severity of the event using the sponsor- defined categories. This assessment is subjective and the reporting physician/ healthcare professional should use medical judgment to compare the reported clinical event to similar type events observed in clinical practice.	CESEV	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	Some studies may collect Severity and/or Toxicity Grade.
Events	CE	N/A	N/A	21	CETOX	Clinical Event Toxicity Description	A description of toxicity quantified by CETOXGR (e.g., NCI CTCAE Short Name).	What was the description of the toxicity?	[NCI CTCAE] Toxicity	Char	O	Record the description of the toxicity.	CETOX	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	This would typically be the text description quantified by CETOXGR (e.g., HYPERCALCEMIA, HYPOCALCEMIA)
Events	CE	N/A	N/A	22	CETOXGR	Clinical Event Toxicity Grade	The toxicity grade using a standard toxicity scale (e.g., NCI CTCAE).	What was the toxicity grade?	[NCI CTCAE Toxicity] Grade	Char	O	Record the severity of the clinical event using the CTCAE Toxicity Grades.	CETOXGR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	Some studies may collect Severity and/or Toxicity Grade. CDISC Controlled Terminology (TOXGRV3); (TOXGRV4) may be used.
Events	CE	N/A	N/A	23	CEMODIFY	Clinical Event Modified Term	If the value for CETERM is modified to facilitate coding, then CEMODIFY will contain the modified text.	N/A	N/A	Char	O	N/A	CEMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process.
Events	CE	N/A	N/A	24	CEDECOD	CE Dictionary- Derived Term	The dictionary- or sponsor-defined standardized text description of CETERM or the modified topic variable (CEMODIFY), if applicable.	N/A	N/A	Char	O	N/A	CEDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This is typically not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. Equivalent to the Preferred Term (PT in MedDRA).
Events	CE	N/A	N/A	25	CELLT	Clinical Event Lowest Level Term	MedDRA text description of the Lowest Level Term.	N/A	N/A	Char	O	N/A	CELLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	26	CELLTCD	Clinical Event Lowest Level Term Code	MedDRA Lowest Level Term code.	N/A	N/A	Num	O	N/A	CELLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	27	CEPTCD	Clinical Event Preferred Term Code	MedDRA code for the Preferred Term.	N/A	N/A	Num	O	N/A	CEPTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	28	CEHLT	Clinical Event High Level Term	MedDRA text description of the High Level Term from the primary path.	N/A	N/A	Char	O	N/A	CEHLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	29	CEHLTCD	Clinical Event High Level Term Code	MedDRA High Level Term code from the primary path.	N/A	N/A	Num	O	N/A	CEHLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	30	CEHLGT	Clinical Event High Level Group Term	MedDRA text description of the High Level Group Term from the primary path.	N/A	N/A	Char	O	N/A	CEHLGT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	31	CEHLGTCD	CE High Level Group Term Code	MedDRA High Level Group Term code from the primary path.	N/A	N/A	Num	O	N/A	CEHLGTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	32	CESOC	CE Primary System Organ Class	MedDRA Primary System Organ Class description associated with the event.	N/A	N/A	Char	O	N/A	CESOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	CE	N/A	N/A	33	CESOCCD	CE Primary System Organ Class Code	MedDRA code for the primary System Organ Class.	N/A	N/A	Num	O	N/A	CESOCCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.

Assumptions for the CDASHIG CE - Clinical Events Domain

1. The determination of events to be considered clinical events versus adverse events should be done carefully and with reference to regulatory guidelines or consultation with a regulatory review division. Please note that all reportable adverse events that would contribute to AE incidence tables in a clinical study report must be included in the AE domain. AE data should not be commingled with CE data. The collection of write-in events on a CE CRF should be considered with caution.

2. Events considered to be clinical events may include episodes of symptoms of the disease under study (often known as signs and symptoms), or about events that do not constitute adverse events in themselves, although they might lead to the identification of an adverse event. For example, in a study of an investigational treatment for migraine headaches, migraine headaches may not be considered to be AEs per protocol. The occurrence of migraines or associated signs and symptoms might be reported in CE.

3. Some clinical events may escalate (e.g., increase in duration, severity) and require additional collection in AE. This should be clearly defined in the protocol.

4. The CDASHIG variable CEYN, with the question text “Were any clinical events experienced?”, is intended to assist in the cleaning of data and in confirming that no data are unintentionally missing. This CDASHIG variable is not included as part of the SDTM Event domain for submission. This field is annotated as NOT SUBMITTED on the CRF.

5. Categories CECAT and CESCAT should not be redundant with the domain code or dictionary classification provided by CEDECOD and CESOC (i.e., they should provide a different means of defining or classifying CE records).

6. Presence or Absence of Events: The CDASHIG variable CEOCCUR is used to record whether a subject had a prespecified clinical event. Example: "Does the subject have a fever?"

7. Coding

a. CEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is permissible to code CETERM using a standard dictionary such as MedDRA. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.

b. CEMODIFY is a permissible variable and should be included if the sponsor’s coding procedure permits modification of a verbatim term. The modified term is listed in CEMODIFY. The variable should be populated as per the sponsor’s coding procedure. The CDASHIG elements CELLT, CELLTCD, CEPTCD, CEHLT, CEHLTCD, CEHLGT, CEHLGTCD, CEBDSYCD, CESOC, and CESOCCD are only applicable to events coded in MedDRA. These items are not expected for non- MedDRA coding.

8. Relative Timing Variables

a. CEONGO field does not map directly to an SDTMIG variable. It may be used to derive a value into an SDTMIG relative timing variable such as CEENRF or CEENRTPT when no end date is recorded. When populating CEENRF, if the value of CEONGO is "Y", a value (from the values "DURING", "AFTER" or "DURING/AFTER", as is appropriate to the study) may be derived.

b. When populating CEENRTPT, if the value of CEONGO is "Y", the value of "ONGOING" may be derived. CEENRTPT must refer to a "time point anchor" described in CEENTPT.

9. CEONGO is a special use case of Yes/No where the question is usually presented as a single possible response of Yes in conjunction with another question, as in this case, an end date. CEONGO is completed to indicate that the CE has not resolved at the time of data collection, and thus no end date is collected. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the end date was deliberately left blank

Example CRF for the CDASHIG CE - Clinical Events Domain

Example 1

Title: Hypoglycemic Events







CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
HYPOEV_CECAT	1	What is the category of the clinical event?	Clinical Event Category	Record the clinical event category, if not pre- printed on the CRF.	Text	CECAT				HYPO EVENTS	Prompt		Yes
HYPOEV_CETERM	2	What is the clinical event term?	Clinical Event	Record the clinical event or [insert text corresponding to the specific clinical event].	Text	CETERM	CETERM where CECAT = "HYPO EVENTS"			HYPOGLYCEMIC EVENT	Prompt		Yes
HYPOEV_CEYN	3	Were any hypoglycemic events experienced?	Any Hypoglycemic Events	Indicate if the subject experienced any hypoglycemic events. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes			radio
HYPOEV_CESPID	4	What is the clinical event identifier?	Sponsor Defined ID	If collected on the CRF, sponsors may insert instructions to ensure each record has a unique identifier.	Text	CESPID	CESPID where CECAT = "HYPO EVENTS"			001	Prompt
HYPOEV_CESTDAT	5	What was the clinical event start date?	Start Date	The start date of the clinical event represented in an unambiguous date format (e.g., DD-MON- YYYY).	Date	CESTDTC	CESTDTC where CECAT = "HYPO EVENTS"				Prompt
HYPOEV_CESTTIM	6	What was the clinical event start time?	Start Time	The start time of the clinical event represented in an unambiguous date format (e.g., hh:mm:ss).	Time	CESTDTC	CESTDTC where CECAT = "HYPO EVENTS"				Prompt
WHENOCC	7	When did the Hypoglycemic Event Occur?	Time Period	Record the time period during which the hypoglycemic event occurred.	Text	SUPPCE.QVAL	SUPPCE.QVAL where SUPPCE.QNAM = "WHENOCC" and SUPPCE.QLABEL = "When Did the Hypoglycemic Event Occur?"		Between Bedtime and Waking; Between Waking and Bedtime			radio
WASAEYN_FAORRES	8	In the Opinion of the Investigator Was This an Adverse Event?	Adverse Event	Indicate whether or not the investigator has determined this to be an adverse event.	Text	FAORRES	FAORRES where FATESTCD = "WASAEYN" and FATEST = "Was this an adverse event?" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes			radio
LBCAT	9	What was the name of the lab panel?	Lab Panel Name	Record the lab test category, if not pre- printed on the CRF.	Text	LBCAT				CHEMISTRY	Prompt		Yes
LBTEST	10	What was the lab test name?	Lab Test Name	Record the name of the Lab measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	LBTEST				GLUCOSE	Prompt		Yes
LBPERF	11	Was a glucose measurement obtained at the time of the event?	Lab Performed	Indicate whether or not glucose measurement obtained.	Text	LBSTAT	LBSTAT = "NOT DONE" when LBPERF = "N" and LBSTAT is null when LBPERF = "Y"	(NY)	No; Yes			radio
LBORRES	12	What was the result of the glucose lab test?	Glucose Result	Record laboratory test result.	Text	LBORRES					Prompt
LBORRESU	13	What was the unit of the glucose lab result?	Glucose Units	Record or select the original unit in which these data were collected.	Text	LBORRESU		(UNIT)	mg/dL; mmol/L		Prompt	radio
ECCAT	14	What is the category of the study treatment?	Study Treatment Category	Record the study treatment category, if not pre-printed on the CRF.	Text	ECCAT				HIGHLIGHTED DOSE	Prompt		Yes
ECTRT	15	What was the last study medication taken?	Last Study Medication Taken	Record the name of study treatment.	Text	ECTRT					Prompt
ECSTDAT	16	What was the dose date?	Date	Record the start date of the study treatment administration using this format (DD-MON- YYYY).	Date	ECSTDTC					Prompt
ECSTTIM	17	What was the dose time?	Time	Record the start time (as complete as possible) when administration of study treatment started.	Date	ECSTDTC					Prompt
ECDSTXT	18	What was the dose per administration of study treatment?	Dose	Record the dose or amount of study treatment that was administered to/taken by the subject in the period recorded, from the start date/time to the end date/time inclusive.	Text	ECDOSTXT; ECDOSE					Prompt
ECDOSU	19	What were the units for the dose?	Units	Record the unit of dose or amount taken per period recorded (e.g., ng, mg, mg/kg).	Text	ECDOSU		(UNIT)	mg; mL		Prompt	radio
ANTIHYPR_CMCAT	20	What is the category for the concomitant medication?	Concomitant Medication Category	Record the concomitant medication category, if not pre-printed on the CRF.	Text	CMCAT				ANTI- HYPERGLYCEMIC MED	Prompt		Yes
ANTIHYPR_CMSCAT	21	What is the subcategory for the concomitant medication?	Concomitant Medication Subcategory	Record the concomitant medication subcategory, if not pre-printed on the CRF.	Text	CMSCAT	CMSCAT where CMCAT = "ANTI-HYPERGLYCEMIC MED"			HIGHLIGHTED DOSE	Prompt		Yes
ANTIHYPR_CMTRT	22	What was the last concomitant diabetic medication taken?	Last Concomitant Diabetic Medication Taken	Provide the full trade or proprietary name of the medication; otherwise the generic name may be recorded.	Text	CMTRT	CMTRT where CMCAT = "ANTI-HYPERGLYCEMIC MED"				Prompt
ANTIHYPR_CMSTDAT	23	What was the concomitant medication dose date?	Date	Record the date the concomitant medication dose was taken using this format (DD-MON- YYYY).	Date	CMSTDTC	CMSTDTC where CMCAT = "ANTI-HYPERGLYCEMIC MED"				Prompt
ANTIHYPR_CMSTTIM	24	What was the concomitant medication dose time?	Time	Record the time (as complete as possible) that the concomitant medication dose was taken.	Date	CMSTDTC	CMSTDTC where CMCAT = "ANTI-HYPERGLYCEMIC MED"				Prompt
ANTIHYPR_CMDSTXT	25	What was the individual dose of the concomitant mediation?	Dose	Record the dose of concomitant medication taken per administration (e.g., 200).	Text	CMDOSTXT; CMDOSE	CMDOSTXT and CMDOSE where CMCAT = "ANTI- HYPERGLYCEMIC MED"				Prompt
ANTIHYPR_CMDOSU	26	What is the unit for the dose of concomitant medication?	Unit	Record the dose unit of the dose of concomitant medication taken (e.g., mg.).	Text	CMDOSU	CMDOSU where CMCAT = "ANTI-HYPERGLYCEMIC MED"	(UNIT)	g; IU; mg; mL; ug		Prompt	radio
MLSTDAT	27	What was the date of last meal?	Date of Last Meal	Record using DD-MMM- YYYY format.	Date	MLSTDTC					Prompt
MLSTTIM	28	What was the time of last meal?	Time of Last Meal	Record time using a 24- hour clock.	Time	MLSTDTC					Prompt
HYPOSYMP_CECAT	29	What is the category of the clinical event?	Clinical Event Category	Record the clinical event category, if not preprinted on the CRF.	Text	CECAT				HYPO SYMPTOMS	Prompt		Yes
HYPOSYMP_CEYN	30	Were any signs/symptoms reported?	Any Signs/Symptoms	Indicate if the subject experienced any signs/symptoms. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes			radio
HYPOSYMP_SWEATING_CEOCCUR	31	Did the subject experience sweating?	Sweating	Record whether the subject experienced sweating during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "SWEATING" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_TREMOR_CEOCCUR	32	Did the subject experience tremors/trembling?	Tremors/Trembling	Record whether the subject experienced tremors/trembling during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "TREMORS/TREMBLING" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_DIZZY_CEOCCUR	33	Did the subject experience dizziness?	Dizziness	Record whether the subject experienced dizziness during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "DIZZINESS" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_COGIMP_CEOCCUR	34	Did the subject experience cognitive impairment?	Cognitive Impairment	Record whether the subject experienced cognitive impairment during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "COGNITIVE IMPAIRMENT" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_LOSOCONS_CEOCCUR	35	Did the subject experience loss of consciousness?	Loss of Consciousness	Record whether the subject experienced loss of consciousness during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "LOSS OF CONSCIOUSNESS" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_SEIZURE_CEOCCUR	36	Did the subject experience convulsions/seizure?	Convulsions/Seizure	Record whether the subject experienced convulsions/seizure during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "CONVULSIONS/SEIZURE" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_COMA_CEOCCUR	37	Did the subject experience coma?	Coma	Record whether the subject experienced coma during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = "COMA" and CECAT = "HYPO SYMPTOMS" and CEPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_OTHER_CEOCCUR	38	Did the subject experience any other sign/symptom?	Other (Specify)	Record whether the subject experienced an "other" sign/symptom during the hypoglycemic event.	Text	CEOCCUR	CEOCCUR where CETERM = value entered in HYPOSYMP_CETERM and CECAT = "HYPO SYMPTOMS"	(NY)	No; Yes		Prompt	radio
HYPOSYMP_CETERM	39	If Other, specify	Specify	If "other" is indicated, specify the sign/symptom.	Text	CETERM	CETERM where CECAT = "HYPO SYMPTOMS"
HPF_FACAT	40	What is the category?	Category	Record the FA category, if not pre-printed on the CRF.	Text	FACAT				PRECIPIATING FACTORS	Prompt		Yes
HPF_FAOBJ	41	N/A	N/A	N/A	Text	FAOBJ	FAOBJ where FACAT = "PRECIPIATING FACTORS"			HYPOGLYCEMIC EVENT	Prompt		Yes
HPF_FAYN	42	Were any precipitating factors reported?	Any Precipitating Factors	Indicate if there are findings. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes			radio
HPF_ALCPF_FAORRES	43	Was alcohol consumption a precipitating factor?	Alcohol Consumption	Indicate if alcohol consumption was a precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD = "ALCPF" and FATEST = "Alcohol Consumption as a Precip Factor" and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_ILLPF_FAORRES	44	Was concurrent illness a precipitating factor?	Concurrent Illness	Indicate if concurrent illness was a precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD = "ILLPF" and FATEST = "Concurrent Illness as a Precip Factor" and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_DSDVPF_FAORRES	45	Was deviation from dosing instructions a precipitating factor?	Deviation from Dosing Instructions	Indicate if deviation from dosing instructions was a precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD = "DSDVPF" and FATEST = "Dosing Deviation as a Precip Factor" and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_MEALPF_FAORRES	46	Was missed, delayed or smaller meal a precipitating factor?	Missed, Delayed or Smaller Meal	Indicate if missed, delayed, or smaller meal was a precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD = "MEALPF" and FATEST = "Meal Variance as a Precip Factor" and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_PAPF_FAORRES	47	Was physical activity a precipitating factor?	Physical Activity	Indicate if physical activity was a precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD = "PAPF" and FATEST = "Physical Activity as a Precip Factor" and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_OTHPF_FAORRES	48	Was there any other precipitating factor?	Other (Specify)	Indicate if there was an other precipitating factor of the hypoglycemic event.	Text	FAORRES	FAORRES where FATESTCD/FATEST are derived from the value entered in HPF_FATEST and FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"	(NY)	No; Yes		Prompt	radio
HPF_FATEST	49	If Other, specify	Specify	If "other" is indicated, specify the precipitating factor.	Text	FATEST	FATEST where FACAT = "PRECIPITATING FACTORS" and FAOBJ = "HYPOGLYCEMIC EVENT"
HTG_CMCAT	50	What is the category for the concomitant medication?	Concomitant Medication Category	Record the concomitant medication category, if not pre-printed on the CRF.	Text	CMCAT				HYPO TREATMENT	Prompt		Yes
HTG_CMYN	51	Was any treatment given for the hypoglycemic event?	Any Treatment	Indicate if the subject took any treatment for the hypoglycemic event. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes			radio
HTG_DRINK_CMOCCUR	52	Did the subject take drink?	Drink	Indicate if drink was taken by checking Yes or No.	Text	CMOCCUR	CMOCCUR where CMTRT = "DRINK" and CMCAT = "HYPO TREATMENT" and CMPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HTG_FOOD_CMOCCUR	53	Did the subject take food?	Food	Indicate if food was taken by selecting Yes or No.	Text	CMOCCUR	CMOCCUR where CMTRT = "FOOD" and CMCAT = "HYPO TREATMENT" and CMPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HTG_GLUCTAB_CMOCCUR	54	Did the subject take glucose tablets?	Glucose Tablets	Indicate if glucose tablets were taken by selecting Yes or No.	Text	CMOCCUR	CMOCCUR where CMTRT = "GLUCOSE TABLETS" and CMCAT = "HYPO TREATMENT" and CMPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HTG_GLUCINJ_CMOCCUR	55	Did the subject take a glucagon injection?	Glucagon Injection	Indicate if glucagon injection was taken by selecting Yes or No.	Text	CMOCCUR	CMOCCUR where CMTRT = "GLUCAGON INJECTION" and CMCAT = "HYPO TREATMENT" and CMPRESP = "Y"	(NY)	No; Yes		Prompt	radio
HTG_IVGLUC_CMOCCUR	56	Did the subject take intravenous glucose?	Intravenous Glucose	Indicate if intravenous glucose was taken by selecting Yes or No.	Text	CMOCCUR	CMOCCUR where CMTRT = "INTRAVENOUS GLUCOSE" and CMCAT = "HYPO TREATMENT" and CMPRESP = "Y"	(NY)	No; Yes		Prompt	radio
TRTADMIN_FACAT	57	What is the category?	Category	Record the FA category, if not pre-printed on the CRF.	Text	FACAT				TREATMENT ADMINISTRATION	Prompt		Yes
TRTADMIN_FAOBJ	58	N/A	N/A	N/A	Text	FAOBJ	FAOBJ where FACAT = "TREATMENT ADMINISTRATION"			HYPOGLYCEMIC EVENT	Prompt		Yes
TRTADMIN_TXASSIST_FAORRES	59	If treatment was given, indicate if assistance was needed?	Need for Assistance	Indicate the investigator's assessment of the subject's need for assistance.	Text	FAORRES	FAORRES where FATESTCD = "TXASSIST" and FATEST = "Treatment Assistance" and FACAT = "TREATMENT ADMINISTRATION" and FAOBJ = "HYPOGLYCEMIC EVENT"		None - Subject Treated Self; Subject was Capable of Treating Self, but Received Assistance; Subject was Not Capable of Treating Self and Required Assistance			radio

For another way to represent data collected using the CE domain, see the CDISC Therapeutic Area Data Standards User Guide for Diabetes v1.0 Section 3.3.2, Example 5 (available at https://www.cdisc.org/standards/therapeutic-areas/diabetes).

8.2.4 DS - Disposition

Description/Overview for the CDASHIG DS - Disposition Domain

The DS domain includes disposition events and protocol milestones (e.g., informed consent obtained, randomized).

Specification for the CDASHIG DS - Disposition Domain

Disposition Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	DS	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Events	DS	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	DS	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	DS	N/A	N/A	4	DSCAT	Category for Disposition Event	A categorization of the disposition events which is used to distinguish between disposition events, protocol milestones, and other events.	What was the category of the disposition?	[Disposition Category]	Char	HR	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	DSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DSCAT)	N/A	This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. This is used to distinguish a DISPOSITION EVENT, a PROTOCOL MILESTONE, or an OTHER EVENT.
Events	DS	N/A	N/A	5	DSSCAT	Subcategory for Disposition Event	A sub-division of the DSCAT values based on user- defined characteristics.	What was the subcategory of the disposition?	[Disposition Subcategory]; NULL	Char	O	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	DSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. DSSCAT can only be used if there is an DSCAT with a and it must be a subcategorization of the Disposition event.
Events	DS	N/A	N/A	6	EPOCH	Epoch	Trial epoch (e.g., DOUBLE BLIND, SINGLE BLIND, TREATMENT, SCREENING, RUN IN) for which subject disposition is being collected.	What is the trial period for this disposition event?	Trial Period	Char	R/C	Check the [epoch, or insert more appropriate wording] for which disposition is being recorded.	EPOCH	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EPOCH)	N/A	If disposition events are collected more than once in the study, EPOCH may be needed to differentiate them. Typically, the trial epoch will be preprinted on the CRF as the title of the page; however, some companies have a standard CRF module that includes a pick-list of epochs. See SDTMIG for further information regarding EPOCH. EPOCH would only be populated for disposition event and not for protocol milestones.
Events	DS	N/A	N/A	7	DSDECOD	Standardized Disposition Term	The standardized terminology of the disposition term that describes whether a subject completed the study or a portion of a study (epoch) or the reason they did not complete.	What was the subject's status (at the EPOCH/study specific time frame)?	Status (at the EPOCH/study specific time frame)	Char	R/C	Document the subject's status at [insert text corresponding to the selected trial epoch/study specific time frame]. If the subject discontinued prematurely, record the primary reason for discontinuation.	DSDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. Both DSDECOD and DSTERM must be populated in the SDTM-based datasets. If DSTERM was collected as an "Other, Specify" free text, populate DSTERM with the free text and populate DSDECOD with the sponsor-defined standardized text. If DSDECOD was collected with no free text, populate DSTERM and DSDECOD in the SDTM-based dataset with the DSDECOD value that was collected.	(NCOMPLT)	N/A	DSDECOD can be used as the standardized coded list with DSTERM used to capture any "Specify, Other" information, or DSDECOD can be used on its own. For Sponsor- and/or study-specific reasons for discontinuation, it is recommended that these reasons be preprinted on the CRF, as subcategories of the appropriate standardized DSDECOD item. However, it is recommended to limit the use of sponsor and study- specific reasons in order to promote consistent use of terminology and hence permit the combination of data across multiple sponsors. Either DSTERM or DSDECOD must be on the CRF. Both may be used if DSTERM is used as a "Specify, Other" field.
Events	DS	N/A	N/A	8	DSTERM	Reported Term for the Disposition Event	The verbatim or prespecified name of the event. The reported or prespecified name for how a subject completed the study or a portion of a study (epoch) or the reason they did not complete.	What was the subject's status?; If [DSDECOD], specify	[Status]; [Specify]	Char	R/C	Document the subject's status at [insert text corresponding to the selected trial epoch]. If the subject discontinued prematurely, record the primary reason for discontinuation. (Or, if used with a DECOD list), if Other is selected from the Status list, provide the verbatim reason.	DSTERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variables DSDECOD and DSTERM must be populated in SDTM. If DSTERM was collected as an "Other, Specify" free text, populate the SDTMIG variable DSTERM with the free text and populate DSDECOD with the sponsor-defined standardized text. If DSDECOD was collected with no free text, populate DSTERM and DSDECOD in the SDTM-based dataset with the DSDECOD value that was collected.	N/A	N/A	If used with a DECOD list, free text description of the subject's "Other" status. DSTERM is the verbatim term for subject status when Other is selected from the DSDECOD code list. This field would only be used with the Prompt and Completion Instructions provided as an Specify, Other field in conjunction with DSDECOD. DSTERM may be used by itself when no code list is provided for DSDECOD on the CRF. Either DSTERM or DSDECOD must be on the CRF. DSTERM is required in the SDTM-based dataset.
Events	DS	N/A	N/A	9	DSSTDAT	Disposition Event Start Date	The date of the specified protocol milestone (e.g., informed consent, randomization) or disposition event (e.g., study completion or discontinuation), represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the [protocol milestone/disposition event/other event name] date?	[Protocol Milestone/Disposition Event/Other Event Name] Date	Char	R/C	Record the date of [protocol milestone/disposition event] as defined in the protocol and/or CRF Completion Instructions using this format (DD- MON-YYYY).	DSSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable DSSTDTC in ISO 8601 format.	N/A	N/A	Define in the protocol and/or CRF completion instructions the criteria for completion of each protocol milestone or disposition event for which a disposition CRF will be provided. Only collect the date of each protocol milestone or disposition event once. For example, if the date of the last dose is defined to mark the end of the Treatment Phase epoch, and is collected on the Exposure form, then this field would not be collected on the Disposition CRF module. If not collected elsewhere, this field should be collected on the Disposition CRF module.
Events	DS	N/A	N/A	10	DSSTTIM	Disposition Event Start Time	The time of the specified protocol milestone (e.g., informed consent, randomization) or disposition event (e.g., study completion or discontinuation), represented in an unambiguous time format (e.g., hh:mm:ss).	What was the [protocol milestone/disposition event/other event name] time?	[Protocol Milestone/Disposition Event/Other Event Name] Time	Char	O	Record the time (as complete as possible) that the subject completed the study or portion of the study as defined in the protocol and/or CRF Completion Instructions. If the subject did not complete the study or portion of the study, record the time (as complete as possible) as defined in the protocol and/or CRF Completion Instructions.	DSSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable DSSTDTC in ISO 8601 format.	N/A	N/A	Define in the protocol and/or CRF completion instructions the criteria for completion of each epoch for which a disposition CRF will be provided. Define also the date of completion or discontinuation. Collecting the time of completion or discontinuation is only appropriate if it can be realistically determined and if there is a 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.
Events	DS	N/A	N/A	11	DTHDAT	Death Date	Date of death for any subject who died.	What [is/was] the subject's date of death?	Death Date	Char	O	Record the date of death	DM.DTHDTC	This field does not map directly to an SDTMIG variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DTHDTC in ISO 8601 format.	N/A	N/A	The CDASH model defines Death Date as a timing variable; this is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the sponsor, but should only be collected once. The SDTMIG variable DTHDTC is mapped to the DM domain during the SDTM submission dataset creation process. The SDTMIG variable DM.DTHFLG is not a CDASH variable, but it is typically populated during the SDTM submission dataset creation process. Death Date may be mapped to other SDTM domains (e.g., DS) as deemed appropriate by the sponsor.
Events	DS	N/A	N/A	12	DSUNBLND	Unblinded	An indication the subject's treatment information was revealed to any unauthorized site personnel during the trial.	Was (study) treatment unblinded by the site?	Unblinded	Char	O	Record "Yes" if the subject's treatment assignment was unblinded/unmasked intentionally due to an AE, or unintentionally for other reasons (e.g., an administrative action) during the subject's blinded/masked treatment. Record the primary reason for discontinuation if the unblinding resulted in the subject discontinuing the trial prematurely.	DSTERM; DSDECOD	This does not map directly to an SDTM variable. If the CDASH field DSUNBLIND="Y", then the SDTMIG variables DSDECOD and DSTERM="TREATMENT UNBLINDED" and DSCAT ="OTHER EVENT". If DSUNBLIND="N", then the CRF should be annotated to indicate that this value is NOT SUBMITTED.	(NY)	N/A	There may be multiple rows in the SDTM DS dataset to represent this information, each with the appropriate DSCAT values. One row could indicate the treatment was unblinded using DSCAT="OTHER EVENT" and another row could indicate the status of the subject at the end of participation in the trial using DSCAT= "DISPOSITION". If DSUNBLND is "Yes" and information was collected about the reason for the unblinding, populate DSCAT with "OTHER EVENT" and the SDTMIG variables DSTERM with the free text and DSDECOD with the sponsor-defined standardized text (e.g., TREATMENT UNBLINDED). If DSUNBLND is "Yes", and the unblinding also resulted in the subject discontinuing the trial prematurely, populate DSCAT with "DISPOSTION" and use the SDTM IG variables DSTERM and DSDECOD to capture the applicable discontinuation details. If the unblinding occurred due to an Adverse Event, DSTERM contains the text of the AE, and in the AE domain the SDTMIG variable AEACNOTH "Were any other actions taken in response to this adverse event?" may include text of "Treatment Unblinded". DSUNBLND may also be used to document intentional unblinding at a protocol defined point in the trial.
Events	DS	N/A	N/A	13	DSCONT	Subject Continue	The plan for subject continuation to the next phase of the study or another study at the time of completion of the CRF.	Will the subject continue?	Subject Continue	Char	O	Record if the subject will be continuing to [the next phase of this study/related study] (sponsor to specify as appropriate).	SUPPDS.QVAL	This information could be submitted in a SUPPDS dataset as the value of SUPPDS.QVAL when SUPPDS.QNAM= "DSCONT" and SUPPDS.QLABEL="Subject Continue". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Sponsors should specify the next phase of the study or the related study on the CRF. Typically this is a prompt question to aid in monitoring and data cleaning, and usually not submitted in a SUPPDS dataset.
Events	DS	N/A	N/A	14	DSNEXT	Next EPOCH	Identifies the study epoch or new study in which the subject will participate.	What is the next [epoch/period/study/trial] the subject will [continue to/enter/enroll]?	Next [Epoch/Period/Study/Trial]	Char	O	Record the planned subsequent [study epoch/study] in which the subject intends to participate.	N/A	Sponsor-defined SDTMIG mapping.	N/A	N/A	Sponsors should specify the next phase of the study or the related study on the CRF. The data are to be used to aid in monitoring and data cleaning. No specific SDTM-based dataset mapping rules are provided since the mapping depends on the situation (next epoch or next trial). Per sponsor decision, plans to enter the next epoch within a study may be included in the SDTM submission datasets (e.g., SE). Actual subject entry into the next study is submitted as part of Trial Design datasets of that study.

Assumptions for the CDASHIG DS - Disposition Domain

1. Sponsors may choose which disposition events and milestones to collect for a study. A milestone is a protocol-specified “point in time” that is not assigned to an epoch. A disposition event describes whether a subject completed the study or portion of a study (epoch), or the reason they did not complete. A sponsor may collect 1 disposition event for the trial as a whole, or they may collect disposition for each epoch of the trial.

2. Disposition data may be collected on a form dedicated to disposition data, or it may be collected across several forms that also contain data that are not DS. When disposition data are collected on forms also containing data that are not DS, the disposition should be mapped to the appropriate DS SDTMIG variable (e.g., DSCAT, DSSTDTC, DSTERM, DSDECOD). The same disposition data should not be collected on both domain-specific forms and on a disposition form.

a. The CDASHIG DS domain does not specify where to collect protocol milestones within the CRF. Protocol milestones may be included in convenient places in the CRF. For example, Informed Consent Date or Randomization Date may be collected on the same CRF page as demographics data and mapped for submission to the SDTMIG DS domain.

b. The CDASH Model allows for collection of the Date of Death to be collected on any CRF deemed appropriate by the sponsor and mapped for submission to the SDTMIG DS domain or the Date of Death may be collected as part of a Disposition form. Consideration should be given to design the CRF to collect the Date of Death only once in a study.

3. Controlled Terminology (NCOMPLT) is focused on disposition events, and is used when DSCAT is "DISPOSITION EVENT". Because the complete list of controlled terminology may not be appropriate, sponsors may choose to include only subsets of CT on the CRF. The choices that appear for a DS Event are dependent upon the event itself, and the contents of the list can vary if data are collected for multiple epochs in a study. For example, "Non-Compliance with Study Drug" and "Lack of Efficacy” are not applicable choices prior to the start of treatment; "Failure to Meet Randomization Criteria" is an applicable choice only for the epoch that immediately follows the date of subject's randomization.

4. If DSUNBLND is "Yes", and the unblinding/unmasking resulted in the subject discontinuing the trial prematurely, DSTERM and DSDECOD capture the applicable details. If the unblinding/unmasking occurred due to an adverse event, DSTERM contains the text of the AE, and the AE “Were any other actions taken in response to this adverse event?” (AEACNOTH [optional]) free text may include text of “Treatment Unblinded”. DSUNBLND may also be used to document intentional unblinding at a protocol defined point in the trial.

5. DSCONT and DSNEXT data are used to aid in monitoring and data cleaning. Because the responses are about future plans, the validity of the responses cannot be ascertained until the subject enters the subsequent epoch or new study.

Example CRFs for the CDASHIG DS - Disposition Domain

Example 1

Title: Informed Consent



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Value	SDTMIG Target Mapping	Controlled Terminology Code List Name	CRF Implementation Notes	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DSCAT	1	What was the category of the disposition?	Disposition Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	DSCAT	DSCAT="PROTOCOL MILESTONE" where DSDECOD and DSTERM="INFORMED CONSENT OBTAINED"	(DSCAT)	Refer to the SDTMIG for guidelines for assigning DSCAT, DSTERM, and DSDECOD for events considered Protocol Milestones/		PROTOCOL MILESTONE	prompt		Yes
DSSTDAT	2	What was the Informed Consent date?	Informed Consent Date	Record the date of informed consent as defined in the protocol and/or CRF Completion Instructions using this format (DD- MON-YYYY).	Date	DSSTDTC						qtext
DSSTTIM	3	What was the Informed Consent time?	Informed Consent Time	Record the time (as complete as possible) of informed consent as defined in the protocol and/or CRF Completion Instructions.	Time	DSSTDTC						qtext

Example 2

In this example, the Disposition CRF simply collects whether or not the subject completed the study, so there is only 1 record per subject.

Title: Study Disposition



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Value	SDTMIG Target Mapping	Controlled Terminology Code List Name	CRF Implementation Notes	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DSCAT	1	What was the category of the disposition?	Disposition Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	DSCAT		(DSCAT)			DISPOSITION EVENT	prompt		Yes
DSDECOD	2	What was the subject's status?	Status	Document the subject's status at study completion. If the subject discontinued prematurely, record the primary reason for discontinuation.	Text	DSDECOD		(NCOMPLT)	The Controlled Terminology (NCOMPLT) is focused on disposition events, and is used when DSCAT is "DISPOSITION EVENT".	COMPLETED; ADVERSE EVENT; DEATH; DISEASE RELAPSE; LACK OF EFFICACY; LOST TO FOLLOW-UP; NON-COMPLIANCE WITH STUDY DRUG; PHYSICIAN DECISION; PREGNANCY; PROGRESSIVE DISEASE; PROTOCOL DEVIATION; RECOVERY; SITE TERMINATED BY SPONSOR; STUDY TERMINATED BY SPONSOR; TECHNICAL PROBLEMS; WITHDRAWAL BY PARENT/GUARDIAN; WITHDRAWAL BY SUBJECT			radio
DSTERM	3	If adverse event, specify	Specify	If Adverse Event is selected from the Status list, provide the verbatim reason.	Text	DSTERM			If DSTERM was collected as an adverse event, Specify", populate the SDTMIG variable DSTERM with the free text and populate DSDECOD with the standardized text from (NCOMPLT).			prompt
DSSTDAT	4	What was the study completion/discontinuation date?	Study Completion/Discontinuation Date	Record the date that the subject completed the study using this format (DD-MON-YYYY). If the subject did not complete the study, record the date that the subject discontinued.	Date	DSSTDTC
DSSTTIM	5	What was the study completion/discontinuation time?	Study Completion/Discontinuation Time	Record the time (as complete as possible) that the subject completed the study. If the subject did not complete the study, record the time (as complete as possible) that the subject discontinued.	Time	DSSTDTC

Example 3

In this example, the Disposition CRF collects multiple disposition events at different time points in the study as indicated by the trial period (epoch).

Title: Trial Period Disposition



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Value	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DSCAT	1	What was the category of the disposition?	Disposition Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	DSCAT		(DSCAT)		DISPOSITION EVENT	prompt		Yes
EPOCH	2	What is the trial epoch for this disposition event?	Epoch	Select the trial epoch for which disposition is being recorded.	Text	EPOCH		(EPOCH)	INDUCTION TREATMENT; BLINDED TREATMENT; OPEN LABEL TREATMENT; FOLLOW-UP; LONG-TERM FOLLOW-UP		prompt	radio
DSSTDAT	3	What was the completion/discontinuation date?	Completion/Discontinuation Date	Record the date that the subject completed the study or trial period using this format (DD-MON- YYYY). If the subject did not complete the study or trial period, record the date that the subject discontinued.	Date	DSSTDTC
DSSTTIM	4	What was the completion/discontinuation time?	Completion/Discontinuation Time	Record the time (as complete as possible) that the subject completed the study or trial period as defined in the protocol. If the subject did not complete the study or trial period, record the time (as complete as possible).	Time	DSSTDTC
DSDECOD	5	What was the subject's status?	Status	Document the subject's status for the study or trial period. If the subject discontinued prematurely, record the primary reason for discontinuation.	Text	DSDECOD		(NCOMPLT)	COMPLETED; ADVERSE EVENT; DEATH; DISEASE RELAPSE; LACK OF EFFICACY; LOST TO FOLLOW-UP; NON-COMPLIANCE WITH STUDY DRUG; PHYSICIAN DECISION; PREGNANCY; PROGRESSIVE DISEASE; PROTOCOL DEVIATION; RECOVERY; SITE TERMINATED BY SPONSOR; STUDY TERMINATED BY SPONSOR; TECHNICAL PROBLEMS; WITHDRAWAL BY PARENT/GUARDIAN; WITHDRAWAL BY SUBJECT; OTHER			radio
DSTERM	6	If other, specify	Specify	If Adverse Event or Other is selected from the Status list, provide the verbatim reason.	Text	DSTERM					prompt
DSCONT	7	Will the subject continue?	Continue	Record if the subject will be continuing to the next trial period of this study.	Text	SUPPDS.QVAL	SUPPDS.QVAL when SUPPDS.QNAM= "DSCONT" and SUPPDS.QLABEL="Subject Continue".	(NY)	No; Yes			radio
DSNEXT	8	What is the next epoch the subject will continue to enter?	Next epoch	Record the planned subsequent trial epoch in which the subject intends to participate.	Text	N/A		(EPOCH)	BLINDED TREATMENT; OPEN LABEL TREATMENT; FOLLOW-UP; LONG-TERM FOLLOW-UP; NOT APPLICABLE

8.2.5 DV - Protocol Deviations

Description/Overview for the CDASHIG DV - Protocol Deviations Domain

The DV domain is intended to collect protocol deviations or violations that occur after enrollment. It is not intended to collect information about inclusion/exclusion criteria; that data should be collected in IE.

Considerations Regarding Usage of a Protocol Deviations CRF

Sponsors must employ a robust and systematic method for recording protocol deviations; this may include the use of a dedicated CRF for this purpose, or the intentional inclusion of data collection fields throughout the entire set of CRFs that will detect protocol deviations.

The DV domain metadata and example CRF were developed as a guide that sponsors could use for designing a Protocol Deviations CRF and associated database, should they choose to do so. See Appendix B, Glossary and Abbreviations, for definitions of Protocol Deviation and Protocol Violation are available.

Specification for the CDASHIG DV - Protocol Deviations Domain

Protocol Deviations Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	DV	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Events	DV	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted for the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	DV	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	DV	N/A	N/A	4	DVCAT	Category for Protocol Deviation	A grouping of topic- variable values based on user- defined characteristics.	What is the category of the protocol deviation?	[Protocol Deviation Category]; NULL	Char	O	Record the deviation category, if not preprinted on the CRF.	DVCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Events	DV	N/A	N/A	5	DVSCAT	Subcategory for Protocol Deviation	A sub-division of the DVCAT values based on user- defined characteristics.	What is the subcategory of the protocol deviation?	[Protocol Deviation Subcategory]; NULL	Char	O	Record the deviation event subcategory, if not preprinted on the CRF.	DVSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. DVSCAT can only be used if there is an DVCAT and it must be a subcategorization of DVCAT.
Events	DV	N/A	N/A	6	DVYN	Any Protocol Deviation	An indication whether or not there were any protocol deviations.	Were there any protocol deviations?	Any Deviations	Char	O	Enter Yes if a protocol deviation occurred and No if none occurred. Ensure that any adverse event which triggers a protocol deviation (e.g., concomitant medication use, newly discovered medical history) is noted in the respective CRF.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Events	DV	N/A	N/A	7	DVDECOD	Protocol Deviation Coded Term	The sponsor-defined standardized text for the name of the protocol deviation.	What was the (standardized) protocol deviation (term/(code)?	(Standardized) Protocol Deviation (Term)	Char	R/C	Record protocol deviations identified and/or select the appropriate code from the list of protocol deviation terms.	DVDECOD	Maps directly to the SDTMIG variable listed in the column with the heading "SDTMIG Targe".	N/A	N/A	DVTERM and DVDECOD may have the same value. If the CRF is collecting protocol deviations using a code list of responses, then DVDECOD should be used to store the code list response. Sponsors must use either DVDECOD or DVTERM on the CRF and in some cases, both may be used. For example, if the CRF collects "Specify, Other" or similar additional free text descriptions of code list items, then DVTERM should be used to store the detailed descriptive text
Events	DV	N/A	N/A	8	DVTERM	Protocol Deviation Term	The reported or prespecified name of the protocol deviation.	What was the protocol deviation term?	(Specify) Protocol Deviation	Char	R/C	Record the appropriate code from the list of protocol deviation terms.	DVTERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	DVTERM and DVDECOD may have the same value. If the CRF is collecting protocol deviations using a free text field, then DVTERM should be used to store the free text response. Sponsors may use either DVDECOD or DVTERM on the CRF, but a value in DVTERM is required in the SDTM-based datasets.
Events	DV	N/A	N/A	9	DVSTDAT	Deviation Start Date	The start date of deviation, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the protocol deviation start date?	Start Date	Char	O	Record the start date that the protocol deviation using this format (DD-MON- YYYY). This should be the start or occurrence of the protocol deviation and not the date it was discovered or reported.	DVSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable DVSTDTC in ISO 8601 format.	N/A	N/A	This may be derived if not collected on a CRF.
Events	DV	N/A	N/A	10	DVSTTIM	Deviation Start Time	The start time of the deviation, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the protocol deviation start time?	Start Time	Char	O	If appropriate, record the start time (as complete as possible) of the protocol deviation in an unambiguous time format (e.g.,., hh:mm:ss). This should be the start or occurrence of the protocol deviation and not the time it was discovered or reported.	DVSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable DVSTDTC in ISO 8601 format.	N/A	N/A	N/A
Events	DV	N/A	N/A	11	DVENDAT	Deviation End Date	The end date of the deviation ,represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the protocol deviation end date?	End Date	Char	O	Record the end date of the protocol deviation using this format (DD-MON- YYYY). This should be the date the protocol deviation stopped and not the date it was discovered or reported.	DVENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable DVENDTC in ISO 8601 format. N/A	N/A	N/A
Events	DV	N/A	N/A	12	DVENTIM	Deviation End Time	The end time of the deviation, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the protocol deviation end time?	End Time	Char	O	If appropriate, record the end time (as complete as possible) of the protocol deviation in an unambiguous time format (e.g., hh:mm:ss). This should be the time the protocol deviation stopped and not the time it was discovered or reported.	DVENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable DVENDTC in ISO 8601 format.	N/A	N/A	N/A
Events	DV	N/A	N/A	13	DVSPID	DV Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, the sponsor may insert instructions to ensure each record has a unique identifier.	DVSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record

Assumptions for the CDASHIG DV - Protocol Deviations Domain

If a sponsor decides to use a DV CRF, 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.

Example CRF for the CDASHIG DV - Protocol Deviations Domain

Example 1

Title: Protocol Deviations



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Value	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DVYN	1	Were there any protocol deviations?	Any Deviations	Enter Yes if a protocol deviation occurred and No if none occurred. Ensure that any adverse event which triggers a protocol deviation (e.g., concomitant medication use, newly discovered medical history) is noted on the respective CRF.	Text	N/A		(NY)	Yes; No
DVSPID	2	What is the protocol deviation identifier?	DV Number	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Text	DVSPID							Yes
DVDECOD	3	What was the protocol deviation?	Protocol Deviation	Record protocol deviations identified and/or select the appropriate code from the list of protocol deviation terms.	Text	DVDECOD			Informed Consent Not Obtained; Inclusion Criteria Not Met; Study Drug Non- Compliance; Randomization Error; Other
DVTERM	4	What was the protocol deviation term?	Specify Protocol Deviation	Record the protocol deviation if not listed above.	Text	DVTERM					Prompt
DVSTDAT	5	What was the protocol deviation start date?	Start Date	Record the start date for the protocol deviation using this format (DD-MON-YYYY). This should be the start or occurrence of the protocol deviation, not the date it was discovered or reported.	Date	DVSTDTC
DVENDAT	6	What was the protocol deviation end date?	End Date	Record the end date of the protocol deviation using this format (DD-MON-YYYY). This should be the date the protocol deviation stopped, not the date it was discovered or reported.	Date	DVENDTC

8.2.6 HO - Healthcare Encounters

Description/Overview for the CDASHIG HO - Healthcare Encounters Domain

The HO dataset includes inpatient and outpatient healthcare events (e.g., hospitalizations, nursing home stay, rehabilitation facility stays, medical practitioner office visits).

This domain is used to record information about the event (e.g., type of encounter, timing). Other data about any interventions administered or any findings measured, observed, or tested during the healthcare encounter should be collected for submission in those respective domains. For example:

• Information about imaging—for example, MRI or endoscopic retrograde cholangiopancreatography (ERCP), which is a combination of an upper GI endoscopy and x-ray—would be collected in the Procedures (PR) domain.

• Laboratory results would be reported in Lab Results (LB).

It may not be necessary to collect data for the HO domain if the planned reporting or analysis is about the interventions and/or findings data rather than to the number/types of encounters, the duration of encounters, and so on.

Assumptions for the CDASHIG HO - Healthcare Encounters Domain

Please refer to SDTMIG for Healthcare Encounters Domain Assumptions.

Specification for the CDASHIG HO - Healthcare Encounters Domain

Healthcare Encounters Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	HO	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Events	HO	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	HO	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	HO	N/A	N/A	4	HOYN	Any Healthcare Encounters	An indication whether or not there were any healthcare encounters.	Were there any healthcare encounters?	Any Healthcare Encounters	Char	O	Indicate if the subject experienced any healthcare encounters. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification if all other fields on the CRF were deliberately left blank.
Events	HO	N/A	N/A	5	HOCAT	Category for Healthcare Encounter	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the healthcare encounter?	[Healthcare Encounter Category]; NULL	Char	O	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	HOCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. Examples include HOSPITALIZATION and OUTPATIENT.
Events	HO	N/A	N/A	6	HOSCAT	Subcategory for Healthcare Encounter	A sub-division of the HOCAT values based on user-defined characteristics.	What was the subcategory of the healthcare encounter?	[Healthcare Encounter Subcategory]; NULL	Char	O	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	HOSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. HOSCAT can only be used if there is an HOCAT and it must be a subcategorization of HOCAT.
Events	HO	N/A	N/A	7	HOOCCUR	Healthcare Encounter Occurrence	An indication whether a health encounter occurred when information about the occurrence of a specific event is solicited.	Did the subject have [prespecified healthcare encounter term]?	[prespecified Healthcare Encounter Term]	Char	O	Indicate if [specific healthcare encounter/event topic] has occurred/is occurring by checking Yes or No.	HOOCCUR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	The CDASH variable HOOCCUR is used is used to report the occurrence of a prespecified healthcare encounter. HOOCCUR is not used if the healthcare encounters are collected on the CRF in a manner that requires a free-flow text response. The site should be able to indicate in a separate item (or system variable) that the question was not asked or answered.
Events	HO	N/A	N/A	8	HOPRESP	prespecified Healthcare Encounter	An indication that a specific event, or group of events, are prespecified on a CRF.	N/A	N/A	Char	O	N/A	HOPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	A hidden field on a CRF defaulted to "Y", or added during the SDTM- based dataset creation, when the healthcare encounter is prespecified. Null for spontaneously reported events. If a study collects both prespecified healthcare encounters as well as free-text events, the value of HOPRESP should be "Y" for all prespecified events and null for events reported as free-text. HOPRESP is a permissible field in SDTM and may be omitted from the SDTM-based dataset if all events were collected as free text.
Events	HO	N/A	N/A	9	HOREASND	Reason Healthcare Encounter Not Done	An explanation of why the data are not available.	What was the reason the data was not collected?	Reason Not Collected	Char	O	Provide the reason why the subject's Healthcare Encounters experience was not assessed.	HOREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor defined list (e.g., subject not asked) or entered as free text. When HOREASND is used, the SDTMIG variable HOSTAT should also be populated in the SDTM-based dataset.
Events	HO	N/A	N/A	10	HOSPID	HO Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	HOSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Events	HO	N/A	N/A	11	HOTERM	Reported Term for Healthcare Encounter	The reported or prespecified name of the healthcare encounter.	What was the healthcare encounter?; If [HODECOD], specify	[Healthcare Encounter]; [Specify]	Char	HR	Record the healthcare encounter or if used with a HODECOD list, "Other" specify.	HOTERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	If collected on the CRF, sponsors must use either HODECOD or HOTERM and in some cases, both may be used. If the CRF is collecting healthcare encounters using a standardized sponsor-defined code list (e.g., INPATIENT ER, ICU, SURGERY, GENERAL WARD, PROVIDER OFFICE - PRIVATE, PROVIDER OFFICE - HOSPITAL, GASTROENTEROLOGIST), then HODECOD may be used to store the code list response. If the CRF collects "Specify, Other" or similar additional free text descriptions of code list items, then HOTERM may be used to store the detailed descriptive text. If HOTERM is entered only as free text, HODECOD would be populated through the sponsor's coding process.
Events	HO	N/A	N/A	12	HODECOD	HO Standardized Term	The sponsor- defined standardized text description of HOTERM or the modified topic variable (HOMODIFY), if applicable.	What was the (standardized) healthcare encounter (term/code)?	(Standardized) Healthcare Encounter (Term)	Char	R/C	Select the healthcare encounter.	HODECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	If collected on the CRF, sponsors must use either HODECOD or HOTERM and in some cases, both may be used. If the CRF is collecting healthcare encounters using a standardized sponsor defined code list (e.g., INPATIENT ER, ICU, SURGERY, GENERAL WARD, PROVIDER OFFICE-PRIVATE, PROVIDER OFFICE-HOSPITAL, GASTROENTEROLOGIST), then HODECOD may be used to store the code list response. If the CRF collects "Specify, Other" or similar additional free text descriptions of code list items, then HOTERM may be used to store the detailed descriptive text. If HOTERM is entered only as free text, HODECOD would be populated through the sponsor's coding process.
Events	HO	N/A	N/A	13	HOSTDAT	Healthcare Encounter Start Date	The start date the healthcare encounter, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the [healthcare encounter/HOTERM] [start/admission] date?	[Start/Admission] Date	Char	O	Record the start date of the healthcare encounter (e.g., date of admission) using this format (DD- MON-YYYY).	HOSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable HOSTDTC in ISO 8601 format.	N/A	N/A	The preferred method is to collect a complete Start Date. Partial dates (e.g., providing year only, month and year only) may be acceptable.
Events	HO	N/A	N/A	14	HOSTTIM	Healthcare Encounter Start Time	The start time of the healthcare encounter, (e.g., time of admission) represented in an unambiguous time format (e.g., hh:mm:ss).	What was the [healthcare encounter/HOTERM] [start/admission] time?	[Start/Admission] Time	Char	O	Record the start time (as complete as possible ) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	HOSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable HOSTDTC in ISO 8601 format.	N/A	N/A	N/A
Events	HO	N/A	N/A	15	HOENDAT	Healthcare Encounter End Date	The end date of the healthcare encounter, (date of discharge) represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the [healthcare encounter/HOTERM] [end/discharge] date?	[End/Discharge] Date	Char	O	Record the end date of the healthcare encounter using this format (DD- MON-YYYY).	HOENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable HOENDTC in ISO 8601 format.	N/A	N/A	The preferred method is to collect a complete end date. Partial dates (e.g., providing year only, month and year only) may be acceptable.
Events	HO	N/A	N/A	16	HOENTIM	Healthcare Encounter End Time	The end time of the healthcare encounter, (date of discharge) represented in an unambiguous time format (e.g., hh:mm:ss).	What was the [healthcare encounter/HOTERM] [end/discharge] time?	[End/Discharge]Time	Char	O	Record the end time (as complete as possible) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	HOENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable HOENDTC in ISO 8601 format.	N/A	N/A	N/A
Events	HO	N/A	N/A	17	HOCDUR	Healthcare Encounter Collected Duration	Collected duration of the healthcare encounter.	What was the duration of the [healthcare encounter/HOTERM]?	Duration	Char	O	Provide the duration of the healthcare encounter.	HODUR	This does not map directly to an SDTMIG variable. For the SDTM-based dataset, concatenate the CDASH collected duration and collected duration unit and populate the SDTMIG variable HODUR in ISO 8601 Period format. Example: P1DT2H (for 1 day, 2 hours).	N/A	N/A	Collected duration of the healthcare encounter. Used only if collected on the CRF and not derived from the start and end date/times.
Events	HO	N/A	N/A	18	HOCDURU	HO Collected Duration Unit	Unit of the collected duration of the healthcare encounter. Used only if duration was collected on the CRF.	What was the duration unit of the [healthcare encounter/HOTERM]?	(Duration) Unit	Char	O	Select the appropriate duration unit of the healthcare encounter.	HODUR	This does not map directly to an SDTMIG variable. For the SDTM-based dataset, concatenate the CDASH collected duration and collected duration unit and populate the SDTMIG variable HODUR in ISO 8601 Period format. Example: P1DT2H (for 1 day, 2 hours).	(UNIT)	N/A	To ensure data quality, it is recommended that the appropriate duration unit(s) be preprinted on the (e)CRF. If only one unit is appropriate, no data entry would be required.
Events	HO	N/A	N/A	19	HOONGO	Ongoing Healthcare Encounter	Indication that the encounter is ongoing when no end date is provided.	Was the [healthcare encounter/HOTERM] ongoing(as of the[study-specific timepoint or period?	Ongoing as of the[study-specific timepoint or period]	Char	O	Record the healthcare encounter as ongoing ('Y') if it has not stopped at[at the timepoint defined by the study].	HOENRF; HOENRTPT	This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as HOENRF or HOENRTPT. When populating HOENRF, if the value of HOONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating HOENRTPT, if the value of HOONGO is "Y", the value of "ONGOING" may be used. When HOONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable HOENRF should be populated. When HOONGO is compared to any other time point, the SDTMIG variables HOENRTPT and HOENTPT should be used. Note: HOENRTPT must refer to a time point anchor described in HOENTPT.	(NY)	N/A	Completed to indicate that the healthcare encounter has not ended at the time of data collection. It is expected that every reported encounter has either an End Date or the Ongoing field is populated, but not both. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the End Date was deliberately left blank. Often used as a tick/checkbox. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.
Events	HO	N/A	N/A	20	HOREAS	Reason for the Healthcare Encounter	Denotes the reason for the healthcare encounter.	What was the reason for the [healthcare encounter/HOTERM]?	Reason for the Healthcare Encounter	Char	O	Provide the reason for the subject's Healthcare Encounters.	SUPPHO.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPHO dataset as the value of SUPPHO_QVAL where SUPPHO.QNAM ="HOREAS" and SUPPHO.QLABEL="Healthcare Encounter Reason". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	To ensure data quality, it is recommended that the sponsor develop controlled terminology (e.g., LACK OF EFFICACY, ADVERSE EVENT, CHEMOTHERAPY, PHYSICAL THERAPY, INDICATION UNDER STUDY, NOT INDICATION UNDER STUDY). The sponsor may, however choose to collect this as free text or as a combination of preprinted options and free text in the form of "Specify, Other".
Events	HO	N/A	N/A	21	HOAENO	Related Adverse Event ID	Identifier for the adverse event that precipitated this encounter.	What was the identifier for the adverse event(s), which precipitated the [healthcare encounter/HOTERM]?	Adverse Event Identifier	Char	O	Record the identifier for the adverse event that precipitated this encounter.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Adverse Events domain.	N/A	N/A	Intent is to establish a link between the healthcare encounter record and the AE that was the primary cause of the encounter. HOAENO can be used in RELREC to identify a relationship between records in HO dataset and records in the AE

Example CRF for the CDASHIG HO - Healthcare Encounters Domain

Example 1

This example shows the collection of admission date/time and discharge date/time for admission to hospitals and to rehabilitation facilities.

Title: Healthcare Encounters



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
HOCAT	1	What was the category of the healthcare encounter?	Healthcare Encounter Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	HOCAT				INPATIENT ENCOUNTERS	Prompt
HOSP_HOTERM	2	What was the healthcare encounter?	Healthcare Encounter	Record the healthcare encounter name.	Text	HOTERM				HOSPITAL	Prompt
HOSP_HOREASND	3	What was the reason the hospitalization data was not collected?	Reason Not Collected	Provide the reason why the subject's Healthcare Encounters experience was not assessed.	Text	HOREASND	HOREASND where HOTERM = "HOSPITAL"; HOSTAT = "NOT DONE" where HOTERM = "HOSPITAL" when value present		Not Asked; Subject Refused
HOSP_HOOCCUR	4	Did the subject have any hospitalizations?	Hospitalizations	Indicate if a hospitalization has occurred/is occurring by checking Yes or No.	Text	HOOCCUR	HOOCCUR where HOTERM = "HOSPITAL"	(NY)	Yes; No			Radio
HOSP_HOSTDAT	5	What was the hospitalization admission date?	Hospitalization Admission Date	Record the start date of the healthcare encounter (e.g., date of admission) using this format (DD-MON-YYYY).	Date	HOSTDTC	HOSTDTC where HOTERM = "HOSPITAL"				Prompt
HOSP_HOSTTIM	6	What was the hospitalization admission time?	Hospitalization Admission Time	Record the start time (as complete as possible) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	Time	HOSTDTC	HOSTDTC where HOTERM = "HOSPITAL"				Prompt
HOSP_HOONGO	7	Was the hospitalization ongoing?	Hospitalization Ongoing	Record the healthcare encounter as ongoing (Yes) if it has not ended at the time of data collection; the end date should be left blank.	Text	HOENRF; HOENRTPT	HOENRF where HOTERM = "HOSPITAL" / HOENRTPT where HOTERM = "HOSPITAL"	(NY)	Yes; No			Radio
HOSP_HOSP_HOENDAT	8	What was the hospitalization discharge date?	Hospitalization Discharge Date	Record the end date of the healthcare encounter using this format (DD-MON-YYYY).	Date	HOENDTC	HOENDTC where HOTERM = "HOSPITAL"				Prompt
HOSP_HOENTIM	9	What was the hospitalization discharge time?	Hospitalization Discharge Time	Record the end time (as complete as possible) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	Time	HOENDTC	HOENDTC where HOTERM = "HOSPITAL"				Prompt
REHAB_HOTERM	10	What was the healthcare encounter?	Healthcare Encounter	Record the healthcare encounter name.	Text	HOTERM				REHABILITATION FACILITY	Prompt
REHAB_HOREASND	11	What was the reason the rehabilitation facility data was not collected?	Reason Rehabilitation Facility Not Collected	Provide the reason why the subject's Healthcare Encounters experience was not assessed.	Text	HOREASND	HOREASND where HOTERM = "REHABILIATION FACILITY"; HOSTAT = "NOT DONE" where HOTERM = "REHABILIATION FACILITY" when value present		Not Asked; Subject Refused
REHAB_HOOCCUR	12	Did the subject have any rehabilitation facility admissions?	Rehabilitation Facility	Indicate if a rehabilitation facility admission has occurred/is occurring by checking Yes or No.	Text	HOOCCUR	HOOCCUR where HOTERM = "REHABILIATION FACILITY"	(NY)	Yes; No			Radio
REHAB_HOSTDAT	13	What was the rehabilitation facility admission date?	Rehabilitation Facility Admission Date	Record the start date of the healthcare encounter (e.g., date of admission) using this format (DD-MON-YYYY).	Date	HOSTDTC	HOSTDTC where HOTERM = "REHABILITATION FACILITY"				Prompt
REHAB_HOSTTIM	14	What was the rehabilitation facility admission time?	Rehabilitation Facility Admission Time	Record the start time (as complete as possible ) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	Time	HOSTDTC	HOSTDTC where HOTERM = "REHABILITATION FACILITY"				Prompt
REHAB_HOONGO	15	Was the rehabilitation facility admission ongoing?	Rehabilitation Facility Ongoing	Record the healthcare encounter as ongoing (Yes) if it has not ended at the time of data collection; the end date should be left blank.	Text	HOENRF; HOENRTPT	HOENRF where HOTERM = "REHABILITATION FACILITY" / HOENRTPT where HOTERM = "REHABILIATION FACILITY"	(NY)	Yes; No			Radio
REHAB_HOENDAT	16	What was the rehabilitation facility discharge date?	Rehabilitation Facility Discharge Date	Record the end date of the healthcare encounter using this format (DD-MON-YYYY).	Date	HOENDTC	HOENDTC where HOTERM = "REHABILITATION FACILITY"				Prompt
REHAB_HOENTIM	17	What was the rehabilitation facility discharge time?	Rehabilitation Facility Discharge Time	Record the end time (as complete as possible) of the healthcare encounter in an unambiguous time format (e.g., hh:mm:ss).	Time	HOENDTC	HOENDTC where HOTERM = "REHABILITATION FACILITY"				Prompt

8.2.7 MH - Medical History

Description/Overview for the CDASHIG MH - Medical History Domain

The MH dataset includes the subject's medical history at the start of the trial. The CDASH metadata tables contain the most common general medical history data collection fields. In cases where more indication- specific medical history is required by the protocol, sponsors should add fields as needed from the CDASH Events model.

Specification for the CDASHIG MH - Medical History Domain

Medical History Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Events	MH	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Events	MH	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Events	MH	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Events	MH	N/A	N/A	4	MHYN	Any Medical History Event	An indication whether or not there was any medical history to report.	Were any medical conditions or events reported?; Has the subject had any medical conditions or events?	Any Medical History	Char	O	Indicate if the subject experienced any medical conditions or events. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Events	MH	N/A	N/A	5	MHCAT	Category for Medical History	A grouping of topic- variable values based on user- defined characteristics.	What was the category of the medical history?	[Medical History Category]; NULL	Char	R/C	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	MHCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology (e.g., CARDIAC, GENERAL). This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. This would be used when specific medical history (e.g., disease under study details) is captured, in addition to the general medical history.
Events	MH	N/A	N/A	6	MHSCAT	Subcategory for Medical History	A sub-division of the MHCAT values based on user- defined characteristics.	What was the subcategory of the medical history?	[Medical History Subcategory]; NULL	Char	O	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	MHSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. Typically would be used when specific medical history (e.g., disease diagnosis) is captured, in addition to the general medical history. MHSCAT can only be used if there is an MHCAT and it must be a subcategorization of MHCAT.
Events	MH	N/A	N/A	7	MHDAT	Medical History Collection Date	The date on which the medical history was collected, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the date the medical history was collected?	Collection Date	Char	O	Record the date on which the Medical History was collected using this format (DD-MON- YYYY).	MHDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MHDTC in ISO 8601 format.	N/A	N/A	This should be a complete date. The date of collection may be determined from a collected visit date.
Events	MH	N/A	N/A	8	MHSPID	MH Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	MHSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile concomitant medications and/or procedure records with MH. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system. If CMMHNO or PRMHNO is used, this is the identifier to which CMMHNO or PRMHNO refers.
Events	MH	N/A	N/A	9	MHEVDTYP	Medical History Event Date Type	Specifies the aspect of the medical condition or event by which MHSTDTC and/or the MHENDTC is defined.	What was the medical history event date type?	Medical History Event Date Type	Char	O	The instructions depend upon the format of the CRF. Sponsors may pre- print these values on the CRF or use them as defaulted or hidden text.	SUPPMH.QVAL	This field does not map directly to an SDTM variable. This information could be submitted in a SUPPMH dataset as the value of SUPPMH.QVAL when SUPPMH.QNAM = "MHEVDTYP" and SUPPMH.QLABEL= "Medical History Event Date Type". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	The type of start/ and or end date (e.g., DIAGNOSIS, EPISODE, EXACERBATION, SYMPTOM ONSET). It is not related to the trial's condition. This date type cannot be a PRIMARY DIAGNOSIS, SECONDARY DIAGNOSIS since these terms do not define the date type.
Events	MH	N/A	N/A	10	MHTERM	Reported Term for the Medical History	The reported or prespecified name of the medical condition or event.	What is the medical condition or event term?	Medical History Term	Char	HR	Record all relevant medical conditions or events, as defined in the protocol. Record only 1 medical condition or event per line. Ensure that the medical conditions or events listed on the Medical History page do not meet any of the exclusion criteria.	MHTERM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsors should collect all relevant medical conditions or events, as defined in the protocol. It is a best practice for sponsors to collect all relevant history of surgeries or procedures using the associated diagnosis in the MH domain, while reporting relevant surgeries and procedures in the SDTM PR domain. Sponsors should provide instructions on how surgeries and procedures will be handled based on the protocol requirements. Information on prespecified surgeries, or procedures should be collected in the PR domain.
Events	MH	N/A	N/A	11	MHOCCUR	Medical History Occurrence	An indication whether a prespecified medical condition/event or a group of medical conditions/events occurred when information about the occurrence of a specific event is solicited.	Did the subject have [prespecified medical condition/event/group of medical conditions]; Is the [prespecified medical occurring]?	[Medical condition/Event]	Char	O	Indicate if [specific medical condition/event] has occurred/is occurring by checking Yes or No.	MHOCCUR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	MHOCCUR is used to report the occurrence of a prespecified medical conditions or events. MHOCCUR is not used if the medical conditions or events are collected on the CRF in a manner that requires spontaneously free- text response. The site should be able to indicate that the response was not asked or answered.
Events	MH	N/A	N/A	12	MHPRESP	Medical History Event prespecified	An indication that a specific event, or group of events, are prespecified on a CRF.	N/A	N/A	Char	O	N/A	MHPRESP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	A hidden field on a CRF defaulted to "Y", or added during the SDTM- based dataset creation when the medical condition or event is prespecified. Null for spontaneously reported events. If a study collects both prespecified medical history as well as free- text events, the value of MHPRESP should be "Y" for all prespecified events and null for medical conditions or events reported as free-text. MHPRESP is a permissible field in SDTM and may be omitted from the SDTM- based dataset if all events were collected as free text.
Events	MH	N/A	N/A	13	MHPRIOR	Prior Medical History Event	An indication whether the event occurred prior to study start.	Did the medical condition or event start prior to [MHSTTPT]?; Did the medical condition or event start prior to study start?	Prior to [MHSTTPT]; Prior to Study	Char	O	Check if the medical condition or event started [before the study].	MHSTRTPT; MHSTRF	This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as MHSTRF or MHSTRTPT. When populating MHSTRF, or MHSTRTPT, if the value of the CDASH field MHPRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When MHPRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable MHSTRF should be populated. When MHPRIOR is compared to another time point, the SDTMIG variables MHSTRTPT and MHSTTPT should be used. Note: MHSTRTPT must refer to the time point anchor described in MHSTTPT.	(NY)	N/A	Sponsors may collect this information rather than start dates. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.
Events	MH	N/A	N/A	14	MHONGO	Ongoing Medical History Event	Indication the medical condition or event is ongoing when no end date is provided.	Is the medical condition or event ongoing (as of the [study-specific timepoint or period])?	Ongoing (as of the [study-specific timepoint or period])	Char	O	Record the medical condition or event as ongoing ("Y") if it has not ended at the time of data collection. If the medical condition or event, is ongoing, the end date should be left blank.	MHENRF; MHENRTPT	This does not map directly to an SDTM variable. May be used to populate a value into an SDTMIG relative timing variable such as MHENRF or MHENRTPT. When populating MHENRF, if the value of MHONGO is "Y", the value of "DURING", "AFTER" or "DURING/AFTER" may be used. When populating MHENRTPT, if the value of MHONGO is "Y", the value of "ONGOING" may be used. When MHONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTMIG variable MHENRF should be populated. When MHONGO is compared to another time point, the SDTMIG variables MHENRTPT and MHENTPT should be used. Note: MHENRTPT must refer to a time point anchor described in MHENTPT.	(NY)	N/A	Completed to indicate that the condition has not resolved at the time of data collection. It is expected that every reported condition has either an End Date or the Ongoing field is populated, but not both. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.
Events	MH	N/A	N/A	15	MHCTRL	MH Disease or Symptom Under Control	Indication whether the medical condition or event is under control at the time of data collection.	Is the medical condition or event under control?	Medical Condition Under Control	Char	O	Select the most appropriate response.	SUPPMH.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMH dataset as the value of SUPPMH.QVAL where SUPPMH.QNAM ="MHCTRL" and SUPPMH.LABEL="Medical Condition Under Control". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	MHCTRL is not defined in the SDTMIG MH domain. If collected, it should be submitted in the SUPPMH dataset. If MHCTRL is collected, the sponsor must provide information on the relative timeframe. Generally, MHDAT is collected or determined using the visit date of the collection to indicate this is the subject's status at the time of data collection.
Events	MH	N/A	N/A	16	MHSTDAT	Medical History Event Start Date	The start date of medical history event or condition represented in an unambiguous date format (e.g., DD- MON-YYYY).	What [is/was] the [medical event or condition/category of the event] start date?	Start Date	Char	O	Record the start date of the medical event or condition using this format (DD-MON-YYYY).	MHSTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTMIG variable MHSTDTC in ISO 8601 format.	N/A	N/A	The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).
Events	MH	N/A	N/A	17	MHENDAT	Medical History Event End Date	The end date of medical history event or condition represented in an unambiguous date format (e.g., DD- MON-YYYY).	What[is/was] the[medical event or condition/category of the event] end date?	End Date	Char	O	Record the end date of the medical event or condition using this format (DD-MON-YYYY).	MHENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable MHENDTC in ISO 8601 format.	N/A	N/A	The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).
Events	MH	N/A	N/A	18	MHLOC	Medical History Event Location	A description of the anatomical location relevant for the medical condition or event.	What was the anatomical location of the medical condition or event?	Anatomical Location	Char	O	Indicate the anatomical location of the medical event or condition.	MHLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location (e.g., ARM for skin rash). Could be a defaulted or hidden field on the CRF for prespecified [MHTERM/Event Topic]. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF. LAT, DIR, PORTOT are used to further describe the anatomical location.
Events	MH	N/A	N/A	19	MHLAT	Medical History Event Laterality	Qualifier for anatomical location further detailing the side of the body relevant for the event.	What was the side of the anatomical location of the medical condition or event?	Side	Char	O	Record the side of the anatomical location of the medical event.	MHLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	MH	N/A	N/A	20	MHDIR	Medical History Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the medical condition or event?	Directionality	Char	O	Record the directionality of the anatomical location of the medical event.	MHDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	MH	N/A	N/A	21	MHPORTOT	MH Event Location Portion or Totality	Qualifier for anatomical location further detailing the distribution, which means arrangement of, apportioning of.	What was the portion or totality of the anatomical location of the of the medical condition or event?	Portion or Totality	Char	O	Indicate the portion or totality anatomical location of the medical event.	MHPORTOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Events	MH	N/A	N/A	22	MHMODIFY	MH Modified Reported Term	If the value for MHTERM is modified to facilitate coding, then MHMODIFY will contain the modified text.	N/A	N/A	Char	O	N/A	MHMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process.
Events	MH	N/A	N/A	23	MHDECOD	MH Dictionary- Derived Term	The dictionary text description of MHTERM or the modified topic variable (MH MODIFY), if applicable.	N/A	N/A	Char	O	N/A	MHDECOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the Define- XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This is typically not a data collection fieldthat will appear on the CRF.Sponsors will populate this through the coding process. Equivalent to the Preferred Term (PT in MedDRA).
Events	MH	N/A	N/A	24	MHLLT	Medical History Event Lowest Level Term	MedDRA Dictionary text description of the Lowest Level Term.	N/A	N/A	Char	O	N/A	MHLLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	25	MHLLTCD	MH Event Lowest Level Term Code	MedDRA Lowest Level Term code.	N/A	N/A	Num	O	N/A	MHLLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	26	MHPTCD	MH Event Preferred Term Code	MedDRA code for the Preferred Term.	N/A	N/A	Num	O	N/A	MHPTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	27	MHHLT	Medical History Event High Level Term	MedDRA text description of the High Level Term from the primary path.	N/A	N/A	Char	O	N/A	MHHLT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	28	MHHLTCD	MH Event High Level Term Code	MedDRA High Level Term code from the primary path.	N/A	N/A	Num	O	N/A	MHHLTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	29	MHHLGT	MH Event High Level Group Term	MedDRA text description of the High Level Group Term from the primary path.	N/A	N/A	Char	O	N/A	MHHLGT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	30	MHHLGTCD	MH Event High Level Group Term Code	MedDRA High Level Group Term code from the primary path.	N/A	N/A	Num	O	N/A	MHHLGTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	31	MHSOC	MH Event Primary System Organ Class	MedDRA Primary System Organ Class description associated with the event.	N/A	N/A	Char	O	N/A	MHSOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.
Events	MH	N/A	N/A	32	MHSOCCD	MH Event Primary System Organ Class Code	MedDRA code for the primary System Organ Class.	N/A	N/A	Num	O	N/A	MHSOCCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the dictionary name and version used to code utilizing the Define-XML external codelist attributes. Sponsors should include an Origin in the define metadata document to indicate that the data was "ASSIGNED".	N/A	N/A	This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This is applicable to items using MedDRA coding.

Assumptions for the CDASHIG MH - Medical History Domain

1. Medical History Collection Period

a. Sponsors should define the appropriate collection period for medical history in the protocol. The evaluation interval may be provided in the SDTMIG variable MHEVLINT or MHEVINTX. These intervals are not recorded by the investigator, but are populated by the sponsor in the SDTMIG MH dataset. These intervals may be preprinted on the CRF as instruction text.

2. Medical History Coding

a. Sponsors who code medical history should use appropriate dictionary variables for the coding. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml External Codelist attributes.

b. Coding using MedDRA, though not required by the FDA, is recommended by CDASH. Coding of medical history is recommended because it provides methodology to compare medical history to adverse events and facilitate the identification of unexpected safety concerns or potential relationships to past treatments. It is recommended that coding be done during the execution phase of a study rather than after it is completed, as this facilitates efficient resolution of any coding queries.

c. For uncoded medical history, a sponsor-defined categorization of medical history events is recommended. One approach is to use the MHCAT variable.

d. Coding variables are not a data collection field that will appear on the CRF itself; sponsors will populate this through the coding process. When MedDRA is used as the coding dictionary, the MedDRA coding variables are included in the SDTM dataset.

3. Date of Collection (DAT)

a. This is the date that the data was recorded, not the date that the condition started or the event occurred. The date of collection can be "derived" from the date of the visit.

4. Relative Timing Variables

a. The date of data collection in conjunction with a collected time point anchor date and the MHONGO CDASHIG fields would determine how the SDTMIG relative timing variables would be populated.

b. The MHONGO field does not map directly to an SDTMIG variable but it may be used to derive a value into an SDTMIG relative timing variable such as MHENRF or MHENRTPT. When populating MHENRF, if the MHONGO box is checked, a value of "DURING", "AFTER" or "DURING/AFTER" may be derived. When populating MHENRTPT, if the MHONGO box is checked, the value of "ONGOING" may be derived.
Note: MHENRTPT must refer to a "time point anchor" described in MHENTPT. See Section 3.7, Mapping Relative Times from Collection to Submissions, and SDTMIG v3.2 Section 4.1.4.7 for more information.

c. MHONGO is a special-use case of "Yes/No", where the question is usually presented as a single possible response of "Yes" when there is no applicable end date at time of collection. In this case, if the box is checked and the end date is blank, the desired SDTMIG relative timing variable can be derived according to note 4b. If the box is not checked (MHONGO is NULL) and an end date is present, no SDTMIG relative timing variable would be derived. MHONGO is only used to derive an appropriate SDTMIG relative timing variable and should not be submitted on its own in the MH or SUPPMH dataset. The purpose of collecting this field is to help with data cleaning and monitoring; this field provides further confirmation that the end date was deliberately left blank.

d. MHPRIOR can be added to this domain from the CDASH Model and used when the sponsor elects not to collect start dates (even partial dates) on the MH CRF. The sponsor would derive a value into an SDTMIG relative timing variable such as MHSTRF or MHSTRTPT. When populating MHSTRF, if the value of MHPRIOR is “Y”, the value of “BEFORE” may be derived. When populating MHSTRTPT, if the value of MHPRIOR is “Y”, the value of “BEFORE” may be derived. Note: MHSTRTPT must refer to a “time point anchor” as described in MHSTTPT.

5. Start and End Dates

a. Partial dates are commonly collected in MH when the subject does not remember the complete date of when a medical history condition started or ended. The sponsor may choose to capture a complete date or any variation thereof (e.g., month and year, year).

6. Non-standard Supplemental Qualifier Variables

a. Medical History Event Type (MHEVDTYP) is used to specify the aspect of the medical condition or event by which its start date is defined. This variable (MHEVDTYP) is only to be used in the MH domain. This variable is used when the CRF records "multiple" dates such as the date when the condition was diagnosed, when symptoms were first reported prior to diagnosis, when the subject had a relapse, or when the infection associated with the diagnosis was reported. Example values for MHEVDTYP include DIAGNOSIS, EPISODE, EXACERBATION and SYMPTOM ONSET..

b. Condition under control (MHCTRL) is used to indicate that the disease/symptoms are under control at the time of data collection. It is recommended that, because this non-standard variable (NSV) has an implied time frame, the sponsor should provide the MHDTC data in the SDTMIG MH domain when using this NSV. Refer to the CDASHIG Metadata Tables for detailed mapping instructions.

Example CRFs for the CDASHIG MH - Medical History Domain

Example 1

Title: Cirrhosis History



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
MHCAT	1	What was the category of the medical history?	Medical History Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	MHCAT				CIRRHOSIS HISTORY	Prompt		Yes
MHTERM	2	What is the medical condition or event term?	Medical History Term	Record all relevant medical conditions or events, as defined in the protocol. Record only one medical condition or event per line. Ensure that the medical conditions or events listed on the Medical History page do not meet any of the exclusion criteria.	Text	MHTERM				CIRRHOSIS	Prompt		Yes
MHPRESP	3	N/A	N/A	N/A	Text	MHPRESP		(NY)	Yes	Yes		radio	Yes
MHOCCUR	4	Did the subject have cirrhosis?	Cirrhosis	Indicate if cirrhosis has occurred/is occurring by checking Yes or No.	Text	MHOCCUR		(NY)	Yes; No			radio
MHSTDAT	5	What was the medical condition or event start date?	Start Date	Record the start date of the medical event or condition using this format (DD-MON-YYYY).	Date	MHSTDTC					Prompt
MHONGO	6	Is the medical condition or event ongoing?	Ongoing	Record the medical condition or event as ongoing (Yes) if it has not ended at the time of data collection; the end date should be left blank.	Text	MHENRF; MHENRTPT	MHENRF or MHENRTPT	(NY)	Yes; No		Prompt	radio
MHENDAT	7	What was the medical condition or event end date?	End Date	Record the end date of the medical event or condition using this format (DD-MON-YYYY).	Date	MHENDTC					Prompt

Example 2

Title: General Medical History



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
MHYN	1	Has the subject had any medical conditions or events?	Any Medical History	Indicate if the subject experienced any medical conditions or events. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	Yes; No			radio
MHCAT	2	What was the category of the medical history?	Medical History Category	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	Text	MHCAT				Sponsor Defined	prompt
MHSPID	3	What is the medical condition or event identifier?	MH Number	Sponsor-Defined CRF Completion Instructions	Text	MHSPID
MHTERM	4	What is the medical condition or event term?	Medical History Term	Record all relevant medical conditions or events, as defined in the protocol. Record only one medical condition or event per line. Ensure that the medical conditions or events listed on the Medical History page do not meet any of the exclusion criteria.	Text	MHTERM
MHSTDAT	5	What was the medical condition or event start date?	Start Date	Record the start date of the medical event or condition using this format (DD-MON-YYYY).	Date	MHSTDTC					prompt
MHONGO	6	Is the medical condition or event ongoing?	Ongoing	Record the medical condition or event as ongoing (Yes) if it has not ended at the time of data collection; the end date should be left blank.	Text	MHENRF/ MHENRTPT		(NY)	Yes; No			radio
MHENDAT	7	What was the medical condition or event end date?	End Date	Record the end date of the medical event or condition using this format (DD-MON-YYYY).	Date	MHENDTC					prompt

Example 3

Title: Psychiatric History: Symptom Start and Diagnosis Dates



8.3 Findings Class Domains

The Findings class includes CDASH domains that define collection standards for results from evaluations such as physical examinations, laboratory tests, electrocardiogram (ECG) testing, and responses to questionnaires.

8.3.1 General CDASH Assumptions for Findings Domains

1. CDASH --CAT and/or --SCAT are generally not entered on the CRF by sites. Implementers may prepopulate and display these category values to help sites understand what data should be recorded on the CRF. Implementers may also prepopulate hidden variables with the values assigned within their operational database. Categories and subcategories that are not collected and are self-evident from the protocol design are populated during the creation of the SDTM submission dataset.

2. CDASH --PERF

a. --PERF variables having the Question Text "[Were any/Was the] [--TEST/ topic] [measurement(s)/test(s) /examinations (s)/specimen(s) /sample(s) ] [performed/collected]?" are intended to assist in the cleaning of data and in confirming that there are no missing values. (Refer to CDASH Model v1.1 for more information on creating and using --PERF variables.)

b. --PERF may be used at the page, panel, or question level. --PERF may be used during the creation of the STDM submission datasets to derive a value into the SDTM variable --STAT. The implementer can use a combination of --CAT, --SCAT, with the --TESTCD= "--ALL" and --TEST= "" to represent what tests were not performed. Refer to the current SDTMIG for more information.

3. The CDASH variable --REASND is used with SDTM variable --STAT only. The value NOT DONE in -- STAT indicates that the findings test was not performed.

4. The CDASH --SPID variable may be populated by the sponsor's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This field may be populated by the sponsor's data collection system.

5. Date and Time Variables

a. CDASH variables (--DAT, --TIM) are used in Findings domains to collect the date or date and time that the test was done or performed. The SDTM --DTC variable contains either a date or date and time when a specimen is collected or the start date or start date and time when a specimen is collected over time.

b. Collecting the time is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the test was performed and the study design is such that it is important to know the time the test was performed with respect to dosing time.

c. Implementers must not use these elements to record a date that is the result of a test (e.g., date of last day on the job). The date of the last day on the job would be recorded in the CDASH variable -- ORRES. See SDTMIG v3.2 Section 4.1.4.9 for more information.

d. The date of collection of a test may be derived from the date of visit. If so, a separate date of observation field is not required to be present on the CRF.

6. Horizontal (Denormalized) and Vertical Data Structures (Normalized)

a. In the CDASHIG Metadata Table, many of the CDASH Findings Class Domains are presented in a normalized structure (1 record for each test) that is similar to the SDTM, even though many data management systems hold the data in a denormalized structure (1 variable for each test). When implementing CDASH in a denormalized structure, create variable names for the Findings --TEST and/or --TESTCD values. To do this, define the denormalized variable names using available CDISC Controlled Terminology for --TESTCD. Alternatively, CDASH variable names for data management systems allowing more than 8-character variable names can use CDASH variables using the following naming convention: <--TESTCD>_<-- SDTM variable name> where --TESTCD is the appropriate CT for the test code (e.g., DIABP_VSORRES, DIABP_VSLOC).

b. In the horizontal (denormalized) setting, SDTM variables such as --PERF, --LOC , --STAT may be collected once for the whole horizontal record and applying the value to all of the observations on that record, or they can be collected by test using the CDASH variable such as <--TESTCD>_--PERF. When SDTM submission datasets are created, any variables collected for the entire horizontal record must be mapped to each vertical record (as appropriate).

c. In the horizontal (denormalized) setting, an identifier (e.g., --GRPID) may be used to identify all -- TESTCD collected on the same record. This facilitates transformation from the CDASH horizontal setting to the SDTM vertical setting and creation of RELRECs.

7. Tests and Original Results

a. The value in --TEST cannot be longer than 40 characters. The corresponding codelist value for the short test name (at most 8 characters) must also be populated in the SDTM variable --TESTCD.

b. --TESTCD should be used to create a variable name and --TEST be used as the Prompt on the CRF. Both --TESTCD and --TEST are recommended for use in the operational database. See Section 5, Conformance to the CDASH Standard, for more details.

c. CDASH variable --ORRES is used to collect test results or findings in the original units in character format.

d. If the results are modified for coding, the --MODIFY variable contains any modified text.

e. If normal or reference ranges are collected for results, the CDASH variables --ORNRLO and -- ORNRHI and --NIND are used.

f. CDASH does not define the SDTM variable used to standardize the findings results (e.g., --STRESC, - -STRESN) or to standardize the normal/reference ranges (--STNRLO,--STNRHI, --STNRC). The standardization of the original findings results and normal/reference ranges is expected to be performed during the creation of the SDTM submission datasets. Extensive discussion on the standardization of findings results is provided in the SDTMIG.

8. Location Variables (--LOC, --LAT, --DIR, --PORTOT)

a. These variables are used to collect the location of the test. The SDTM acknowledges that the results themselves may not be at the same location as the test. This is a known issue with the SDTM.

b. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF. --LOC could be a defaulted or hidden field on the CRF.

9. CDASH uses the variables –ORRES, --RES, --DESC, and --RESOTH to collect results for the observation class findings. The variable pairs --RES/--DESC, and --RES/--RESOTH are often used when a finding result is collected using 2 CRF questions but is combined into a single row in the SDTM dataset. The variable --ORRES is used when the finding result is based on a single question, and is mapped directly to a single row in SDTM. CDASH suggests:

a. --ORRES variable is used when the finding result is collected using a single question. The result should map directly to the SDTM variable --ORRES.

b. --RES and --DESC are used when a question is asked to collect the finding result, with a follow-up question for a description of the finding. Typically, the question would be “Is the [normal/abnormal] or [absent/present]" with a follow-up question such as “What is the abnormality?” or “What is the finding that was observed?” --RES is used to collect whether the finding is normal/abnormal or absent/present and –DESC is used to collect the description of the finding. Typically, this data is modeled in the SDTM as described in the PE domain:

i. --ORRES result is normal/absent, or

ii. --ORRES is the actual abnormality/observed finding and the collected value abnormal/present are not represented.

c. --RES and --RESOTH are used when a question is asked that allows the selection of a prespecified finding, with a follow-up question to ask about the prespecified response "OTHER". Typically, the question would be "What is the result?" with a set of prespecified responses, including the choice “OTHER” with a follow-up question “Specify, Other”. --RES is used to collect the finding with prespecified responses, and --RESOTH is used to collect "Specify, Other". Typically, --RESOTH data is modeled in SDTM as --ORRES instead of the response "OTHER".

10. The Findings About Events and Intervention domains use the same root variables as the Findings domain with the addition of the --OBJ variable. The CDASHIG Metadata Table contains a generic FA domain.

It is assumed that implementers 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, or operating procedures) to Findings and Findings About domains.

8.3.2 DA - Drug Accountability

Description/Overview for the CDASHIG DA - Drug Accountability Domain

The CDASHIG DA domain is used to collect information about dispensing and returning of study treatment materials used in a clinical trial.

The SDTMIG separates drug accountability from the Exposure (EX) domain, which contains the data about the subjects' actual exposure to study treatment.

SDTMIG definitions:

• "Drug Accountability is for data regarding the accountability of study drug, such as information on receipt, dispensing, return, and packaging." See the current SDTMIG for more information.

• "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 comparators, and investigational products. Treatments that are not protocol-specified should be recorded in the Concomitant Medications (CM) domain. See the current SDTMIG for more information.

Care should be taken not to confuse drug accountability with study treatment compliance or study drug exposure. Comparing the amount dispensed to the subject and the amount returned by the subject does not necessarily mean the difference equates to the amount of treatment consumed by the subject or the subject's compliance with the treatment plan. For example, the subject could have dropped 2 tablets into the sink drain, which would not be reflected in the returned amount and could provide a false estimate of compliance.

Because the actual treatment name may not be known to the site at the time of dispensing or returning, the word treatment in the context of the CDASHIG DA domain refers to the identifier that references the treatment (e.g., Bottle A, Bottle B, Drug A, Drug B) rather than the actual (unblinded) treatment name.

The term dispensed refers to when the study treatment is provided to the subject, not when the subject uses or consumes the study treatment. The term returned refers to when the subject returns the unused study treatment to the investigational site.

In some cases sponsors may wish to link DA data to EX data. This may be accomplished by using the appropriate identifier variables and the relationship (RELREC) dataset as described in the SDTMIG.

This domain, which is in the Findings class, has been modeled in both normalized and denormalized structures to provide users with examples of how each structure could be implemented. Findings domains are typically represented in the vertical/normalized structure as this is usually the easiest and quickest way to collect, process, and clean the data. However, users may have system constraints that prevent them from collecting this data in the vertical/normalized manner. The horizontal/denormalized version provides the structure necessary to collect the variables in this manner.

Depending on the study design, the DA CRF/eCRF may not be required.

Specification for the CDASHIG DA - Drug Accountability Domain

Drug Accountability Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	DA	N/A	Horizontal- Generic	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	DA	N/A	Horizontal- Generic	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	DA	N/A	Horizontal- Generic	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	DA	N/A	Horizontal- Generic	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	DA	N/A	Horizontal- Generic	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable DADTC in ISO 8601 format.	N/A	N/A	The date the drug accountability assessments were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit, or the collection date can be included on the DA CRF using the date (DADAT) field.
Findings	DA	N/A	Horizontal- Generic	6	DAGRPID	Drug Accountability Group ID	A sponsor- defined identifier used to tie a block of related records in a single domain.	What is the test group identifier?	Test Group Identifier	Char	O	Record unique group identifier. Sponsor may insert additional instructions to ensure each record has a unique group identifier.	DAGRPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	It can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This group identifier ties together all the tests collected on this horizontal record. This field may be populated by the sponsor's data collection system.
Findings	DA	N/A	Horizontal- Generic	7	[DATESTCD]_DAPERF	Drug Accountability Performed	An indication whether or not a planned drug accountability assessment was performed.	Was [DATEST] collected?	[DATEST] Collected	Char	O	Indicate whether or not drug accountability was performed.	DASTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable DASTAT. If DAPERF="N", the value of DASTAT will be "NOT DONE". If DAPERF="Y", DASTAT should be null. A combination of SDTMIG variables ( e.g., DACAT and DASCAT, DATPT ) is used to indicate that multiple tests were not done. In this situation, the SDTM variable DATESTCD would be populated as DAALL and an appropriate test name (DATEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This general prompt question is used as a data management tool to verify that missing results are confirmed missing. This may be implemented for all tests collected on the same horizontal record or for each specific test. When mapped to SDTM, the value of DAPERF would apply to all tests on the same record. Use the CDASH variable [DATESTCD]_DAPERF when implemented on a specific test basis. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DA	N/A	Horizontal- Generic	8	[DATESTCD]_DACAT	DA Category of Assessment	A grouping of topic-variable values based on user-defined characteristics.	What was the type of treatment for which drug accountability was assessed?	Treatment Type	Char	O	Record the type of study treatment for which drug accountability is assessed (e.g., STUDY MEDICATION, RESCUE MEDICATION, COMPARATOR, PLACEBO).	DACAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. If the protocol allows dispensing different types of study treatment (e.g., study medication, rescue medication, run-in medication) the CRF can capture the type of treatment using DACAT. This may be preprinted on the CRF. If DACAT is not collected (e.g., it is self- evident from the protocol design), it could be populated during the SDTM-based dataset creation process. The value of DACAT would apply to all measurements on that record when mapped to SDTM. If needed, the CDASH variable [DATESTCD]_DACAT may be used to collect a category for each DATEST. See SDTMIG v3.2 Section 6.3.8.2 for examples on populating DACAT and DASCAT. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure
Findings	DA	N/A	Horizontal- Generic	9	[DATESTCD]_DASCAT	DA Subcategory of Assessment	A sub-division of the DACAT values based on user-defined characteristics.	What was the name of the treatment for which drug accountability was assessed?	[DATEST] Treatment Name	Char	O	Record the name of the study treatment dispensed (e.g., DRUG A, DRUG B, BOTTLE 1).	DASCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. If it is known at the time of data collection, the treatment name may be collected in DASCAT (with appropriate, but different than, DACAT grouping values). The value of DASCAT would apply to all measurements on that record when mapped to SDTM. If needed, the CDASH variable [DATESTCD]_DASCAT may be used to collect a category for each DATEST. See SDTMIG Section 6.3 for examples on populating DACAT and DASCAT. DASCAT can only be used if there is an DACAT and it must be a subcategorization of DACAT.
Findings	DA	N/A	Horizontal- Generic	10	[DATESTCD]_DAREFID	Drug Accountability Reference ID	An internal or external identifier such as treatment label identifier (e.g., kit number, bottle label, vial identifier).	What is the [DATEST] treatment label identifier?	[DSTEST] Treatment Label Identifier	Char	O	Record dispensed treatment label identifier.	DAREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in EX domain.	N/A	N/A	This packaging identifier (e.g., kit number, bottle label, vial identifier) may be collected in different ways (e.g., affixing label onto CRF, scanning a bar code). For some study dosing regimens, greater granularity for treatment identifiers may be needed. In this situation, sponsors may need to use additional variables. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DA	N/A	Horizontal- Generic	11	[DATESTCD]_DADAT	Drug Accountability Date of Assessment	The date the study treatment was dispensed or returned, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date [DATEST] drug accountability was assessed?	[DATEST] Date	Char	R/C	Record the date drug accountability was performed, using this format ( DD-MON-YYYY).	DADTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable DADTC in ISO 8601 format.	N/A	N/A	The date study treatment dispensed/returned should be recorded for each dispensation for a study with multiple periods or multiple products dispensed. A single date may be collected for all the observations when they are performed on the same date. The date of each observation can also be collected using a CDASH variable [DATESTCD]_DADAT. The date of the observation may be determined from a collected date of visit and in such cases a separate measurement date field is not required. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DA	N/A	Horizontal- Generic	12	[DATESTCD]_DAORRES	DA Assessment Result in Original Units	Result of the drug accountability assessment (e.g., actual amount).	What is the amount of the [DATEST] drug accountability assessment?	[DATEST] Amount	Char	HR	Record the result of the drug accountability assessment.	DAORRES; DATEST; DATESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. In addition to the SDTMIG variable DAORRES, create DATESTCD from the CDASH variable name and derive the value of DATEST from DATESTCD. The CDASH prompt may also contain the DATEST. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Each test may be collected using the CDASH variable [TESTCD] ( e.g., RETAMT) or [TESTCD]_DAORRES where TESTCD is the appropriate CT for the DA test code (e.g., RETAMT_DAORRES). For a study with multiple periods or multiple products dispensed, drug accountability amounts should be assessed for each dispensation and return. For the SDTM submission dataset, DAREFID should be used to link related records. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DA	N/A	Horizontal- Generic	13	[DATESTCD]_DAORRESU	DA Original Units	The unit of the result as originally received or collected.	What was the unit of the [DATEST] result?	[DATEST] Unit	Char	HR	Record or select the original units in which these data were collected, if not preprinted on CRF.	DAORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	(DAORRESU)	The unit should be preprinted on the CRF or a field provided on the CRF to capture it. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DA	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	DA	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	DA	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What is the subject identifier?	Subject	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	DA	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, see SDTM Table 2.2.4.
Findings	DA	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable DADTC in ISO 8601 format.	N/A	N/A	The date the drug accountability assessments were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit, or the collection date can be included on the DA CRF using the date (DADAT) field.
Findings	DA	N/A	N/A	6	DAPERF	Drug Accountability Performed	An indication whether or not a planned drug accountability assessment was performed.	Was drug accountability performed?	Drug Accountability Performed	Char	O	Indicate whether or not drug accountability was performed.	DASTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable DASTAT. If DAPERF="N", the value of DASTAT will be "NOT DONE". If DAPERF="Y", DASTAT should be null. A combination of SDTMIG variables ( e.g., DACAT and DASCAT, DATPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable DATESTCD would be populated as DAALL and an appropriate test name (DATEST) provided. See SDTMIG Section 4.1.5.1.2.	(NY)	N/A	This may be implemented on a CRF page level on a visit-by-visit basis. This general prompt question is used as a data management tool to verify that missing results are confirmed missing.
Findings	DA	N/A	N/A	7	DACAT	DA Category of Assessment	A grouping of topic-variable values based on user-defined characteristics.	What was the type of treatment for which drug accountability was assessed?	[Treatment Type]; NULL	Char	O	Record the type of treatment dispensed/returned.	DACAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. If the protocol allows dispensing different types of treatment (e.g., study medication, rescue medication, run-in medication) the CRF can capture the type of treatment using DACAT. This may be preprinted on the CRF. If DACAT is not collected (e.g., it is self- evident from the protocol design), it can be populated during the SDTM-based dataset creation process. See SDTMIG DA domain for examples on populating DACAT and DASCAT.
Findings	DA	N/A	N/A	8	DASCAT	DA Subcategory of Assessment	A sub-division of the DACAT values based on user-defined characteristics.	What was the name of the treatment for which drug accountability was assessed?	[Treatment Name]; NULL	Char	O	Record the name of the study treatment dispensed/returned (e.g., Bottle A, Bottle B).	DASCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. If it is known at the time of data collection, the treatment name may be collected in DASCAT (with appropriate, but different, than DACAT grouping values). See SDTMIG DA domain for examples on populating DACAT and DASCAT. DASCAT can only be used if there is an DACAT and it must be a subcategorization of DACAT.
Findings	DA	N/A	N/A	9	DADAT	Drug Accountability Date	The date the study treatment was dispensed or returned, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date the drug accountability assessment was performed?	Date	Char	R/C	Record the exact date the study treatment was (dispensed or returned), using this format (DD-MON- YYYY).	DADTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable DADTC in ISO 8601 format.	N/A	N/A	The date study treatment dispensed/returned should be recorded for each dispensation for a study with multiple periods or multiple products dispensed.
Findings	DA	N/A	N/A	10	DAREFID	Drug Accountability Reference ID	An internal or external identifier such as treatment label identifier (e.g., kit number, bottle label, vial identifier).	What was the treatment label identifier?	Treatment Label Identifier	Char	O	Record treatment label identifier.	DAREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	For the SDTM submission dataset, DAREFID should be used to tie together a block of related records and to link dispensed product to returned product. This packaging identifier (e.g., kit number, bottle label, vial identifier) may be collected in different ways (e.g., affixing label onto CRF, scanning a bar code). For some study dosing regimens, greater granularity for treatment identifiers may be needed. In this situation, sponsors may need to use additional identifier variables.
Findings	DA	N/A	N/A	11	DATEST	Name of Accountability Assessment	Descriptive name of the measurement or finding (e.g., dispensed, returned).	What was the drug accountability being assessed?	[Drug Accountability Test Name]	Char	HR	Record the name of the drug accountability assessment if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	DATEST; DATESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable DATESTCD may be determined from the value collected in the CDASH field DATEST. The SDTMIG variables DATESTCD and DATEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(DATEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Test can be included as the column header. For a study with multiple periods or multiple products dispensed, drug accountability amounts should be assessed for each dispensation.
Findings	DA	N/A	N/A	12	DAORRES	DA Assessment Result in Original Units	Result of the drug accountability assessment as originally dispensed or returned (e.g., actual amount).	What is the result of the drug accountability assessment?	Amount	Char	HR	Record the actual amount of treatment dispensed or returned.	DAORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	For a study with multiple periods or multiple products dispensed, drug accountability amounts should be assessed for each dispensation.
Findings	DA	N/A	N/A	13	DAORRESU	DA Original Units	The unit of the result as originally received or collected.	What was the unit?	Unit	Char	HR	Record or select the original units in which these data were collected, if not preprinted on CRF.	DAORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	(DAORRESU)	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.

Assumptions for the CDASHIG DA - Drug Accountability Domain

1. The DA domain is only needed if this information will be collected for the study.

2. There may need to be a clear understanding of how the drugs are identified (e.g., by subject, by masked ID) in order to set up data collection in a manner that makes sense. This is a cross-functional team issue that needs to be addressed early in planning, if applicable.

3. Drug accountability may be implemented for an entire study or on a visit-by-visit basis depending on the most logical approach for each protocol.

4. The DA panel can be used for studies that allow dispensing different types of study treatment (e.g., study medication, rescue medication, run-in medication) by using the DACAT variable to differentiate treatment types.

Example CRFs for the CDASHIG DA - Drug Accountability Domain

Example 1

This example shows normalized data collection for drug accountability information

Title: Study Drug Accountability



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DAPERF	1	Was drug accountability performed?	Drug Accountability Performed	Indicate whether or not drug accountability was performed.	Text	DASTAT	If "N" (No), then DASTAT = "NOT DONE" where DATESTCD = "DAALL". If "Y" (Yes), then NOT SUBMITTED.	(NY)	Yes; No
DACAT	2	What was the type of treatment for which drug accountability was assessed?	Treatment Type	Record the type of treatment dispensed/returned.	Text	DACAT				STUDY MEDICATION	Prompt
DASCAT	3	What was the name of the treatment for which drug accountability was assessed?	Treatment Name	Record the name of the study treatment dispensed/returned (e.g., Bottle A, Bottle B).	Text	DASCAT					Prompt
DADAT	4	What was the date the drug accountability assessment was performed?	Date	Record the exact date the study treatment was (dispensed or returned), using this format (DD- MON-YYYY).	Date	DADTC					Prompt
DAREFID	5	What was the treatment label identifier?	Treatment Label Identifier	Record treatment label identifier.	Text	DAREFID					Prompt
DATEST	6	What was the drug accountability being assessed?	Drug Accountability Test Name	Record the name of the drug accountability assessment if not prespecified on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	DATEST		(DATEST)	Dispensed Amount; Returned Amount
DAORRES	7	What is the result of the drug accountability assessment?	Amount	Record the actual amount of treatment dispensed or returned.	Text	DAORRES					Prompt
DAORRESU	8	What was the unit?	Unit	Record or select the original units in which these data were collected, if not preprinted on CRF.	Text	DAORRESU		(UNIT)	Bag Dosing Unit; Bottle Dosing Unit; Box Dosing Unit; Capsule Dosing Unit; Container Dosing Unit; Disk Dosing Unit; Gram; Milligram; Milliliter; Package Dosing Unit; Packet Dosing Unit; Patch Dosing Unit; Syringe Dosing Unit; Tablet Dosing Unit; Tube Dosing Unit; Vial Dosing Unit		Prompt

Example 2

This example shows denormalized data collection for drug accountability information.

Title: Study Treatment Accountability



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DISPAMT_DAPERF	1	Was dispensed amount collected?	Dispensed Amount Collected	Indicate whether or not dispensed drug accountability was performed.	Text	DASTAT	If N (No), then DASTAT = "NOT DONE" where DATESTCD = "DISPAMT". If Y (Yes), then NOT SUBMITTED.	(NY)	Yes; No
DISPAMT_DADAT	2	What was the date the drug accountability assessment was performed?	Date Dispensed	Record the exact date the study treatment was dispensed, using this format (DD-MON- YYYY).	Date	DADTC	DADTC where DATESTCD = "DISPAMT".
DISPAMT_DACAT	3	What was the type of treatment dispensed?	Treatment Type	Record the type of study treatment dispensed (e.g., STUDY MEDICATION, RESCUE MEDICATION, COMPARATOR, PLACEBO).	Text	DACAT				STUDY MEDICATION	Prompt		Yes
DISPAMT_DAREFID	4	What was the dispensed treatment label identifier?	Dispensed Treatment Label Identifier	Record dispensed treatment label identifier.	Text	DAREFID	DAREFID where DATESTCD = "DISPAMT".				Prompt
DISPAMT_DAORRES	5	What is the amount dispensed?	Dispensed Amount	Record the actual amount of study treatment dispensed.	Text	DAORRES; DATEST; DATESTCD	DAORRES where DATESTCD = "DISPAMT".				Prompt
DISPAMT_DAORRESU	6	What was the unit?	Unit	Record or select the original units in which these data were collected, if not preprinted on CRF.	Text	DAORRESU	DAORRESU where DATESTCD = "DISPAMT".	(UNIT)	Bag Dosing Unit; Bottle Dosing Unit; Box Dosing Unit; Capsule Dosing Unit; Container Dosing Unit; Disk Dosing Unit; Gram; Milligram; Milliliter; Package Dosing Unit; Packet Dosing Unit; Patch Dosing Unit; Syringe Dosing Unit; Tablet Dosing Unit; Tube Dosing Unit; Vial Dosing Unit		Prompt
RETAMT_DAPERF	7	Was returned amount collected?	Returned Amount Collected	Indicate whether or not returned drug accountability was performed.	Text	DASTAT	If N (No), then DASTAT = "NOT DONE" where DATESTCD = "RETAMT". If Y (Yes), then NOT SUBMITTED.	(NY)	Yes; No
RETAMT_DADAT	8	What was the date the drug accountability assessment was performed?	Date Returned	Record the exact date the study treatment was returned, using this format (DD-MON- YYYY).	Date	DADTC	DADTC where DATESTCD = "RETAMT".
RETAMT_DACAT	9	What was the type of treatment returned?	Treatment Type	Record the type of study treatment returned (e.g., STUDY MEDICATION, RESCUE MEDICATION, COMPARATOR, PLACEBO).	Text	DACAT				STUDY MEDICATION	Prompt		Yes
RETAMT_DAREFID	10	What was the returned treatment label identifier?	Returned Treatment Label Identifier	Record returned treatment label identifier.	Text	DAREFID	DAREFID where DATESTCD = "RETAMT".				Prompt
RETAMT_DAORRES	11	What is the amount returned?	Returned Amount	Record the actual amount of study treatment returned.	Text	DAORRES; DATEST; DATESTCD	DAORRES where DATESTCD = "RETAMT".				Prompt
RETAMT_DAORRESU	12	What was the unit?	Unit	Record or select the original units in which these data were collected, if not preprinted on CRF.	Text	DAORRESU	DAORRESU where DATESTCD = "RETAMT".	(UNIT)	Bag Dosing Unit; Bottle Dosing Unit; Box Dosing Unit; Capsule Dosing Unit; Container Dosing Unit; Disk Dosing Unit; Gram; Milligram; Milliliter; Package Dosing Unit; Packet Dosing Unit; Patch Dosing Unit; Syringe Dosing Unit; Tablet Dosing Unit; Tube Dosing Unit; Vial Dosing Unit		Prompt

8.3.3 DD - Death Details

Description/Overview for the CDASHIG DD - Death Details Domain

The DD domain is used to collect additional data that are typically collected when a death occurs, such as the official cause of death, when the death occurred, and whether it was witnessed.

This domain is not intended to replace or collate data collected on designated CRF pages such as Severe Adverse Event details in the AE domain, or details of disposition in the DS domain. Data on the DD domain may be linked to other domains that relate to death using the appropriate identifier variables and the related records (RELREC) dataset as described in the SDTMIG.

Specification for the CDASHIG DD - Death Details Domain

Death Details Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	DD	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	DD	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	DD	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	DD	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	DD	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable DDDTC in ISO 8601 format.	N/A	N/A	The date the death details assessments were reported can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit or the collection date can be included on the Death Detail CRF using the date (DDDAT) field.
Findings	DD	N/A	N/A	6	DDCAT	Category for Death Details	A grouping of topic-variable values based on user-defined characteristics.	What is the category of the death detail assessment?	[Death Detail Category]; NULL	Char	O	Record the death detail category, if not preprinted on the CRF.	DDCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer.
Findings	DD	N/A	N/A	7	DDSCAT	Subcategory for Death Details	A sub-division of the DDCAT values based on user-defined characteristics.	What is the subcategory of the death detail assessment?	[Death Detail Assessment Subcategory]; NULL	Char	O	Record the death detail subcategory, if not preprinted on the CRF.	DDSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header DDSCAT can only be used if there is an DDCAT and it must be a subcategorization of DDCAT.
Findings	DD	N/A	N/A	8	DDYN	Any Death Detail Results	General prompt question regarding whether or not any death details were available.	Were any death detail assessments collected?	Any Death Details	Char	O	Indicate if the death details are known. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification if all other fields on the CRF were deliberately left blank.
Findings	DD	N/A	N/A	9	DDDAT	Death Details Date of Collection	The date of collection, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date death detail assessments were collected?	Collection Date	Char	R/C	Record the date of collection using this format (DD- MON-YYYY).	DDDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable DDDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and, if so, a separate assessment date field is not required.
Findings	DD	N/A	N/A	10	DDSPID	Death Details Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	DDSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Since SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	DD	N/A	N/A	11	DTHDAT	Death Date	Date of death for any subject who died.	What was the subject's date of death?	Death Date	Char	O	Record the date of death.	DM.DTHDTC	This field does not map directly to an SDTMIG variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DTHDTC in ISO 8601 format.	N/A	N/A	The CDASH model defines Death Date as a timing variable; this is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor, but should only be collected once. The SDTMIG variable DTHDTC is mapped to the DM domain during the SDTM submission dataset creation process. The SDTMIG variable DM.DTHFLG is not a CDASH variable, but it is typically populated during the SDTM submission dataset creation process. Death Date may be mapped to other SDTM domains, as deemed appropriate by the sponsor (e.g., DS).
Findings	DD	N/A	N/A	12	DDTEST	Death Detail Assessment Name	Descriptive name for death details	What was the death detail assessment test name?	[Death Detail Assessment (Test Name]	Char	HR	Record the name of the death detail assessment if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	DDTEST; DDTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable DDTESTCD may be determined from the value collected in DDTEST. Both DDTESTCD and DDTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(DTHDX)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Test can be included as the column header.
Findings	DD	N/A	N/A	13	DDORRES	Death Details Result or Finding	Result of the death detail assessment, as originally received or collected.	What was the result of the death detail assessment?	(Result)	Char	HR	Record the death detail response.	DDORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	DD	N/A	N/A	14	DDEVAL	Death Details Evaluator	The role of the person who provided the information.	Who provided the death detail assessment information?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	DDEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted, or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	DD	N/A	Horizontal- Generic	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	DD	N/A	Horizontal- Generic	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted for the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	DD	N/A	Horizontal- Generic	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	DD	N/A	Horizontal- Generic	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to Study Data Tabulation Model, Table 2.2.4.
Findings	DD	N/A	Horizontal- Generic	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable DDDTC in ISO 8601 format.	N/A	N/A	The date the death details assessments were reported can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit or the collection date can be included on the Death Detail CRF using the date (DDDAT) field.
Findings	DD	N/A	Horizontal- Generic	6	DDYN	Any Death Detail Results	General prompt question regarding whether or not any death details were available.	Were any death detail assessments collected?	Any Death Detail Assessments	Char	O	Indicate if the death details are known. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification if all other fields on the CRF were deliberately left blank.
Findings	DD	N/A	Horizontal- Generic	7	DDCAT	Category for Death Details	A grouping of topic-variable values based on user defined characteristics.	What is the category of the death detail assessment?	[Death Detail Assessment Category]; NULL	Char	O	Record the death detail category, if not preprinted on the CRF.	DDCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	DD	N/A	Horizontal- Generic	8	DDSCAT	Subcategory for Death Details	A sub-division of the DDCAT values based on user defined characteristics.	What is the subcategory of the death detail assessment?	[Death Detail Assessment Subcategory]; NULL	Char	O	Record the death detail subcategory, if not preprinted on the CRF.	DDSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header DDSCAT can only be used if there is an DDCAT and it must be a subcategorization of DDCAT.
Findings	DD	N/A	Horizontal- Generic	9	[DTHDXCD]_DDDAT	Death Details Date of Collection	The date of collection represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date [DTHDX] assessment was collected?	[DTHDX] Date	Char	R/C	Record the date of collection using this format (DD- MON-YYYY).	DDDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable DDDTC in ISO 8601 format.	N/A	N/A	A single date may be collected for all death detail assessments when they are collected on the same date. The date of collection of each assessment can also be collected using a CDASH variable [DTHDXCD]_DDDAT. The date of the assessment may be determined from a collected date of visit and in such cases a separate assessment date field is not required.
Findings	DD	N/A	Horizontal- Generic	10	DTHDAT	Date of Death	Date of death for any subject who died.	What was the subject's date of death?	Death Date	Char	O	Record the date of death.	DM.DTHDTC	This field does not map directly to an SDTMIG variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DTHDTC in ISO 8601 format.	N/A	N/A	The CDASH model defines Death Date as a timing variable; this is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor, but should only be collected once. The SDTMIG variable DTHDTC is mapped to the DM domain during the SDTM submission dataset creation process. The SDTMIG variable DM.DTHFLG is not a CDASH variable, but it is typically populated during the SDTM submission dataset creation process. Death Date may be mapped to other SDTM domains, as deemed appropriate by the sponsor (e.g., DS).
Findings	DD	N/A	Horizontal- Generic	11	[DTHDXCD]_DDORRES	Death Details Result or Finding	Result of the death detail assessment, as originally received or collected.	What was the death detail assessment result?	Result	Char	HR	Record the death detail response.	DDORRES; DDTEST; DDTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. In addition to the SDTMIG variable DDORRES, create DDTESTCD from the CDASH variable name and determine the value of DDTEST from DDTESTCD. The CDASH prompt may also contain the DDTEST. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Each test may be collected using the CDASH variable [TESTCD] (e.g., PRCDTH) or [TESTCD]_DDORRES where TESTCD is the appropriate CT for the DD test code e.g., PRCDTH_DDORRES. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	DD	N/A	Horizontal- Generic	12	DDEVAL	Death Details Evaluator	The role of the person who provided the information.	Who provided the death detail assessment information?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	DDEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted, or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.

Assumptions for the CDASHIG DD - Death Details Domain

1. This domain captures information pertaining to the death of a subject, including the causes of death and findings of an autopsy directly related to the death itself (e.g., cause of death). If more than 1 cause of death is obtained, these may be separated into primary and secondary causes and/or other appropriate designations.

2. This domain is not intended to include the details describing the autopsy (e.g., who conducted the autopsy or when). Autopsy information should be handled as per recommendations in the Procedures (PR) domain.

3. An autopsy is a procedure from which there will usually be findings. Results of the autopsy not specific to the death itself will be represented in the appropriate Findings domain(s).

Example CRF for the CDASHIG DD - Death Details Domain

Example 1

Title: Death Details



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DDYN	1	Were any death detail assessments collected?	Any Death Detail Assessments	Indicate if the death details are known. If Yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	No; Yes
DDDAT	2	What was the date death detail assessments were collected?	Collection Date	Record the date of collection using this format (DD- MON-YYYY).	Date	DDDTC
DTHDAT	3	What was the subject’s date of death?	Death Date	Record the date of death.	Date	DM.DTHDTC					prompt
PRCDTH_DDORRES	4	What is the primary cause of death?	Result	Record the primary cause of death.	Text	DDORRES; DDTEST; DDTESTCD;	DDORRES WHERE DDTESTCD = "PRCDTH"
SECDTH_DDORRES	5	What is the secondary cause of death?	Result	Record the secondary cause of death, if applicable.	Text	DDORRES; DDTEST; DDTESTCD;	DDORRES WHERE DDTESTCD = "SECDTH"
LOCDTH_DDORRES	6	What is the location of death?	Result	Record the location of death.	Text	DDORRES; DDTEST; DDTESTCD;	DDORRES WHERE DDTESTCD = "LOCDTH"		Hospital; Out of Hospital-During Sleep; During Routine Activities
DDEVAL	7	Who provided the death detail assessment information?	[Evaluator/Reporter]	Select the role of the person who provided the evaluation.	Text	DDEVAL		(EVAL)	Adjudication Committee; Health Care Professional; Independent Assessor

8.3.4 EG - ECG Test Results

Description/Overview for the CDASHIG EG - ECG Test Results Domain

This section provides EG domain metadata for 3 different data collection 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, rather than recorded on the CRF. The accession number and date collected on the CRF can be used as an aid in reconciliation of the electronic data.



Scenario 2: Local Reading

In this scenario, subjects' ECGs are performed and analyzed, and then the results are recorded directly on the CRF.



Scenario 3: Central Reading with Investigator Assessment of Clinical Significance Assessment and/or Overall Interpretation

In this scenario, results are captured directly by an electronic device by a central vendor. The results are provided in an electronic file to the sponsor. In addition, the results are provided to the investigator for assessment of clinical significance for any abnormal values and that information is provided to the sponsor on the CRF.



Specification for the CDASHIG EG - ECG Test Results Domain

ECG Test Results Metadata Table

• Position of the Subject is provided as part of the electronic data.

• Position of the Subject is not pertinent to the protocol.

• The protocol specifies only one possible position and the sponsor does not feel there is significant risk of the sites performing the ECG with the subject in the wrong position.

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	EG	Central Reading	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	EG	Central Reading	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	EG	Central Reading	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/ Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	EG	Central Reading	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	EG	Central Reading	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	The date the ECG measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the ECG measurements at that visit, or the collection date can be included on the ECG CRF using the date (EGDAT) field.
Findings	EG	Central Reading	N/A	6	EGCAT	Category for ECG	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the ECG finding?	[ECG Category]; NULL	Char	O	Record the ECG finding category, if not preprinted on the CRF.	EGCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	EG	Central Reading	N/A	7	EGSCAT	Subcategory for ECG	A sub-division of the EGCAT values based on user-defined characteristics.	What was the subcategory of the ECG finding?	[ECG Subcategory]; NULL	Char	O	Record the ECG finding subcategory, if not preprinted on the CRF.	EGSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header EGSCAT can only be used if there is an EGCAT and it must be a subcategorization of EGCAT.
Findings	EG	Central Reading	N/A	8	EGPERF	ECG Performed	An indication whether or not a planned ECG measurement, series of ECG measurements, tests, or observations was performed	Was the ECG performed?	ECG Performed	Char	HR	Indicate whether or not an ECG or specific ECG test was done.	EGSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable EGSTAT. If the CDASH field EGPERF= "N", the value of EGSTAT will be "NOT DONE". If EGPERF = "Y", EGSTAT should be null. A combination of SDTMIG variables (e.g., EGCAT and EGSCAT, EGTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable EGTESTCD would be populated as EGALL and an appropriate test name (EGTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire ECG, or a specific ECG test basis. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	EG	Central Reading	N/A	9	EGREFID	ECG Reference ID	An internal or external identifier of the ECG (e.g., waveform number).	What was the (ECG) [reference identifier/accession number]?	(ECG) [Reference Identifier/Accession Number]	Char	O	Record the identifier number assigned.	EGREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer if this reference ID happens to be available to the site at the time of collection. It can also be used to link the clinical significance assessment to the proper record in the electronic data. (e.g., UUID for external waveform file, session number automatically generated by electronic equipment).
Findings	EG	Central Reading	N/A	10	EGMETHOD	Method of ECG Test	Method of the test or examination.	What was the method used for the ECG?	Method	Char	O	Record the method used for the ECG.	EGMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EGMETHOD)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One possible condition is the method used to collect or calculate the ECG data. If the protocol requires this type of information, then this question may be included to confirm that the method used matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: • Method of ECG is provided as part of the electronic data. • Method of ECG is not pertinent to the protocol. • The protocol specifies only one possible method for collecting ECG measurements and the sponsor does not feel there is significant risk of the sites performing the ECG using the incorrect method.
Findings	EG	Central Reading	N/A	11	EGPOS	ECG Position of Subject	The position of the subject during the ECG measurement.	What was the position of the subject during the ECG measurement?	Position	Char	O	Record the position of the subject during the ECG.	EGPOS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(POSITION)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One common condition is the subject's position. If the protocol requires this type of information, then this question may be included to confirm that the subject's position matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF:
Findings	EG	Central Reading	N/A	12	EGDAT	ECG Date	The date the ECG was performed, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the ECG?	ECG Date	Char	R/C	Record the date the ECG was done using this format (DD-MON-YYYY).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	EG	Central Reading	N/A	13	EGTPT	ECG Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the ECG measurement?	[Planned Time Point Name]	Char	R/C	Record the time point labels for when the ECG test should be taken, if not preprinted on the CRF.	EGTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. SDTMIG time point anchors EGTPTREF (text description) and EGRFTDTC (date/time) may be needed, as well as SDTMIG variables EGTPTNUM, EGELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	EG	Central Reading	N/A	14	EGTIM	ECG Time	Time of ECG, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time the ECG was collected?	ECG Time	Char	R/C	Record the time the ECG was done (as complete as possible).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on 1 day or when the timing in relationship to study treatment is required for analysis.
Findings	EG	Local Reading	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	EG	Local Reading	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	EG	Local Reading	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	EG	Local Reading	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	EG	Local Reading	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	The date the ECG measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the ECG measurements at that visit, or the collection date can be included on the ECG CRF using the date (EGDAT) field.
Findings	EG	Local Reading	N/A	6	EGCAT	Category for ECG	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the ECG finding?	[ECG Category]; NULL	Char	O	Record the ECG finding category, if not preprinted on the CRF.	EGCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	EG	Local Reading	N/A	7	EGSCAT	Subcategory for ECG	A sub-division of the EGCAT values based on user-defined characteristics.	What was the subcategory of the ECG finding?	[ECG Subcategory]; NULL	Char	O	Record the ECG finding subcategory, if not preprinted on the CRF.	EGSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header EGSCAT can only be used if there is an EGCAT and it must be a subcategorization of EGCAT.
Findings	EG	Local Reading	N/A	8	EGPERF	ECG Performed	An indication of whether or not a planned measurement, series of measurements, test, or observation was performed.	Was the ECG performed?	ECG Performed	Char	HR	Indicate whether or not ECG or specific ECG test was done.	EGSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable EGSTAT. If the CDASH field EGPERF="N", the value of EGSTAT will be "NOT DONE". If EGPERF="Y", EGSTAT should be null. A combination of SDTMIG variables ( e.g., EGCAT and EGSCAT, EGTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable EGTESTCD would be populated as EGALL and an appropriate test name (EGTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire ECG, or a specific ECG test basis. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	EG	Local Reading	N/A	9	EGMETHOD	Method of ECG Test	Method of the test or examination.	What was the method used for the ECG?	Method	Char	O	Record the method used for the ECG.	EGMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EGMETHOD)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One possible condition is the method used to collect or calculate the ECG data. If the protocol requires this type of information, then this question may be included to confirm that the method used matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: • Method of ECG is provided as part of the electronic data. • Method of ECG is not pertinent to the protocol. • The protocol specifies only one possible method for collecting ECG measurements and the sponsor does not feel there is significant risk of the sites performing the ECG using the incorrect method.
Findings	EG	Local Reading	N/A	10	EGPOS	ECG Position of Subject	The position of the subject during the ECG measurement.	What was the position of the subject during the ECG measurement?	Position	Char	O	Record the position of the subject during the ECG.	EGPOS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(POSITION)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One common condition is the subject's position). If the protocol requires this type of information, then this question may be included to confirm that the subject's position matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: • Position of the subject is provided as part of the electronic data. • Position of the subject is not pertinent to the protocol. • The protocol specifies only one possible position and the sponsor does not feel there is significant risk of the sites performing the ECG with the subject in the wrong position.
Findings	EG	Local Reading	N/A	11	EGDAT	Date of ECG	The date the ECG was performed, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the ECG?	ECG Date	Char	R/C	Record the date ECG was done using this format (DD-MON-YYYY).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	EG	Local Reading	N/A	12	EGTPT	ECG Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the ECG measurement?	[Planned Time Point Name]	Char	R/C	Record the time point labels for when the ECG test should be taken, if not preprinted on the CRF.	EGTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. SDTMIG time point anchors EGTPTREF (text description) and EGRFTDTC (date/time) may be needed, as well as SDTMIG variables EGTPTNUM, EGELTM.	N/A	N/A	Planned time point are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	EG	Local Reading	N/A	13	EGTIM	Time of ECG	Time of ECG, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time the ECG was collected?	ECG Time	Char	R/C	Record the time the ECG was done (as complete as possible).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on 1 day or when the timing in relationship to study treatment is required for analysis.
Findings	EG	Local Reading	N/A	14	EGTEST	ECG Test or Examination Name	Descriptive name of the measurement or finding.	What was the ECG test name?	[ECG Test Name]	Char	HR	Record the name of the ECG measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	EGTEST; EGTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable EGTESTCD may be determined from the value collected in EGTEST. The SDTMIG variables EGTESTCD and EGTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(EGTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	EG	Local Reading	N/A	15	EGORRES	ECG Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the ECG?	(Result)	Char	HR	Record test results, interpretations or findings.	EGORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	EG	Local Reading	N/A	16	EGORRESU	ECG Original Units	The unit of the result as originally received or collected.	What was the unit of the ECG results?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	EGORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	(EGORRESU)	May be included if quantitative results are recorded. Because units for quantitative ECG results are typically limited, units should be preprinted on the CRF with the associated test when possible, rather than having the sites record the units. This item is not necessary for qualitative results.
Findings	EG	Local Reading	N/A	17	EGCLSIG	ECG Clinical Significance	An indication whether the ECG results were clinically significant.	Was the ECG clinically significant?	Clinically Significant	Char	O	Record whether ECG results were clinically significant.	SUPPEG.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEG dataset as the value of SUPPEG.QVAL where SUPPEG.QNAM ="EGCLSIG" and SUPPEG.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Could apply to specific measurements or to overall interpretation.
Findings	EG	Central Reading with Investigator Assessment	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	EG	Central Reading with Investigator Assessment	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	EG	Central Reading with Investigator Assessment	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	EG	Central Reading with Investigator Assessment	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	EG	Central Reading with Investigator Assessment	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	The date the ECG measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the ECG measurements at that visit, or the collection date can be included on the ECG CRF using the date (EGDAT) field.
Findings	EG	Central Reading with Investigator Assessment	N/A	6	EGCAT	Category for ECG	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the ECG finding?	[ECG Category]; NULL	Char	O	Record the ECG finding category, if not preprinted on the CRF.	EGCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	EG	Central Reading with Investigator Assessment	N/A	7	EGSCAT	Subcategory for ECG	A sub-division of the EGCAT values based on user-defined characteristics.	What was the subcategory of the ECG finding?	[ECG Subcategory]; NULL	Char	O	Record the ECG finding subcategory, if not preprinted on the CRF.	EGSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header EGSCAT can only be used if there is an EGCAT and it must be a subcategorization of EGCAT.
Findings	EG	Central Reading with Investigator Assessment	N/A	8	EGPERF	ECG Performed	An indication of whether or not a planned measurement, series of measurements, test, or observation was performed.	Was the ECG performed?	ECG Performed	Char	HR	Indicate whether or not an ECG or specific ECG test was done.	EGSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable EGSTAT. If the CDASH field EGPERF="N", the value of EGSTAT will be "NOT DONE". If EGPERF="Y", EGSTAT should be null. A combination of SDTMIG variables (e.g., EGCAT and EGSCAT, EGTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable EGTESTCD would be populated as EGALL and an appropriate test name (EGTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire ECG, or a specific ECG test basis. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	EG	Central Reading with Investigator Assessment	N/A	9	EGREFID	ECG Reference ID	An internal or external identifier of the ECG (e.g., waveform number).	What was the (ECG) [reference identifier/accession number]?	(ECG) [Reference Identifier/Accession Number]	Char	O	Record the identifier number assigned.	EGREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer if this reference ID happens to be available to the site at the time of collection. (e.g., Universally Unique Identifier (UUID) for external waveform file, session number automatically generated by electronic equipment). This can also be used to link.
Findings	EG	Central Reading with Investigator Assessment	N/A	10	EGMETHOD	Method of ECG Test	Method of the test or examination.	What was the method used for the ECG?	Method	Char	O	Record the method used for the ECG.	EGMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EGMETHOD)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One possible condition is the method used to collect or calculate the ECG data. If the protocol requires this type of information, then this question may be included to confirm that the method used matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: • Method of ECG is provided as part of the electronic data. • Method of ECG is not pertinent to the protocol. • The protocol specifies only one possible method for collecting ECG measurements and the sponsor does not feel there is significant risk of the sites performing the ECG using the incorrect method.
Findings	EG	Central Reading with Investigator Assessment	N/A	11	EGPOS	ECG Position of Subject	The position of the subject during the ECG measurement.	What was the position of the subject during the ECG measurement?	Position	Char	O	Record the position of the subject during the ECG.	EGPOS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(POSITION)	N/A	Results may be affected by whether conditions for ECG as specified in the protocol were properly met. One common condition is the subject's position. If the protocol requires this type of information, then this question may be included to confirm that the subject's position matches the protocol. The following are examples of when it is not necessary to collect these data on the CRF: • Position of the subject is provided as part of the electronic data. • Position of the subject is not pertinent to the protocol. • The protocol specifies only one possible position and the sponsor does not feel there is significant risk of the sites performing the ECG with the subject in the wrong position.
Findings	EG	Central Reading with Investigator Assessment	N/A	12	EGDAT	Date of ECG	The date the ECG was performed, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the ECG?	ECG Date	Char	R/C	Record the date ECG was done using this format (DD-MON-YYYY).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	EG	Central Reading with Investigator Assessment	N/A	13	EGTPT	ECG Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the ECG measurement?	[Planned Time Point Name]	Char	R/C	Record the time point labels for when the ECG test should be taken, if not preprinted on the CRF.	EGTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. SDTMIG time point anchors EGTPTREF (text description) and EGRFTDTC (date/time) may be needed, as well as SDTMIG variables EGTPTNUM, EGELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	EG	Central Reading with Investigator Assessment	N/A	14	EGTIM	Time of ECG	Time of ECG, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time the ECG was collected?	ECG Time	Char	R/C	Record the time the ECG was done (as complete as possible).	EGDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable EGDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on 1 day or when the timing in relationship to study treatment is required for analysis.
Findings	EG	Central Reading with Investigator Assessment	N/A	15	EGEVAL	ECG Evaluator	The role of the person who provided the evaluation.	Who provided the information?; Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	EGEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	EG	Central Reading with Investigator Assessment	N/A	16	INTP_EGORRES	ECG Interpretation	Overall interpretation of the result of the measurement or finding.	What was the interpretation of the ECG?	Interpretation	Char	O	Record overall interpretations of the ECG.	EGORRES	This does not map directly to an SDTM variable. For the SDTM submission dataset, the recorded interpretation is populated into the SDTMIG variable EGORRES where EGTEST= "Interpretation", and EGTESTCD="INTP".	N/A	N/A	The overall interpretation of an ECG is mapped into the appropriate SDTM test and result variables. See the SDTMIG EG Domain for details.
Findings	EG	Central Reading with Investigator Assessment	N/A	17	EGCLSIG	ECG Clinical Significance	An indication whether the ECG results were clinically significant.	Was the ECG clinically significant?	Clinically Significant	Char	HR	Record whether ECG results were clinically significant.	SUPPEG.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPEG dataset as the value of SUPPEG.QVAL where SUPPEG.QNAM = "EGCLSIG" and SUPPEG.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Could apply to specific measurements or to overall interpretation. In this scenario, clinical significance could be provided by the investigator.
Findings	EG	Central Reading with Investigator Assessment	N/A	18	EGMHNO	Related Medical History Event ID	Identifier for the medical history event that was reported as a clinically significant ECG finding.	What was the identifier for the medical history event that was reported as a clinically significant ECG finding?	Medical History Event Identifier	Char	O	Identifier for the medical history event that was reported as a clinically significant ECG finding.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Medical History domain.	N/A	N/A	Intent is to establish a link between the clinically significant ECG finding and the medical history event that was reported. EGMHNO can be used in RELREC to identify a relationship between records in EG dataset and records in the MH dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Findings	EG	Central Reading with Investigator Assessment	N/A	19	EGAENO	Related Adverse Event ID	Identifier for the adverse event that was reported as a clinically significant ECG finding.	What was the identifier for the adverse event(s) that was reported as a clinically significant ECG finding?	Adverse Event Identifier	Char	O	Identifier for the adverse event that was the reported as a clinically significant ECG finding.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the Adverse Events domain.	N/A	N/A	Intent is to establish a link between the clinically significant ECG finding and the AE that was reported. EGAENO can be used to identify a relationship between records in EG dataset and records in the AE dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.

Assumptions for the CDASHIG EG - ECG Test Results Domain

1. The ECG tests that should be collected are not specified by CDASH; this is a medical and scientific decision that should be based on the needs of the protocol.

2. Sponsors should decide which scenario is appropriate for each protocol.

3. As required or defined by the study protocol, clinically significant results may need to be reported on the Adverse Event CRF.

4. As required or defined by the study protocol, changes that are worsening may need to be reported on the AE CRF.

5. As depicted in Scenario 3, where CRF includes site assessment of clinical significance and/or overall interpretation, results are returned to the sites, and the sites complete a CRF page of clinical significance for any abnormal/unexpected values and/or record an overall interpretation of the results. As in Scenario 1, the actual testing results are transmitted electronically, but the CRF includes data necessary to identify and rate the clinical significance of the abnormal results.

Example CRFs for the CDASHIG EG - ECG Test Results Domain

Example 1

This example shows a CRF that collects electrocardiogram data utilizing a central reader.

Title: ECG Central Reading



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
EGPERF	1	Was the ECG performed?	ECG Performed	Indicate whether or not an ECG or specific ECG test was done.	Text	EGSTAT		(NY)	No; Yes
EGREFID	2	What was the ECG reference identifier?	ECG Reference Identifier	Record the ECG reference identifier.	Text	EGREFID
EGDAT	3	What was date of the ECG?	ECG Date	Record the date ECG was done using this format (DD-MON-YYYY).	Date	EGDTC
EGTIM	4	What was the time the ECG was collected?	ECG Time	Record the time the ECG was done (as complete as possible).	Time	EGDTC
EGMETHOD	5	What was the method used for the ECG?	ECG Method	Record the the method used for the ECG.	Text	EGMETHOD		(EGMETHOD)	6-Lead Standard; 12-Lead Standard
EGPOS	6	What was the position of the subject during the ECG measurement?	Position	Record the position of the subject during the ECG.	Text	EGPOS		(POSITION)	Supine; Sitting

Example 2

This example shows a CRF that collects electrocardiogram data utilizing a local reader.

Title: ECG Local Reading



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
EGPERF	1	Was the ECG performed?	ECG Performed	Indicate whether or not an ECG or specific ECG test was done.	Text	EGSTAT		(NY)	No; Yes
EGMETHOD	2	What was the method used for the ECG?	Method	Record the method used for the ECG.	Text	EGMETHOD		(EGMETHOD)	6 Lead Standard; 8 Lead Standard; 10 Lead Standard; 12 Lead Standard
EGPOS	3	What was the position of the subject during the ECG measurement?	Position	Record the position of the subject during the ECG.	Text	EGPOS		(POSITION)	Supine; Sitting
EGDAT	4	What was date of the ECG?	ECG Date	Record the date ECG was done using this format (DD-MON-YYYY).	Date	EGDTC
EGTPT	5	What was the planned time point of the ECG measurement?	[Planned Time Point Name]	Record the time point labels for when the ECG test should be taken, if not pre-printed on the CRF.	Text	EGTPT
EGTIM	6	What was the time the ECG was collected?	ECG Time	Record the time the ECG was done (as complete as possible).	Time	EGDTC
PRAG_EGORRES	7	What was the Aggregate PR Interval?	PR Interval, Aggregate	Record the test result.	Text	EGORRES	EGORRES WHERE EGTESTCD = "PRAG"
PRAG_EGORRESU	8	What was the unit of the Aggregate PR Interval?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	EGORRES	EGORRESU WHERE EGTESTCD = "PRAG"	(Unit)		msecs
QRSAG_EGORRES	9	What was the Aggregate QRS Duration?	QRS Duration, Aggregate	Record the test result.	Text	EGORRES	EGORRES WHERE EGTESTCD = "QRSAG"
QRSAG_EGORRESU	10	What was the unit of the Aggregate QRS Duration?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	EGORRES	EGORRESU WHERE EGTESTCD = "QRSAG"	(Unit)		msecs
QTAG_EGORRES	11	What was the Aggregate QT Interval?	QT Interval, Aggregate	Record the test result.	Text	EGORRES	EGORRES WHERE EGTESTCD = "QTAG"
QTAG_EGORRESU	12	What was the unit of the Aggregate QT Interval result?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	EGORRES	EGORRESU WHERE EGTESTCD = "QTAG"	(Unit)		msecs
QTCAAG_EGORRES	13	What was the Aggregate QTca Interval?	QTca Interval, Aggregate	Record the test result.	Text	EGORRES	EGORRES WHERE EGTESTCD = "QTCAAG"
QTCAAG_EGORRESU	14	What was the unit of the Aggregate QTca Interval?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	EGORRES	EGORRESU WHERE EGTESTCD = "QTCAAG"	(Unit)		msecs
INTP_EGORRES	15	What was the overall interpretation of the ECG?	Interpretation	Record the the test result.	Text	EGORRES	EGORRES WHERE EGTESTCD = "INTP"	(NORMABNM)	Normal; Abnormal
EGCLSIG	16	Was the ECG clinically significant?	Clinically Significant	Record whether ECG results were clinically significant.	Text	SUPPEG.QVAL	SUPPEG.QVAL where SUPPEG.QNAM = "EGCLSIG" and SUPPEG.QLABEL= "Clinically Significant" and EGTEST= "INTP"	(NY)	Yes;No

Example 3

This example shows a CRF that collects electrocardiogram data which is centrally processed.

Title: ECG Central Reading with Investigator Assessment



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
EGPERF	1	Was the ECG performed?	ECG Performed	Indicate whether or not an ECG or specific ECG test was done.	Text	EGSTAT		(NY)	No; Yes
EGMETHOD	4	What was the method used for the ECG?	Method	Record the method used for the ECG.	Text	EGMETHOD		(EGMETHOD)	6 Lead Standard; 8 Lead Standard; 10 Lead Standard; 12 Lead Standard
EGPOS	5	What was the position of the subject during ECG measurement?	Position	Record the position of the subject during the ECG.	Text	EGPOS		(POSITION)	Supine; Sitting
EGDAT	2	What was the ECG date?	ECG Date	Record the date ECG was done using this format (DD- MON-YYYY).	Date	EGDTC					PROMPT
EGTIM	3	What was the time the ECG was collected?	ECG Time	Record the time the ECG was done (as complete as possible).	Time	EGDTC					PROMPT
INTP_EGORRES	7	What was the interpretation of the ECG?	Interpretation	Record overall interpretations of the ECG.	Text	EGORRES	EGORRES WHERE EGTESTCD = "INTP"	(NORMABNM)	Normal; Abnormal
EGCLSIG	8	Was the ECG clinically significant?	Clinically Significant	Record whether ECG results were clinically significant.	Text	SUPPEG.QVAL	SUPPEG.QVAL where SUPPEG.QNAM ="EGCLSIG" and SUPPEG.QLABEL="Clinically Significant " where EGTEST="INTP"	(NY)	No; Yes

8.3.5 IE - Inclusion/Exclusion Criteria Not Met

Description/Overview for the CDASHIG IE - Inclusion/Exclusion Criteria Not Met Domain

The CDASHIG IE domain is recommended for collecting only inclusion/exclusion exceptions. In other words, those criteria that are "not met"; these are the data that are required to be in the SDTMIG IE domain. The CDASHIG IE domain is used to collect failures on or exceptions to the inclusion/exclusion criteria during the screening process before a subject is enrolled in a study. It is not intended to collect protocol deviations or violations that occur after enrollment; protocol deviations are collected using the DV domain.

The recommendation is that sites be given an entry criteria worksheet to be used for each subject to record the results of eligibility review. 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 criterion using a unique identifier, which can be easily recorded on the CRF if a subject does not meet that criterion. If criteria lists are numbered the same for both inclusion and exclusion criteria (e.g., inclusion 001-100, exclusion 001-100), then this identifier could include a means of identifying the TYPE of criterion (e.g., I001-I100, E001-E100). Alternatively, the criteria could be collected in 2 separate sections on the CRF labeled "Inclusion" and "Exclusion" and the output records could include the values of Inclusion or Exclusion on each record. These are only examples; an organization’s numbering scheme may be different, but some method that captures both the Inclusion or Exclusion category and the unique criterion identifier should be used.

The recommended collection method has been simplified to require the site to record a single "Y/N" value in the IEYN variable to indicate whether or not the subject met all of the criteria. If any criteria are not met, the site then records only those "unmet" criteria in the CRF. The result value for each unmet criterion may then be derived in the SDTMIG IE domain from the collection of the specific criterion that was not met. In other words, if the collected criterion is an inclusion criterion that was not met, the value of "N" can be derived into IEORRES and IESTRESC for that record in the SDTMIG IE domain. If it is an exclusion criterion, then "Y" can be derived into IEORRES and IESTRESC to indicate that the subject met the conditions for that exclusion record in IE.

The rationale for the recommended collection method is that what is being collected in the IE CRF is aligned with the data that would be in the SDTMIG IE domain.

This design allows criteria to change over the life of a study or project (e.g., when adaptive trial designs are used or protocol amendments result in changes to the inclusion or exclusion criteria). If inclusion/exclusion criteria were amended during the trial, then each complete set of criteria must be included in the TI domain. TIVERS is used to distinguish between the versions of the eligibility criteria.

CDASH recommends the use of uniquely numbered entry criteria within a study to manage effectively protocol changes and to facilitate both the collection and submission of IE data. See the current SDTMIG for more details. The Inclusion/Exclusion worksheet may need to be updated and re-numbered/re-lettered whenever a protocol amendment changes one or more criteria. For example, if new versions of a criterion have not been given new numbers, separate values of IETESTCD might be created by appending letters (e.g., INCL003A, INCL003B).

A field could be added to the CRF to capture the version number of the criteria being used; this can be mapped to the SDTMIG variable TI.TIVERS. This enables the retrieval of the full text of the criterion from the code used on the CRF.

Alternatively, an implementer may choose to include the full text of each criterion (IETEST) with a result field (IEORRES) in the CRF and request the site to record explicitly the "Y" or the "N" for each criterion, but only the recommended, simplified method is presented in the IE example CRF.

Specification for the CDASHIG IE - Inclusion/Exclusion Criteria Not Met Domain

Inclusion/Exclusion Criteria Not Met Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	IE	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	IE	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	IE	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	IE	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	IE	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable IEDTC in ISO 8601 format.	N/A	N/A	The date the inclusion and exclusion assessments were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit or the collection date can be included on the Inclusion/Exclusion CRF using the date (IEDAT) field.
Findings	IE	N/A	N/A	6	IEYN	Any Incl/Excl Criteria Findings	Indication whether the subject met all the eligibility requirements for this study at the time the subject was enrolled.	Were all eligibility criteria met?	Met Criteria	Char	HR	Record Yes if all eligibility criteria were met at the time the subject was enrolled. Record No if subject did not meet all criteria at the time the subject was enrolled.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification if all other fields on the CRF were deliberately left blank.
Findings	IE	N/A	N/A	7	IEDAT	Inclusion/Exclusion Collection Date	The date of collection of the inclusion/exclusion criteria represented in an unambiguous date format. (e.g., DD-MON- YYYY).	What was the date the eligibility criteria assessment was performed?	Date	Char	O	Record complete date when the eligibility assessment was performed using this format (DD- MON-YYYY).	IEDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable IEDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	IE	N/A	N/A	8	IECAT	Inclusion/Exclusion Category	A grouping category to denote whether the protocol entry criterion being assessed is Inclusion Criteria or Exclusion Criteria	What was the category of the criterion?	Criterion Type	Char	R/C	Record whether the criterion exception was Inclusion or Exclusion. Checkbox: Check Inclusion or Exclusion.	IECAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(IECAT)	N/A	These categories have been defined in SDTM and have controlled terminology that must be used. Only records for criteria that are not met appear in the IE SDTMIG domain. IECAT must be populated. This criterion category may be collected on the CRF in a checkbox format or it may be included as part of the Criterion Identification and mapped when the SDTM submission datasets are created.
Findings	IE	N/A	N/A	9	IESCAT	Inclusion/Exclusion Subcategory	A sub-division of the IECAT values based on user-defined characteristics.	What was the subcategory of the criterion?	[Criterion Subtype]; NULL	Char	O	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	IESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header This can be used to distinguish criteria for a sub- study or to categorize the criteria as a major or minor exception.
Findings	IE	N/A	N/A	10	IETESTCD	Inclusion/Exclusion Criterion Short Name	The unique identifier associated with the criterion that was the exception.	What was the identifier of the inclusion criterion the subject did not meet or the exclusion criterion the subject met ?	Exception Criterion Identifier	Char	HR	If the subject was not eligible, Record the identifying code for each criterion that was an exception.	IETESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This field is required to appear on the CRF, but may be null if there are no exceptions to the inclusion/exclusion criteria. The CRF should allow multiple exceptions to be recorded. See SDTMIG v3.2 Section 7.5.2 for assumptions regarding protocol versioning. Sponsors may provide a list of inclusion/ exclusion criteria and the unique identifying codes to the site. The list provided should be versioned/updated when the protocol changes and the criteria are changed. Sponsors should use sponsor- developed controlled terminology for IETESTCD.
Findings	IE	N/A	N/A	11	IETEST	Inclusion/Exclusion Criterion	Descriptive name of the inclusion or exclusion criterion that was the exception.	What was the description of the inclusion criterion the subject did not meet or the exclusion criterion the subject met?	Exception Criterion Description	Char	O	Record the description of the criterion, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	IETEST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable IETESTCD may be determined from the value collected in IETEST. The SDTMIG variables IETESTCD and IETEST are required in the SDTM submission datasets.	N/A	N/A	Sponsors could automatically populated the text in EDC systems when the Criterion Identifier is populated by the investigator. This can be verified by the PI to ensure the right Exception Identifier was selected.
Findings	IE	N/A	N/A	12	IEORRES	I/E Criterion Original Result	An indication of which Inclusion criterion was not met or Exclusion criterion was met.	What is the result?	(Result)	Char	HR	If collected on the CRF, the sponsor provides instructions to ensure the data is entered as intended.	IEORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	(NY)	This is only a data collection field when a complete list of inclusion and exclusion criteria are included on the CRF with Yes/No response options. If the sponsor collects only the criteria that are not fulfilled then, when an Inclusion Criteria is not met, IEORRES is mapped to "N" and when an Exclusion Criteria is met, IEORRES is mapped to "Y".

Assumptions for the CDASHIG IE - Inclusion/Exclusion Criteria Not Met Domain

1. The recommendation is for only those records for criteria that are not met to be collected on the IE CRF.

2. The complete list of inclusion/exclusion criteria and the version number of each of the criteria are provided in the SDTMIG TI dataset. The IETEST and IETESTCD values used to collect data on the IE CRF should match the values in the TI dataset.

3. Categories IECAT and IESCAT

a. The SDTMIG variable IECAT must be populated with INCLUSION or EXCLUSION. This criterion category may be collected on the CRF in a checkbox format using the CDASHIG field IECAT, or it may be included as part of the Criterion Identification and populated when the SDTM submission datasets are created.

b. IESCAT may be used by the sponsor to further categorize the exception criteria within the larger categories of Inclusion or Exclusion (e.g., Major, Minor).

c. These categories may be collected on the CRF, or they may be used as titles on the CRF and hidden/defaulted in the operational system. If these categories are not collected on the CRF or created in the operational data management system, they are added when the SDTM submission datasets are created.

4. There should be a unique IETESTCD for each unique criterion text in IETEST, and these values must match the values in the TI domain.

5. It may be useful to collect the protocol version under which a subject was screened.

6. The Collection Date (IEDAT) is the date that the IE data were recorded for the study, and not the actual date the exception occurred. The Visit Date (VISDAT) may be used, instead, to populate the SDTMIG IEDTC variable.

7. The Result (IEORRES)—"Y" or "N"—for each SDTMIG IETESTCD is derived or inferred from the collection of the specific criterion not met. IEORRES must be populated in the SDTMIG IE domain because it is a Required variable. Sponsors will populate this in the operational data management system or in the creation of the SDTMIG submission datasets. When an Inclusion Criterion is not met, the SDTMIG variable IEORRES is populated with "N"; when an Exclusion Criterion is not met, IEORRES is populated with "Y".

Example CRF for the CDASHIG IE - Inclusion/Exclusion Criteria Not Met Domain

Example 1

Title: Inclusion/Exclusion Criteria

Example CRF Completion Instructions

All procedures must be performed and the subject’s eligibility determined within (protocol-specified time period prior to study medication administration). (If applicable, include the following instructions) Complete the Inclusion/Exclusion Worksheet as source document by recording a “Yes” or “No” response to each criterion. Record the criterion identification that was an exception.



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
IEYN	1	Were all eligibility criteria met?	Met Criteria	Record Yes if all eligibility criteria were met at the time the subject was enrolled. Record No if the subject did not meet all criteria at the time the subject was enrolled.	Text	N/A		(NY)	Yes; No			radio
IECAT	2	What was the category of the criterion?	Criterion Type	Record whether the criterion exception was Inclusion or Exclusion.	Text	IECAT		(IECAT)	Inclusion; Exclusion			radio
IETESTCD	3	What was the identifier of the inclusion criterion the subject did not meet or the exclusion criterion the subject met?	Exception Criterion Identifier	If the subject was not eligible, record the identifying code for each criterion that was an exception.	Text	IETESTCD

8.3.6 LB - Laboratory Test Results

Description/Overview for the CDASHIG LB - Laboratory Test Results Domain

This Findings domain includes but is not limited to hematology, clinical chemistry, and urinalysis data. The LB domain does not include microbiology or pharmacokinetic data, which are represented in separate domains. CDASH does not specify the actual lab parameters that should be collected.

This section describes 3 different data collection scenarios for laboratory test results. It is up to the sponsor to determine which data collection scenario best meets the study needs.

Scenario 1: Central Processing

In this scenario, subject specimens are taken at site and sent out for processing. Results are provided in an electronic file and the sponsor has chosen to collect reconciliation data (e.g., LBDAT, LBTIM, VISITNUM, LBREFID) on the CRF. This scenario may also apply if the central lab results are imported into the sponsor's electronic data collection (EDC) system. The fields for test results are not defined here, as these data are not part of the CRF.



Scenario 2: Central Processing with Investigator Assessment of Clinical Significance Assessment for Abnormal Values

In this scenario, subject specimens are taken at site and sent to a central lab for processing. The results are provided in an electronic file to the sponsor. In addition, the results are provided to the investigator for assessment of clinical significance for any abnormal values and that information is provided to the sponsor on the CRF.



Scenario 3: Local Processing

In this scenario, subject specimens are taken and analyzed, and then the results are recorded directly on the CRF.



Specification for the CDASHIG LB - Laboratory Test Results Domain

Laboratory Test Results Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	LB	Central Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	LB	Central Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	LB	Central Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	LB	Central Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	LB	Central Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	The date the laboratory tests were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the laboratory tests at that visit, or the collection date can be collected on the Laboratory CRF using the date (LBDAT) field.
Findings	LB	Central Processing	N/A	6	LBPERF	Lab Performed	An indication of whether or not a planned lab measurement, series of lab measurements, tests, observations or was performed or specimens collected.	Was the sample collected?; Was the lab performed?	Lab Performed; Sample Collected	Char	HR	Indicate whether or not lab specimen was collected or measurement performed.	LBSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable LBSTAT. If the CDASH variable LBPERF = "N", the value of LBSTAT will be "NOT DONE". If LBPERF = "Y", LBSTAT should be null. A combination of SDTMIG variables ( e.g., LBCAT and LBSCAT, LBTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable LBTESTCD would be populated as LBALL and an appropriate test name (LBTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an Lab entire panel, or on a specific lab test basis. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	LB	Central Processing	N/A	7	LBDAT	Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the lab specimen collection?	Collection Date	Char	R/C	Record the date when specimen collection was done using this format (DD- MON-YYYY).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required. The SDTMIG LBDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	LB	Central Processing	N/A	8	LBTIM	Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the lab specimen collection?	[Start] Collection Time	Char	R/C	Record time of collection (as complete as possible).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on 1 day or when the timing in relationship to study treatment is required for analysis or a specimen is collected over an extended time period.
Findings	LB	Central Processing	N/A	9	LBCAT	Category for Lab Test	A grouping of topic-variable values based on user-defined characteristics.	What was the name of the lab panel?	[Lab Panel Name]; NULL	Char	R/C	Record the lab test category, if not preprinted on the CRF.	LBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBCAT and or LBSCAT should be included if lab status (NOT DONE) is collected for each lab category/subcategory (e.g., HEMATOLOGY, CHEMISTRY, URINALYSIS).
Findings	LB	Central Processing	N/A	10	LBSCAT	Subcategory for Lab Test	A sub-division of the LBCAT values based on user-defined characteristics.	What was the name of the lab sub-panel?	[Lab Sub-Panel Name]; NULL	Char	R/C	Record the lab test subcategory, if not preprinted on the CRF.	LBSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology (e.g. Electrolytes, Liver Function). This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBSCAT can only be used if there is an LBCAT and it must be a subcategorization of LBCAT.
Findings	LB	Central Processing	N/A	11	LBTPT	Lab Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the lab?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for the lab test, if not preprinted on the CRF.	LBTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See the SDTMIG for additional information on representing time points. SDTMIG time point anchors LBTPTREF (text description) and LBRFTDTC (date/time) may be needed, as well as SDTMIG variables LBTPTNUM, LBELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Findings	LB	Central Processing	N/A	12	LBCOND	Lab Test Condition Met	Indication whether the testing condition defined in the protocol were met (e.g., Low fat diet).	Were the protocol-defined testing conditions met?	Test Condition Met	Char	R/C	Record whether protocol defined testing conditions were met.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPLB dataset as the value of SUPPLB.QVAL where SUPPLB.QNAM ="LBCOND" and SUPPLB.LABEL="Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	This information is collected when the laboratory test results may be affected by whether conditions for testing were properly met. The specific testing conditions required should be preprinted on the CRF. This may not be relevant for all tests.
Findings	LB	Central Processing	N/A	13	LBFAST	Lab Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	R/C	Record whether the subject was fasting prior to the test being performed.	LBFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. This may not be relevant for all tests.
Findings	LB	Central Processing	N/A	14	LBREFID	Lab Specimen ID	An internal or external identifier such as specimen identifier.	What was the (laboratory test) [reference identifier/accession number]?	(Laboratory) [Reference identifier/Accession Number]	Char	R/C	Record the specimen or accession number assigned.	LBREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer. May be included for linking back to specimens (e.g., Specimen ID).
Findings	LB	Central Processing with CS	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	LB	Central Processing with CS	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	LB	Central Processing with CS	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	LB	Central Processing with CS	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	LB	Central Processing with CS	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	The date of the laboratory tests were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the laboratory tests at that visit, or the collection date can be collected on the Laboratory CRF using the date (LBDAT) field.
Findings	LB	Central Processing with CS	N/A	6	LBPERF	Lab Performed	An indication of whether or not a planned lab measurement, series of lab measurements, test, or observation was performed or specimens collected.	Was the sample collected?; Was the lab performed?	Lab Performed; Sample Collected	Char	HR	Indicate whether or not lab specimen was collected or measurement performed.	LBSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable LBSTAT. If the CDASH variable LBPERF="N", the value of LBSTAT will be "NOT DONE". If LBPERF="Y", LBSTAT should be null. A combination of SDTMIG variables (e.g., LBCAT and LBSCAT, LBTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable LBTESTCD would be populated as LBALL and an appropriate test name (LBTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire lab panel, or on a specific lab test basis. This general prompt question is used as a data management tool to verify that missing results are confirmed missing.
Findings	LB	Central Processing with CS	N/A	7	LBDAT	Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the lab specimen collection	Collection Date	Char	R/C	Record the date when the specimen collection was done using this format (DD- MON-YYYY).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required. The SDTMIG LBDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	LB	Central Processing with CS	N/A	8	LBTIM	Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the lab specimen collection?	[Start] Collection Time	Char	R/C	Record time of collection (as complete as possible).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis or a specimen is collected over an extended time period.
Findings	LB	Central Processing with CS	N/A	9	LBCAT	Category for Lab Test	A grouping of topic-variable values based on user-defined characteristics.	What was the name of the lab panel?	[Lab Panel Name]; NULL	Char	R/C	Record the lab test category, if not preprinted on the CRF.	LBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBCAT and or LBSCAT should be included if lab status (NOT DONE) is collected for each lab category (e.g., HEMATOLOGY, CHEMISTRY, URINALYSIS).
Findings	LB	Central Processing with CS	N/A	10	LBSCAT	Subcategory for Lab Test	A sub-division of the LBCAT values based on user-defined characteristics.	What was the name of the lab sub-panel?	[Lab Sub-Panel Name]; NULL	Char	R/C	Record the lab test subcategory, if not preprinted on the CRF.	LBSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology (e.g. Electrolytes, Liver Function). This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBSCAT can only be used if there is an LBCAT and it must be a subcategorization of LBCAT.
Findings	LB	Central Processing with CS	N/A	11	LBTPT	Lab Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the lab?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for the lab test, if not preprinted on the CRF.	LBTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. SDTMIG time point anchors LBTPTREF (text description) and LBRFTDTC (date/time) may be needed, as well as SDTMIG variables LBTPTNUM, LBELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Findings	LB	Central Processing with CS	N/A	12	LBCOND	Lab Test Condition Met	Indication whether the testing condition defined in the protocol were met (e.g., Low fat diet).	Were the protocol-defined testing conditions met?	Test Condition Met	Char	O	Record whether protocol defined testing conditions were met.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPLB dataset as the value of SUPPLB.QVAL where SUPPLB.QNAM ="LBCOND" and SUPPLB.LABEL="Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	This information is collected when the laboratory test results may be affected by whether conditions for testing were properly met. The specific testing conditions required should be preprinted on the CRF (e.g., "Did subject meet diet requirements?"). This may not be relevant for all tests.
Findings	LB	Central Processing with CS	N/A	13	LBFAST	Lab Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	R/C	Record whether the subject was fasting prior to the test being performed.	LBFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. This may not be relevant for all tests.
Findings	LB	Central Processing with CS	N/A	14	LBTEST	Lab Test or Examination Name	Descriptive name of the lab test or examination used to obtain the measurement or finding. Any test normally performed by a clinical laboratory is considered a lab test.	What was the lab test name?	[Laboratory Test Name]	Char	HR	Record the name of the Lab measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	LBTEST; LBTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable LBTESTCD may be determined from the value collected in LBTEST. The SDTMIG variables LBTESTCD and LBTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(LBTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	LB	Central Processing with CS	N/A	15	LBORRES	Lab Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the lab test?	(Result)	Char	HR	Record laboratory test result.	LBORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Optional if already provided from central lab.
Findings	LB	Central Processing with CS	N/A	16	LBORRESU	Lab Original Units	The unit of the result as originally received or collected.	What was the unit of the lab result?	Unit	Char	O	Record or select the original unit in which these data were collected.	LBORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Optional if already provided from central lab or a sponsor stored units separately.
Findings	LB	Central Processing with CS	N/A	17	LBCLSIG	Lab Clinical Significance	An indication whether lab test results were clinically significant.	Was this result clinically significant?	Clinically Significant	Char	HR	Record whether laboratory test results were clinically significant.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPLB dataset as the value of SUPPLB.QVAL where SUPPLB.QNAM ="LBCLSIG" and SUPPLB.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	Key data collected in this scenario.
Findings	LB	Central Processing with CS	N/A	18	LBREFID	Lab Specimen ID	An internal or external identifier (e.g., specimen identifier).	What was the (laboratory test) [reference identifier/accession number]?	(Laboratory test) [Reference identifier/Accession Number]	Char	R/C	Record the specimen or accession number assigned.	LBREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer. May be included for linking back to specimens (e.g., Specimen ID).
Findings	LB	Central Processing with CS	N/A	19	LBMETHOD	Lab Method of Test or Examination	Method of the test or examination.	What was the method used for the lab test or examination?	Method of Test or Examination	Char	O	Record the method of Test or Examination.	LBMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than 1 method is possible, and collecting the method used is necessary.
Findings	LB	Local Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	LB	Local Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	LB	Local Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	LB	Local Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	LB	Local Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	The date of the laboratory tests were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the laboratory tests at that visit, or the collection date can be collected on the Laboratory CRF using the date (LBDAT) field.
Findings	LB	Local Processing	N/A	6	LBPERF	Lab Performed	An indication of whether or not a planned lab measurement, series of lab measurements, test, or observation was performed or specimens collected.	Was the sample collected?; Was the lab performed?	Sample Collected; Lab Performed	Char	HR	Indicate whether or not lab specimen was collected or measurement performed.	LBSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable LBSTAT. If the CDASH variable LBPERF = "N", the value of LBSTAT will be "NOT DONE". If LBPERF = "Y", LBSTAT should be null. A combination of SDTMIG variables (e.g., LBCAT and LBSCAT, LBTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable LBTESTCD would be populated as LBALL and an appropriate test name (LBTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel, or on a specific test basis. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	LB	Local Processing	N/A	7	LBDAT	Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON-YYYY).	What was the date of the lab specimen collection?	Collection Date	Char	R/C	Record the date of specimen collection using this format (DD- MON-YYYY).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required. The SDTMIG LBDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	LB	Local Processing	N/A	8	LBTIM	Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the lab specimen collection?	[Start] Collection Time	Char	R/C	Record time of collection (as complete as possible).	LBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable LBDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis or a specimen is collected over an extended time period.
Findings	LB	Local Processing	N/A	9	LBCAT	Category for Lab Test	A grouping of topic-variable values based on user-defined characteristics.	What was the name of the lab panel?	[Lab Panel Name]; NULL	Char	R/C	Record the lab test category, if not preprinted on the CRF.	LBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBCAT and or LBSCAT should be included if lab status (NOT DONE) is collected for each lab category (e.g., HEMATOLOGY, CHEMISTRY, URINALYSIS).
Findings	LB	Local Processing	N/A	10	LBSCAT	Subcategory for Lab Test	A sub-division of the LBCAT values based on user defined characteristics.	What was the name of the lab sub-panel?	[Lab Sub-Panel Name]; NULL	Char	R/C	Record the lab test subcategory, if not preprinted on the CRF.	LBSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. Laboratory tests have commonly recognized categories and subcategories that should be used whenever appropriate. LBSCAT can only be used if there is an LBCAT and it must be a subcategorization of LBCAT.
Findings	LB	Local Processing	N/A	11	LBTPT	Lab Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the lab?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for the lab test, if not preprinted on the CRF.	LBTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. SDTMIG time point anchors LBTPTREF (text description) and LBRFTDTC (date/time) may be needed, as well as SDTMIG variables LBTPTNUM, LBELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	LB	Local Processing	N/A	12	LBFAST	Lab Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	R/C	Record whether the subject was fasting prior to the test being performed.	LBFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. This may not be relevant for all tests.
Findings	LB	Local Processing	N/A	13	LBCOND	Lab Test Condition Met	Indication whether the testing condition defined in the protocol were met (e.g., Low fat diet).	Were the protocol-defined testing conditions met?	Test Condition Met	Char	R/C	Record whether protocol defined testing conditions were met.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPLB dataset as the value of SUPPLB.QVAL where SUPPLB.QNAM = "LBCOND" and SUPPLB.LABEL="Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	This information is collected when the laboratory test results may be affected by whether conditions for testing were properly met. The specific testing conditions required should be preprinted on the CRF (e.g., "Did subject meet diet requirements?"). This may not be relevant for all tests.
Findings	LB	Local Processing	N/A	14	LBSPCCND	Lab Specimen Condition	Description of the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	O	Record condition of specimen.	LBSPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. Results may be affected by whether conditions for specimen were properly met. When local processing is used, sponsors may not routinely collect specimen condition.
Findings	LB	Local Processing	N/A	15	LBTEST	Lab Test or Examination Name	Descriptive name of the lab test or examination used to obtain the measurement or finding. Any test normally performed by a clinical laboratory is considered a lab test.	What was the lab test name?	[Laboratory Test Name]	Char	HR	Record the name of the Lab measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	LBTEST; LBTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable LBTESTCD may be determined from the value collected in LBTEST. The SDTMIG variables LBTESTCD and LBTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(LBTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	LB	Local Processing	N/A	16	LBORRES	Lab Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the lab test?	(Result)	Char	HR	Record laboratory test result.	LBORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive Findings or summaries may be recorded here.
Findings	LB	Local Processing	N/A	17	LBMETHOD	Lab Method of Test or Examination	Method of the test or examination.	What was the method used for the lab test or examination?	Method of [Test/Examination]	Char	O	Record the method of Test or Examination.	LBMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than one method is possible, and collecting the method used is necessary.
Findings	LB	Local Processing	N/A	18	LBORRESU	Lab Original Units	The unit of the result as originally received or collected.	What was the unit of the lab result?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	LBORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Should be included if applicable and not available elsewhere. For some lab tests the units may not be applicable (e.g., urine color).
Findings	LB	Local Processing	N/A	19	LBCRESU	Lab Collected Non- Standard Unit	The unit of the result as originally received if it were collected as a non-standard unit.	What was the unit of the lab result?	Unit	Char	O	Record or select the original unit in which these data were collected, if not preprinted on CRF.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. The collected, non-standard unit(s) may be submitted in a supplemental qualifier dataset.	N/A	N/A	The collected, non-standard unit(s) should be reported as an equivalent standard unit in LBORRESU.
Findings	LB	Local Processing	N/A	20	LBTOXGR	Lab Standard Toxicity Grade	The toxicity grade using a standard toxicity scale (e.g., NCI CTCAE).	What is the Toxicity Grade?	Toxicity Grade	Char	O	Record the Toxicity Grade.	LBTOXGR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	This is commonly used in oncology trials but sponsors may not collect these toxicity grades on CRFs. Terminology codes lists (TOXGRV3) and (TOXGRV4) are available for use.
Findings	LB	Local Processing	N/A	21	LBTOX	Lab Toxicity	A description of toxicity quantified by LBTOXGR (e.g., NCI CTCAE Short Name).	What is the description of the toxicity?	Toxicity	Char	O	Record the description of the toxicity.	LBTOX	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The sponsor is expected to provide the toxicity scale name and version used to map the terms utilizing the Define-XML external code list attributes.	N/A	N/A	This would typically be the text description quantified by LBTOXGR (e.g., HYPERCALCEMIA, HYPOCALCEMIA)
Findings	LB	Local Processing	N/A	22	LBORNRLO	Lab Ref Range Lower Limit in Orig Unit	The lower end of normal range or reference range for continuous results stored in LBORRES.	What was the lower limit of the reference range for this lab test?	Normal Range Lower Limit	Char	R/C	Record the lower limit of the reference range of the lab test.	LBORNRLO	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	LBORNRLO and LBORNRHI should be populated only for continuous results; LBSTNRC should be populated only for non- continuous results. These data may be obtained from the lab or the electronic equipment. These data could be determined from a site or lab specific set of normal ranges stored in a look up table. See the SDTMIG for details on mapping and selecting the proper variable name.
Findings	LB	Local Processing	N/A	23	LBORNRHI	Lab Ref Range Upper Limit in Orig Unit	The upper end of normal range or reference range for continuous results stored in LBORRES.	What was the high limit of the reference range for this lab test?	Normal Range Upper Limit	Char	R/C	Record the upper limit of the reference range of the lab test.	LBORNRHI	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	LBORNRLO and LBORNRHI should be populated only for continuous results; LBSTNRC should be populated only for non- continuous results. These data may be obtained from the lab or the electronic equipment. These data could be determined from a site or lab specific set of normal ranges stored in a look up table. See the SDTMIG for details on mapping and selecting the proper variable name.
Findings	LB	Local Processing	N/A	24	LBNRIND	Lab Reference Range Indicator	An indication or description about how the value compares to the normal range or reference range.	How [did/do] the reported values compare within the [reference/normal/expected] range?	Comparison to [Reference/Expected/Normal] Range	Char	R/C	Record where the lab result fell with respect to the reference range (e.g. HIGH, LOW, ABNORMAL).	LBNRIND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NRIND)	N/A	Reference ranges may be defined by LBORNRLO and LBORNRHI or other objective criteria. Typically for local processing "Reference Range Indicator" may be derived or determined programmatically and is not collected on the CRF. Should not be used to indicate clinical significance.
Findings	LB	Local Processing	N/A	25	LBCLSIG	Lab Clinical Significance	An indication whether lab test results were clinically significant.	Was this result clinically significant?	Clinically Significant	Char	O	Record whether lab results were clinically significant.	SUPPLB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPLB dataset as the value of SUPPLB.QVAL where SUPPLB.QNAM= "LBCLSIG" and SUPPLB.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	May be included if required by the protocol.
Findings	LB	Local Processing	N/A	26	LBNAM	Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the laboratory used?	Laboratory Name	Char	R/C	Record the laboratory name.	LBNAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if lab names was not collected at the site/study level or if multiple labs are used by a site.

Assumptions for the CDASHIG LB - Laboratory Test Results Domain

1. The lab parameters that should be collected are not specified by CDASH, as this is a medical and scientific decision that is based on the needs of the protocol.

2. Sponsors should decide which scenario is appropriate for each protocol.

3. As required or defined by the study protocol, clinically significant results may need to be reported on the Medical History or Adverse Event CRF.

4. As required or defined by the study protocol, changes that are worsening may need to be reported on the AE CRF.

5. All pertinent laboratory normal ranges/units and laboratory certification for all laboratories used during the study will be provided to the sponsor. This is required for regulatory and database purposes.

Example CRFs for the CDASHIG LB - Laboratory Test Results Domain

Example 1

Title: Laboratory Findings Scenario 1: Central Processing



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
LBCAT	1	What was the name of the lab panel?	Lab Panel Name	Record the lab test category, if not pre- printed on the CRF.	Text	LBCAT				CHEMISTRY	Prompt
LBSCAT	2	What was name of the lab sub- panel?	Lab Sub- Panel Name	Record the lab test subcategory, if not pre- printed on the CRF.	Text	LBSCAT					LIPID PROFILE Prompt
LBTPT	3	What was the planned time point of the lab?	Planned Time Point Name	Record the planned time point labels for the lab test, if not pre- printed on the CRF.	Text	LBTPT				PRE-DOSE	Prompt
LBPERF	4	Was the sample collected?	Sample Collected	Indicate whether or not lab specimen was collected or measurement performed.	Text	LBSTAT	LBSTAT = "NOT DONE" when LBPERF = "N" and LBSTAT = null when LBPERF = "Y"	(NY)	Yes; No			radio
LBDAT	5	What was the date of the lab specimen collection?	Collection Date	Record the date when specimen collection was done using this format (DD-MON- YYYY).	Date	LBDTC					Prompt
LBTIM	6	What was the time of the lab specimen collection?	Collection Time	Record time of collection (as complete as possible).	Time	LBDTC					Prompt
LBCOND	7	Did subject meet the protocol-defined diet requirements?	Diet Requirements Met	Record whether protocol-defined diet requirements were met.	Text	SUPPLB.QVAL	SUPPLB.QVAL where SUPPLB.QNAM = "LBCOND" and SUPPLB.LABEL = "Test Condition Met"	(NY)	Yes; No			radio
LBFAST	8	Was the subject fasting?	Fasting	Record whether the subject was fasting prior to the test being performed.	Text	LBFAST		(NY)	Yes; No			radio
LBREFID	9	What was the accession number?	Accession Number	Record the specimen or accession number assigned.	Text	LBREFID

Example 2

This CRF is used when lab data is received electronically, and the site will assess clinical significance for any abnormal values from the lab data.

Title: Laboratory Findings Scenario 2: Central Processing with Investigator Assessment of Clinical Significance Assessment for Abnormal Values

Example CRF Completion Instructions/ For each abnormal finding on the lab report, please enter that lab test identification here and indicate whether the finding is clinically significant.



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
LBCAT	1	What was the name of the lab panel?	Lab Panel Name	Record the lab test category, if not pre- printed on the CRF.	Text	LBCAT				CHEMISTRY	Prompt
LBSCAT	2	What was name of the lab sub-panel?	Lab Sub- Panel Name	Record the lab test subcategory, if not pre-printed on the CRF.	Text	LBSCAT				LIVER FUNCTION	Prompt
LBPERF	3	Was the sample collected?	Sample Collected	Indicate whether or not lab specimen was collected or measurement performed.	Text	LBSTAT	LBSTAT = "NOT DONE" when LBPERF = "N" and LBSTAT = null when LBPERF = "Y"	(NY)	Yes; No			radio
LBDAT	4	What was the date of the lab specimen collection?	Collection Date	Record the date when specimen collection was done using this format (DD-MON-YYYY).	Date	LBDTC					Prompt
LBTIM	5	What was the time of the lab specimen collection?	Collection Time	Record time of collection (as complete as possible).	Time	LBDTC					Prompt
LBREFID	6	What was the accession number?	Accession Number	Record the specimen or accession number assigned.	Text	LBREFID
LBSPID	7	What is the lab test identifier?	Line Number	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Text	LBSPID				01	Prompt
LBTEST	8	What was the lab test name?	Lab Test Name	Record the name of the lab measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	LBTEST; LBTESTCD		(LBTEST)	Alkaline Phosphatase; Alanine Aminotransferase; Aspartate Aminotransferase; Bilirubin; Gamma Glutamyl Transferase			radio
LBCLSIG	9	Was this result clinically significant?	Clinically Significant	Record whether laboratory test results were clinically significant.	Text	SUPPLB.QVAL	SUPPLB.QVAL where SUPPLB.QNAM = "LBCLSIG" and SUPPLB.QLABEL = "Clinically Significant"	(NY)	Yes; No			radio

Example 3

Title: Laboratory Findings Scenario 3: Local Processing



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
LBCAT	1	What was the name of the lab panel?	Lab Panel Name	Record the lab test category, if not pre-printed on the CRF.	Text	LBCAT				HEMATOLOGY	Prompt
LBSCAT	2	What was name of the lab sub-panel?	Lab Sub-Panel Name	Record the lab test subcategory, if not pre- printed on the CRF.	Text	LBSCAT				COAGULATION	Prompt
LBPERF	3	Was the lab performed?	Lab Performed	Indicate whether or not lab specimen was collected or measurement performed.	Text	LBSTAT	LBSTAT = "NOT DONE" when LBPERF = "N" and LBSTAT = null when LBPERF = "Y"	(NY)	Yes; No			Radio
LBDAT	4	What was the date of the lab specimen collection?	Collection Date	Record the date of specimen collection using this format (DD-MON-YYYY).	Date	LBDTC					Prompt
LBTIM	5	What was the time of the lab specimen collection?	Collection Time	Record time of collection (as complete as possible).	Time	LBDTC					Prompt
LBSPCCND	6	What was the condition of the specimen?	Specimen Condition	Record condition of specimen.	Text	LBSPCCND		(SPECCOND)	FRESH; FROZEN; REFRIGERATED			Radio
LBNAM	7	What was the name of the laboratory used?	Laboratory Name	Record the laboratory name.	Text	LBNAM
LBTEST	8	What is the lab test name?	Lab Test Name	Record the name of the lab measurement or finding, if not pre-printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	LBTEST; LBTESTCD	LBTEST and LBTESTCD	(LBTEST)	Prothrombin Intl. Normalized Ratio; Activated Partial Thromboplastin Time; Prothrombin Time; Thrombin Time; Fibrinogen; D-Dimer; Factor V; Factor VIII		Prompt	Radio
LBMETHOD	9	What was the method used for the lab test or examination?	Method of Test	Record the method of the test or examination.	Text	LBMETHOD		(METHOD)	CLAUSS METHOD; CLOT DETECTION; MANUAL CLOT DETECTION; MECHANICAL CLOT DETECTION; PHOTOMETRIC CLOT DETECTION			Radio
LBORRES	10	What was the result of the lab test?	Result	Record laboratory test result.	Text	LBORRES					Prompt
LBORRESU	11	What was the unit of the lab result?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	LBORRESU		(UNIT)	g/L; mg/dL; mg/L; U/mL; ug/L; sec; RATIO		Prompt	Radio
LBORNRLO	12	What was the lower limit of the reference range for this lab test?	Normal Range Lower Limit	Record the lower limit of the reference range of the lab test.	Text	LBORNRLO					Prompt
LBORNRHI	13	What was the high limit of the reference range for this lab test?	Normal Range Upper Limit	Record the upper limit of the reference range of the lab test.	Text	LBORNRHI					Prompt
LBNRIND	14	How do the reported values compare within the reference range?	Comparison to Reference Range	Record where the lab result fell with respect to the reference range (i.e., HIGH, NORMAL, LOW).	Text	LBNRIND		(NRIND)	High; Normal; Low		Prompt	Radio
LBCLSIG	15	Was this result clinically significant?	Clinically Significant	Record whether lab results were clinically significant.	Text	SUPPLB.QVAL	SUPPLB.QVAL where SUPPLB.QNAM = "LBCLSIG" and SUPPLB.QLABEL = "Clinically Significant"	(NY)	Yes; No			Radio
LBTOXGR	16	What is the Toxicity Grade?	Toxicity Grade	Record the toxicity grade.	Text	LBTOXGR			0; 1; 2; 3; 4			Radio
LBTOX	17	What is the description of the toxicity?	Toxicity	Record the description of the toxicity.	Text	LBTOX

8.3.7 MB - Microbiology Specimen

Description/Overview for the CDASHIG MB - Microbiology Domain

The MB (Microbiology Specimen) and MS (Microbiology Susceptibility) domains are a pair of domains used to represent microbiology findings. The MB domain is used to represent findings such as the identification, quantification, and other characterizations of microorganisms in subject samples, with the exception of drug susceptibility testing. The MB domain typically includes organisms found (e.g., non-host organisms identified including bacteria, viruses, parasites, protozoa, and fungi), gram stain results, and organism growth status. Culture characteristics may also be included (e.g., concepts such as growth/no growth, colony quantification measures, colony color, colony morphology).

Newer releases of the SDTMIG (e.g., SDTMIG v3.3) provide more information on how microbiology specimen and results are submitted. For example, the variable MBTSTDTL can be used as a further description of MBTESTCD and MBTEST (e.g., MBTSTDTL="VIRAL LOAD" when MBTESTCD represents viral genetic material such as "HCRNA"; MBTSTDTL ="QUANTIFICATION" when MBTESTCD represents any organism being quantified; MBTSTDTL="DETECTION" when MBTEST equals the name of the organism/antigen targeted by the identification assay).

The Therapeutic Area User Guides (TAUGs) for TB (Tuberculosis) and CDAD (Clostridium Difficile Associated Diarrhea) also provide MB examples that are modeled after SDTMIG v3.3. SDTMIG v3.3 provides recommendation on how to represent (1) tests that target an organism, group of organisms, or antigen for identification, (2) tests that are non-targeted identification of organisms (i.e., tests that have the ability to identify a range of organisms without specifically targeting any), and (3) tests about organisms being characterized.

Specification for the CDASHIG MB - Microbiology Specimen Domain

Microbiology Specimen Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	MB	Central Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	MB	Central Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted for the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MB	Central Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MB	Central Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MB	Central Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	The date that the Microbiology Findings were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microbiology Findings at that visit, or the collection date can be included on the Microbiology Findings CRF using the date (MBDAT) field.
Findings	MB	Central Processing	N/A	6	MBPERF	Microbiology Sampling Performed	An indication of whether or not a planned measurement, series of measurements, tests or observations was performed or specimen was collected.	Was [specimen type] collected or [test topic] performed?	[Specimen/Sample] Collected; [Test topic] Performed	Char	O	Indicate whether or not microbiology specimen was collected	MBSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MBSTAT. If MBPERF = "N", the value of MBSTAT will be "NOT DONE". If MBPERF = "Y", MBSTAT should be null. A combination of SDTMIG variables (e.g., MBCAT and MBSCAT, MBTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MBTESTCD would be populated as MBALL and an appropriate test name (MBTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. General prompt question to be used as a data management tool to verify that missing results are confirmed missing. For the SDTM submission dataset, the SDTMIG variable MBSTAT is populated using the CDASH field MBPERF. The question text used might be reflected in the reason not done (MBREASND).
Findings	MB	Central Processing	N/A	7	MBREFID	MB Reference ID	An internal or external identifier such as specimen identifier.	What was the (microbiology test) [reference identifier/accession number]?	(Microbiology Test) [Reference Identifier/ Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MBREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer. May be included for linking back to specimens (e.g., Specimen ID).
Findings	MB	Central Processing	N/A	8	MBDAT	MB Specimen Collection Date	The date of specimen collection ,represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the (start) date of the (microbiology) specimen collection?	Collection Date	Char	R/C	Record the date when specimen collection occurred using this format (DD-MON- YYYY).	MBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and, if so, a separate assessment date field is not required.
Findings	MB	Central Processing	N/A	9	MBTIM	MB Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the (microbiology) specimen collection?	Collection Time	Char	R/C	Record time of collection (as complete as possible).	MBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis.
Findings	MB	Central Processing	N/A	10	MBCAT	MB Category for Microbiology Finding	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the microbiology finding?	[Microbiology Category]; NULL	Char	O	Record the microbiology finding category, if not preprinted on the CRF.	MBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MB	Central Processing	N/A	11	MBSCAT	MB Subcategory for Microbiology Finding	A sub-division of the MBCAT values based on user-defined characteristics.	What was the subcategory of the microbiology finding?	[Microbiology Subcategory]; NULL	Char	O	Record the microbiology finding subcategory, if not preprinted on the CRF.	MBSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MBSCAT can only be used if there is an MBCAT and it must be a subcategorization of MBCAT.
Findings	MB	Central Processing	N/A	12	MBSPEC	MB Specimen Type	Defines the type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	R/C	Record the specimen material type.	MBSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MB	Central Processing	N/A	13	MBSPCCND	MB Specimen Condition	Description of the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	R/C	Record condition of specimen.	MBSPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MB	Central Processing	N/A	14	MBLOC	MB Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location where the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MBLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, PORTOT are used to further describe the anatomical location.
Findings	MB	Central Processing	N/A	15	MBLAT	MB Specimen Collection Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MBLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MB	Central Processing	N/A	16	MBDIR	MB Specimen Collection Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MBDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MB	Local Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	MB	Local Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MB	Local Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MB	Local Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MB	Local Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	The date that the Microbiology Specimen was collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microbiology Findings at that visit, or the collection date can be included on the Microbiology Findings CRF using the date (MBDAT) field.
Findings	MB	Local Processing	N/A	6	MBPERF	Microbiology Sampling Performed	An indication of whether or not a planned measurement, series of measurements, test, or observation was performed or specimen was collected.	Was the microbiology examination performed?	Microbiology Examination Performed	Char	O	Indicate whether or not microbiology examination performed.	MBSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MBSTAT. If MBPERF="N", the value of MBSTAT will be "NOT DONE". If MBPERF="Y", MBSTAT should be null. A combination of SDTMIG variables (e.g., MBCAT and MBSCAT, MBTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MBTESTCD would be populated as MBALL and an appropriate test name (MBTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	MB	Local Processing	N/A	7	MBREFID	MB Reference ID	An internal or external identifier such as specimen identifier.	What was the (microbiology test) [reference identifier/accession number]?	(Microbiology Test) [Reference identifier/ Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MBREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to reconcile CRF data. May be included for linking back to specimens (e.g., Specimen ID).
Findings	MB	Local Processing	N/A	8	MBSPID	MB Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	MBSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	MB	Local Processing	N/A	9	MBGRPID	MB Group ID	A group identifier used to link together a block of related records within a subject in a domain.	What [is/was] the [test/procedure/observation] group identifier?	[Test/Procedure/ Observation] Group Identifier	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each microbiology specimen or result record has a unique identifier that will link records across domains.	MBGRPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	SDTMIG v3.2 uses --GRPID as the variable that links the Microbiology Specimen/Result domain (MB) with the Microbiology Susceptibility domain (MS). In RELREC, this one-to-many relationship may be represented with a simple 2-record dataset-to-dataset RELREC.
Findings	MB	Local Processing	N/A	10	MBLNKID	MB Link ID	An identifier used to link related records across domains.	What [is/was] the [test/procedure/observation] link identifier?	[Domain/Observation] Link Identifier	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each microbiology specimen or result record has a unique identifier that will link records across domains.	MBLNKID	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This may be a one-to-one or a one-to-many relationship. For example, a single microbiology specimen or result may have multiple measurements/assessments performed (e.g., susceptibility testing).
Findings	MB	Local Processing	N/A	11	MBDAT	MB Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the (start) date of the (microbiology) specimen collection?	Collection Date	Char	R/C	Record the date of specimen collection using this format (DD- MON-YYYY).	MBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and, if so, a separate assessment date field is not required.
Findings	MB	Local Processing	N/A	12	MBTIM	MB Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the (microbiology) specimen collection?	Collection Time	Char	R/C	Record time of collection (as complete as possible).	MBDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MBDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis.
Findings	MB	Local Processing	N/A	13	MBCAT	MB Category for Microbiology Finding	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the Microbiology finding?	[Microbiology Category]; NULL	Char	O	Record the microscopic finding category, if not preprinted on the CRF.	MBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MB	Local Processing	N/A	14	MBSCAT	MB Subcategory for Microbiology Finding	A sub-division of the MBCAT values based on user-defined characteristics.	What was the subcategory of the Microbiology finding?	[Microbiology Subcategory]; NULL	Char	O	Record the microscopic finding subcategory, if not preprinted on the CRF.	MBSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MBSCAT can only be used if there is an MBCAT and it must be a subcategorization of MBCAT.
Findings	MB	Local Processing	N/A	15	MBTEST	Microbiology Test or Finding Name	Descriptive name of the Microbiology test or examination used to obtain the measurement or finding.	What was the Microbiology examination test name?	[Microbiology Test Name]	Char	HR	Record the type or name of the microscopic examination, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MBTEST; MBTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable MBTESTCD may be determined from the value collected in MBTEST. Both MBTESTCD and MBTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(MBTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	MB	Local Processing	N/A	16	MBTSTDTL	Microbiology Examination Detail	Detail of the Microbiology examination used to obtain the measurement or finding.	What was the Microbiology examination detail?	[Examination Name Detail]	Char	O	Record the detail of the microbiology examination, if not preprinted on the CRF.	MBTSTDTL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Provides additional details for the microbiology examination. It is recommended that the test detail be preprinted on the CRF. If the form is laid out as a grid, then words such as "Test Detail" can be included as the column header.
Findings	MB	Local Processing	N/A	17	MBORRES	MB Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the examination?	(Result)	Char	HR	Record test result, interpretation or finding.	MBORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	MB	Local Processing	N/A	18	MBORRESU	MB Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	MBORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Should be included if applicable and not available elsewhere. For some tests the units may not be applicable (e.g., where MBTEST="Microbial Organism Identification").
Findings	MB	Local Processing	N/A	19	MBCLSIG	MB Clinical Significance	An indication whether the test results were clinically significant.	Was the result clinically significant?	Clinically Significant	Char	O	Indicate whether the results were clinically significant.	SUPPMB.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMB dataset as the value of SUPPMB.QVAL where SUPPMB.QNAM = "MBCLSIG" and SUPPMB.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	N/A
Findings	MB	Local Processing	N/A	20	MBRESCAT	MB Result Category	Used to categorize the result of a finding.	What was the result category?	Result Category	Char	O	Record the category of the test results.	MBRESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Used to categorize the results of a finding (e.g., INFECTING, COLONIZER).
Findings	MB	Local Processing	N/A	21	MBNAM	MB Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the vendor used?	Vendor Name	Char	O	Record the laboratory name.	MBNAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if lab names was not collected at the site/study level or if multiple labs are used by a site.
Findings	MB	Local Processing	N/A	22	MBSPEC	MB Specimen Type	The type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	O	Record the specimen material type.	MBSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MB	Local Processing	N/A	23	MBSPCCND	MB Specimen Condition	Describes the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	O	Record condition of specimen.	MBSPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MB	Local Processing	N/A	24	MBLOC	MB Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location where the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MBLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	MB	Local Processing	N/A	25	MBLAT	MB Specimen Collection Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MBLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MB	Local Processing	N/A	26	MBDIR	MB Specimen Collection Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MBDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MB	Local Processing	N/A	27	MBMETHOD	MB Method of Test or Examination	Method of the test or examination.	What was the method used for the test or examination?	Method	Char	O	Record the method of test or examination.	MBMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than one method is possible, and collecting the method used is necessary. This could include technique or type of staining used for the slides.
Findings	MB	Local Processing	N/A	28	MBEVAL	MB Evaluator	The role of the person who provided the evaluation.	Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	MBEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted, or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.

Assumptions for the CDASHIG MB - Microbiology Specimen Domain

1. The MB domain is used to represent identification, quantification, and other characterizations of microorganisms in subject samples. Culture characteristics such as growth/no growth, colony quantification measures, colony color, and colony morphology are also represented in this domain.

2. Drug susceptibility testing is not represented in the MB domain.

3. Data about actions taken that affect or may affect a specimen, such as specimen collection, freezing and thawing, aliquoting, and transportation are not included in this domain, but are included in the BE (Biospecimen Events) domain. See BE domain assumptions in the SDTMIG for Pharmacogenomic/Genetics (SDTMIG-PGx).

4. MBDTC represents the date the specimen was collected.

Example CRFs for the CDASHIG MB - Microbiology Specimen Domain

Example 1

Title: Acute Respiratory Infection-Pathogen Testing CRF



CRF Metadata

Order Number	CDASH Variable	Question Text	Prompt	Type	CRF Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	MBCAT	What was the category of the microbiology finding?	Microbiology Category	Text	Record the microbiology finding category, if not pre-printed on the CRF.	MBCAT		N/A		ACUTE RESPIRATORY INFECTION			Y
2	MBPERF	Was any pathogen testing performed?	Pathogen Testing Performed	Text	Indicate whether any pathogen testing was performed.	MBSTAT	If MBPERF = "N", then MBSTAT = "NOT DONE" and MBTESTCD = "MBALL". If MBPERF = "Y", MBSTAT is NULL.	(NY)	Yes;No
3	MBDAT	What was the date the specimen was collected?	Collection Date	Text	Record the date when specimen collection occurred using this format (DD- MON-YYYY).	MBDTC		N/A
4	MBSPEC	What is the specimen material type?	Specimen Type	Text	Record the specimen material type.	MBSPEC		(SPECTYPE)	Nasal/NP Swab;Throat swab;Sputum
5	MBTEST	What was the Microbiology examination test name?	Microbiology Test Name	Text	Record the type or name of the microscopic examination, if not pre-printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MBTEST; MBTESTCD	MBTEST="Microbial Organism Identification" where MBTESTCD="MCORGIDN"	(MBTEST)		Identification			Y
6	MBRES	What was the result of the test?	Result	Text	Record test result, interpretation or finding.	MBORRES	MBORRES="NO GROWTH" when MBRES="NO GROWTH"	N/A	Growth;No Growth
7	MBDES	What was the specific pathogen tested?	Pathogen Tested	Text	If growth, record the specific pathogen identified.	MBORRES	MBORRES=MBDES when MBRES="GROWTH"	N/A
8	MBMETHOD	What was the method used for the test?	Method	Text	Record the method of test or examination.	MBMETHOD		(METHOD)	CULTURE;OTHER

Example 2

Title: Tuberculosis Pathogen Testing



CRF Metadata

Order Number	CDASHIG Variable	Question Text	Prompt	Type	CRF Completion Instructions	SDTMIG Target	SDTMIG Variable Mapping	Controlled Terminology Codelist Name	CRF Implementation Notes	Permissible Values	Pre- specified Value	Query Display	List Style	Hidden
1	SAMPLE_MBYN	Was a sputum sample collected?	Sample Collected	Text	Indicate if a sputum sample was collected.			(NY)		Yes;No
2	MBDAT	What was the date the sputum specimen was collected?	Collection Date	Text	Record the date when specimen collection occurred using this format (DD-MON-YYYY).	MBDTC		N/A
3	AFB_MBPERF	Was an AFB smear performed ?	AFB Smear	Text	Indicate whether an AFB smear was performed.	MBSTAT		(NY)		Yes;No
5	AFB_MBREASND	What was the reason the AFB smear was not done?	Reason	Text	Indicate the reason the AFB smear was not performed.	MBREAS	MBREAS where MBSTAT="NOT DONE"
6	AFB_MBORRES	What was the AFC smear result?	Smear Result	Text	Record the AFC smear result.	MBORRES	MBORRES where MBTESTCD="AFB"	N/A		Negative; +1 Rare; +2 Few; +3 Moderate; +4 Many
4	AFB_MBMETHOD	What was the method?	Method	Text	Indicate the method used for the smear.	MBMETHOD		(METHOD)			SMEAR			Y
6	AFB_MBSPEC	What is the specimen material type?	Specimen Type	Text	Record the specimen material type.	MBSPEC		(SPECTYPE)			SPUTUM			Y
7	AFB_MBTEST	What was the Microbiology examination test name?	Microbiology Test Name	Text	Record the type or name of the microscopic examination, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MBTEST; MBTESTCD	MBTEST="Acid-Fast Bacilli" where MBTESTCD="AFB"	(MBTEST)			Acid-Fast Bacilli			Y
	AFB_MBTSTDTL	What was the test detail?	Microbiology Test Detail	Text	N/A	MBTSTDTL					Quantification, Categorical			Y
7	MGIT_MBPERF	Was a B-D MGIT culture performed?	B-D MGIT Performed	Text	Indicate whether the B-D MGIT culture was performed.	MBSTAT	MBSTAT="NOT DONE" when MGIT_MBPERF='No"			Yes;No
8	MGIT_BESTDT	What was the date the specimen was inoculated?	Innoulation Date	Text	Record the date the sample was inoculated.		BESTDTC where BETERM="INOCULATION"
	MGIT_MBRUNDAT	What was the date the B-D MGIT culture result was reported?	Culture Result Date	Text	Record the date the culture results were reported.	SUPPMB.QVAL	SUPPMS.QVAL where SUPPMS.QNAM = "MBRUNDTC " and SUPPMS.QLABEL="RUN DATE"
	MGIT_MBORRES	What were the B-D MGIT culture results?	Result	Text	Indicate the culture results.	MBORRES	MBORRES where MBTESTCD="MTB"			Negative for MTB complex;Positive for MTB complex;No TB growth, but positive for other mycobacteria;Postive for MTB complex but contaminated
7	MGIT_MBTEST	What was the Microbiology examination test name?	Microbiology Test Name	Text	Record test result, interpretation or finding.	MBTEST;MBTESTCD;	MBTEST="Mycobacterium Tuberculosis"	N/A			Mycobacterium Tuberculosis			Y
	MGIT_MBTSTDTL	What was the test detail?	Microbiology Test Detail	Text	N/A	MBTSTDTL	MBTSTDTL where MBTESTCD="MTB"				Identification			Y
8	MGIT_MBMETHOD	What was the method used for the test?	Method	Text	Record the method of test or examination.	MBMETHOD		(METHOD)			B-D MGIT			Y

8.3.8 MS - Microbiology Susceptibility

Description/Overview for the CDASHIG MS - Microbiology Susceptibility Domain

The MB (Microbiology Specimen) and MS (Microbiology Susceptibility) domains are a pair of domains used to represent microbiology findings. The MS domain is used to represent data from drug susceptibility testing.This includes phenotypic testing (where drug is added directly to a culture of organisms) and genotypic tests that provide results in terms of susceptible or resistant. Drug susceptibility testing may occur on a wide variety of non-host organisms, including bacteria, viruses, fungi, protozoa, and parasites. Phenotypic drug susceptibility testing may involve determining susceptibility/resistance (qualitative) at a pre-defined concentration of drug, or may involve determining a specific dose (quantitative) at which a drug inhibits organism growth or some other process associated with virulence. The MS domain is appropriate for both of these types of drug susceptibility tests.

Newer releases of the SDTMIG (e.g., SDTMIG 3.3) provide more information on how Microbiology Susceptibility results may be submitted. Sponsors can continue to show the "agent" with which the organism is being evaluated against.for susceptibility (as in examples in the SDTMIG v3.2) or can follow the newer examples used in SDTMIG 3.3 and several therapeutic area user guides (e.g., TAUG-Tuberculosis, TAUG- Clostridium Difficile Associated Diarrhea). In particular, several new variables—Non-host Organism ID (NHOID), Agent Name (MSAGENT), Agent Concentration (MSCONC), and Agent Concentration Unit (MSCONCU)—were added.

When data is submitted to a health authority using an older version of the SDTMIG (e.g., version prior to 3.3), sponsors may elect to use this newer approach for representing drug susceptibility testing. Using this approach, sponsors may define non-standard variables as described in the SDTMIG for NHOID, MSAGENT, MSCONC, and MSCONCU.

The current controlled terminology for MSTESTCD assumes that the "agent" used is not included in the MSTESTCD as is shown in SDTMIG 3.2.

CDASHIG v2.1 has included these new variables in the CDASH Domain Metadata table and CRF examples, when appropriate, as non-standard variables.

Specification for the CDASHIG MS - Microbiology Susceptibility Domain

Microbiology Susceptibility Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	MS	Central Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	MS	Central Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MS	Central Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/ Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MS	Central Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MS	Central Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	The date the Microscopic Findings were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microscopic Findings at that visit, or the collection date can be included on the Microscopic Findings CRF using the date (MIDAT) field.
Findings	MS	Central Processing	N/A	6	MSPERF	MS Test Performed	An indication of whether or not a planned measurement, series of measurements, tests or observations was performed.	Was the Microbiology Susceptibility test performed?	Microbiology Susceptibility Performed	Char	O	Indicate whether or not a microbiology susceptibility test was performed.	MSSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MSSTAT. If MSPERF="N", the value of MSSTAT will be "NOT DONE". If MSPERF="Y", MSSTAT should be null. A combination of SDTMIG variables (e.g., MSCAT and MSSCAT, MSTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MSTESTCD would be populated as MSALL and an appropriate test name (MSTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. General prompt question to be used as a data management tool to verify that missing results are confirmed missing. For the SDTM submission dataset, the SDTMIG variable MSSTAT is populated using the CDASH field MSPERF. The question text used might be reflected in the reason not done (MSREASND).
Findings	MS	Central Processing	N/A	7	MSREFID	MS Reference ID	An internal or external identifier such as specimen identifier.	What was the (microbiology susceptibility test) [reference identifier/accession number]?	(Microbiology Susceptibility Test) [Reference Identifier/Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MSREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer. May be included for linking back to specimens (e.g., Specimen ID).
Findings	MS	Central Processing	N/A	8	MSDAT	MS Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the (start) date of the (microbiology) specimen collection?	Test Date	Char	R/C	Record the date when specimen collection occurred using this format (DD-MON- YYYY).	MSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MSDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	MS	Central Processing	N/A	9	MSTIM	MS Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the (microbiology) specimen collection?	Susceptibility Test Time	Char	R/C	Record time of susceptibility test (as complete as possible).	MSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MSDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis.
Findings	MS	Central Processing	N/A	10	MSCAT	MS Category for Organism Findings	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the microbiology susceptibility test?	[Microbiology Susceptibility Category]; NULL	Char	O	Record the microbiology susceptibility category, if not preprinted on the CRF.	MSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MS	Central Processing	N/A	11	MSSCAT	MS Subcategory for Organism Findings	A sub-division of the MSCAT values based on user-defined characteristics.	What was the subcategory of the microbiology susceptibility finding?	[Microbiology Susceptibility Subcategory]; NULL	Char	O	Record the microbiology susceptibility subcategory, if not preprinted on the CRF.	MSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MSSCAT can only be used if there is an MSCAT and it must be a subcategorization of MSCAT.
Findings	MS	Central Processing	N/A	12	MSSPEC	MS Specimen Type	Defines the type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	R/C	Record the specimen material type.	MSSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MS	Central Processing	N/A	13	MSSPCCND	MS Specimen Condition	Description of the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	R/C	Record condition of specimen.	MSSPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MS	Central Processing	N/A	14	MSLOC	MS Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location where the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MSLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	MS	Central Processing	N/A	15	MSLAT	MS Specimen Collection Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MSLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MS	Central Processing	N/A	16	MSDIR	MS Specimen Collection Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MSDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MS	Local Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	MS	Local Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MS	Local Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MS	Local Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MS	Local Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	The date of Microscopic Findings were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microscopic Findings at that visit, or the collection date can be included on the Microscopic Findings CRF using the date (MSDAT) field.
Findings	MS	Local Processing	N/A	6	MSPERF	MS Susceptibility Test Performed	An indication of whether or not a planned measurement, series of measurements, tests or observations was performed.	Was the microbiology susceptibility test performed?	Microbiology Susceptibility Performed	Char	O	Indicate whether or not microbiology susceptibility test was performed.	MSSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MSSTAT. If MSPERF = "N", the value of MSSTAT will be "NOT DONE". If MSPERF = "Y", MSSTAT should be null. A combination of SDTMIG variables (e.g., MSCAT and MSSCAT, MSTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MSTESTCD would be populated as MSALL and an appropriate test name (MSTEST) provided. See SDTMIG Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	MS	Local Processing	N/A	7	MSREFID	MS Reference ID	An internal or external identifier such as specimen identifier.	What was the (microbiology susceptibility test) [reference identifier/accession number]?	(Microbiology Susceptibility test) [Reference identifier/Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MSREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to reconcile CRF data). May be included for linking back to specimens (e.g., Specimen ID).
Findings	MS	Local Processing	N/A	8	MSSPID	MS Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	MSSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	MS	Local Processing	N/A	9	MSLNKID	MS Link ID	An identifier used to link related records across domains.	What [is/was] the [test/procedure/observation] link identifier?	[Domain/Observation] Link Identifier	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each microbiology susceptibility result has an identifier that will link records across domains.	MSLNKID	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This may be a one-to- one or a one-to-many relationship. For example, a single microbiology specimen or result may have multiple measurements/assessments performed (e.g., susceptibility testing).
Findings	MS	Local Processing	N/A	10	MSDAT	MS Specimen Collection Date	The date of specimen collection ,represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the (start) date of the (microbiology) specimen collection?	Collection Date	Char	R/C	Record the date of specimen collection using this format (DD- MON-YYYY).	MSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MSDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	MS	Local Processing	N/A	11	MSTIM	MS Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the the (microbiology) collection?	Collection Time	Char	R/C	Record time of collection (as complete as possible).	MSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MSDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis.
Findings	MS	Local Processing	N/A	12	MSCAT	MS Category for Organism Findings	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the Microbiology Susceptibility finding?	[Microbiology Susceptibility Category]; NULL	Char	O	Record the microscopic finding category, if not preprinted on the CRF.	MBCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MS	Local Processing	N/A	13	MSSCAT	MS Subcategory for Organism Findings	A sub-division of the MSCAT values based on user-defined characteristics.	What was the subcategory of the Microbiology Susceptibility finding?	[Microbiology Susceptibility Subcategory]; NULL	Char	O	Record the microscopic finding subcategory, if not preprinted on the CRF.	MSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MSSCAT can only be used if there is an MSCAT and it must be a subcategorization of MSCAT.
Findings	MS	Local Processing	N/A	14	MSTEST	MS Organism Test or Finding Name	Descriptive name of the Microbiology Susceptibility test or examination used to obtain the measurement or finding.	What was the Microbiology Susceptibility test name?	[Microbiology Susceptibility Test Name]	Char	HR	Record the type or name of the microscopic examination, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MSTEST; MSTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable MSTESTCD may be determined from the value collected in MSTEST. Both MSTESTCD and MSTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(MBTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	MS	Local Processing	N/A	15	MSTSTDTL	Microbiology Susceptibility Test Detail	Detail of the Microbiology Susceptibility Test used to obtain the measurement or finding. Helps to establish a unque record.	What was the Microbiology Susceptibility Test detail?	Test Detail	Char	O	Record the detail of the microbiology susceptibility test, if not preprinted on the CRF.	MSTSTDTL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Provides additional details for the microbiology susceptibility test if necessary to define a unique record. It is recommended that the test detail be preprinted on the CRF. If the form is laid out as a grid, then words such as "Test Detail" can be included as the column header.
Findings	MS	Local Processing	N/A	16	MSORRES	MS Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the examination?	(Result)	Char	HR	Record test result, interpretation or finding.	MSORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	MS	Local Processing	N/A	17	MSORRESU	MS Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	MSORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Should be included if applicable and not available elsewhere. For some tests the units may not be applicable (e.g., where MSTEST requires simply a qualitative result).
Findings	MS	Local Processing	N/A	18	MSCLSIG	MS Clinical Significance	An indication whether the test results were clinically significant.	Was the result clinically significant?	Clinically Significant	Char	O	Indicate whether the results were clinically significant.	SUPPMS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMS dataset as the value of SUPPMS.QVAL where SUPPMS.QNAM="MSCLSIG" and SUPPMS.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	N/A
Findings	MS	Local Processing	N/A	19	MSRESCAT	MS Result Category	Used to categorize the result of a finding.	What was the result category?	Result Category	Char	O	Record the category of the test results.	MSRESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Used to categorize the results of a finding (e.g., "SUSCEPTIBLE", "RESISTANT").
Findings	MS	Local Processing	N/A	20	MSNAM	MS Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the vendor used?	Vendor Name	Char	O	Record the laboratory name.	MSNAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if lab names was not collected at the site/study level or if multiple labs are used by a site.
Findings	MS	Local Processing	N/A	21	MSSPEC	MS Specimen Type	Defines the type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	R/C	Record the specimen material type.	MSSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MS	Local Processing	N/A	22	MSSPCCND	MS Specimen Condition	Describes the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	O	Record condition of specimen.	MSSPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MS	Local Processing	N/A	23	MSLOC	MS Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location where the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MSLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	MS	Local Processing	N/A	24	MSLAT	MS Specimen Collection Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MSLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MS	Local Processing	N/A	25	MSDIR	MS Specimen Collection Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MSDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MS	Local Processing	N/A	26	MSMETHOD	MS Method of Test or Examination	Method of the test or examination.	What was the method used for the test or examination?	Method	Char	O	Record the method of test or examination.	MSMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than one method is possible, and collecting the method used is necessary. This could include technique or type of staining used for the slides.
Findings	MS	Local Processing	N/A	27	MSEVAL	MS Evaluator	The role of the person who provided the evaluation.	Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	MSEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MS	Local Processing	N/A	28	NHOID	Non-host Organism ID	The identifier for a non-host organism which should only be used when the organism is the subject of the test.	What was the Non-host Organism ID?	Non-host Organism ID	Char	O	Record the identifier for a non-host organism that is the subject of the test.	SUPPMS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMS dataset as the value of SUPPMS.QVAL where SUPPMS.QNAM="NHOID" and SUPPMS.QLABEL="Non-host Organism ID". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	Sponsor-defined identifier for a non-host organism which should only be used when the organism is the subject of the test. These variables were added as core SDTM variables in SDTMIG v3.3.
Findings	MS	Local Processing	N/A	29	MSAGENT	Microbiology Susceptibility Agent	The name of the agent for which resistance is tested	What was the name of the agent for which resistance is being tested?	Microbiology Susceptibility Agent	Char	O	Record the name of the agent for which resistance is being tested.	SUPPMS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMS dataset as the value of SUPPMS.QVAL where SUPPMS.QNAM="MSAGENT" and SUPPMS.QLABEL= "Microbiology Susceptibility Agent". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	N/A	N/A	These variables were added as core SDTM variables in SDTMIG v3.3.
Findings	MS	Local Processing	N/A	30	MSCONC	MS Agent Concentration	The concentration of the agent for which resistance is tested.	What was the concentration of the agent?	Agent Concentration	Char	O	Record the concentration of the agent.	SUPPMS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMS.QVAL where SUPPMS.QNAM="MSCONC" and SUPPMS.QLABEL="MS Agent Concentration". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	These variables were added as core SDTM variables in SDTMIG v3.3.
Findings	MS	Local Processing	N/A	31	MSCONCU	MS Agent Concentration Unit	The concentration unit of the agent for which resistance is tested.	What was the agent concentration unit?	Agent Concentration Unit	Char	O	Record the concentration unit of the agent.	SUPPMS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMS dataset as the value of SUPPMS.QVAL where SUPPMS.QNAM="MSCONCU" and SUPPMS.QLABEL="MS Agent Concentration Unit". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A	These variables were added as core SDTM variables in SDTMIG v3.3.

Assumptions for the CDASHIG MS - Microbiology Susceptibility Domain

1. This domain is used only to represent drug susceptibility testing results.

2. MSDTC represents the date the specimen was collected.

3. Information on processing of the biospecimen, including collection and storage information (e.g., culture start and end date), are represented in the BE (Biospecimen Events) domain. See BE domain assumptions in the SDTMIG for Pharmacogenomic/Genetics (SDTMIG-PGx).

4. If used, the variable NHOID, a non-standard variable in SDTMIG versions prior to v3.3, is an intuitive name of the non-host organism being tested. It should only be populated with values representing what is known about the identity of the organism before the results of the test are determined. It should therefore never be used as a result qualifier.

5. Genotypic tests that provide results in terms of specific changes to nucleotides, codons, or amino acids of genes/gene products associated with resistance should be represented in the PF (Pharmacogenomics/genetics Findings) domain.

Example CRF for the CDASHIG MS - Microbiology Susceptibility Domain

Example 1

This sample CRF may be set up as a table with 1 row for each Microbiology Susceptibility Agent, or 1 record can be included for each Microbiology Susceptibility finding. The NSV variable NHOID (Non-Host Organism Identifier) can be included and populated with the name of the organism that is the subject of the test.

Title: Tuberculosis Drug Susceptibility



CRF Metadata

Order Number	CDASH Variable	Question Text	Prompt	Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
1	MSPERF	Was TB drug susceptibility testing performed?	TB Drug Susceptibility Performed	Text	Indicate whether or not tuberculosis drug susceptibility was performed.	MSSTAT	If MSPERF = "N", then MSSTAT = "NOT DONE". If MSPERF = "Y", MSSTAT is NULL.	(NY)	Yes;No;
2	MSCAT	What was the category of the microbiology susceptibility test?	Microbiology Susceptibility Category	Text	Record the microbiology susceptibility category, if not pre-printed on the CRF.	MSCAT		N/A		TUBERCULOSIS DRUG SUSCEPTIBILITY			Y
3	NHOID	What was the Non- host Organism ID?	Non-host Organism ID	Text	Record the identifier for a non-host organism that is the subject of the test.	SUPPMS.QVAL	SUPPMS.QVAL where SUPPMS.QNAM = "NHOID" and SUPPMS.QLABEL="Non-host Organism ID"			Mycobacterium tuberculosis			Y
4	MSTEST	What was the Microbiology Susceptibility test name?	Microbiology Susceptibility Test Name	Text	Record the type or name of the microscopic examination, if not pre-printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MSTEST; MSTESTCD		(MBTEST)		Drug Susceptibility			Y
5	MSAGENT	What was the name of the agent for which resistance is being tested?	Agent	Text	Record the name of the agent for which resistance is tested	SUPPMS.QVAL	SUPPMS.QVAL where SUPPMS.QNAM = "MSAGENT" and SUPPMS.QLABEL="Microbiology Susceptibility Agent"		Isoniazid; Rifampicin; Streptomycin; Amikacin
6	MSCONC	What was concentration of the agent?	Agent Concentration	Text	Record the concentration of the agent.	SUPPMS.QVAL	SUPPMS.QVAL where SUPPMS.QNAM = "MSCONC" and SUPPMS.QLABEL="Agent Concentration"
7	MSCONCU	What was agent concentration unit?	Agent Concentration Unit	Text	Record the concentration unit of the agent.	SUPPMS.QVAL	SUPPMS.QVAL where SUPPMS.QNAM = "MSCONCU" and SUPPMS.QLABEL="Agent Concentration Unit"			ug/mL
8	MSORRES	What was the result of the susceptibility test?	Result	Text	Record test result, interpretation, or finding.	MSORRES	MSORRES where MSTEST="Drug Susceptibility"	N/A	Sensitive; Resistant

8.3.9 MI - Microscopic Findings

Description/Overview for the CDASHIG MI - Microscopic Findings Domain

The MI domain collects the histopathology findings and microscopic evaluations that do not have specialized domains (e.g., MB, MS) for their results.

MI domain metadata are provided for 2 different data collection scenarios. It is up to the sponsor to determine which data collection scenario best meets the study needs. (Sponsors may implement Scenario 3: Central Processing with Investigator Assessment of Clinical Significance Assessment for Abnormal Values following the example in Section 8.3.6, LB - Laboratory Test Results, even though such an example is not provided in the CDASHIG Metadata Table.)

• Scenario 1: Central Processing. In this scenario, subject specimens are taken at the site, sent out for processing, and results are provided directly to the sponsor and not recorded on the CRF. This scenario also applies when results are captured directly via an electronic device and not recorded on the CRF. CRF data are captured at the site for tracking/ header reconciliation. The fields for test results are not defined here, as these data are not part of the CRF.

• Scenario 2: Local Processing. In this scenario, subject specimens are taken and analyzed, and then the results are recorded directly on the CRF.

Specification for the CDASHIG MI - Microscopic Findings Domain

Microscopic Findings Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	MI	Central Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	MI	Central Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MI	Central Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participa nt] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MI	Central Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MI	Central Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	The date the Microscopic Findings were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microscopic Findings at that visit, or the collection date can be included on the Microscopic Findings CRF using the date (MIDAT) field.
Findings	MI	Central Processing	N/A	6	MIPERF	Microscopic Examination Performed	An indication of whether or not a planned microbiology measurement, series of microbiology measurements, test, or observation was performed or specimens collected.	Was the microscopic examination performed?	Microscopic Examination Performed	Char	O	Indicate whether or not microscopic examination performed.	MISTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MISTAT. If MIPERF="N", the value of MISTAT will be "NOT DONE". If MIPERF="Y", MISTAT should be null. A combination of SDTMIG variables (e.g., MICAT and MISCAT, MITPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MITESTCD would be populated as MIALL and an appropriate test name (MITEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. This general prompt question is used as a data management tool to verify that missing results are confirmed missing. For the SDTM submission dataset, the SDTMIG variable MISTAT is populated using the CDASH field MIPERF. The question text used might be reflected in the reason not done (MIREASND).
Findings	MI	Central Processing	N/A	7	MIREFID	MI Reference ID	An internal or external identifier such as specimen identifier.	What was the (microscopic test) [reference identifier/accession number]?	(Microscopic test) [Reference Identifier/ Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MIREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to confirm that the appropriate data record is present in the electronic transfer. May be included for linking back to specimens (e.g., Specimen ID).
Findings	MI	Central Processing	N/A	8	MIDAT	Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the specimen collection?	Collection Date	Char	R/C	Record the date when specimen collection occurred using this format (DD-MON- YYYY).	MIDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	MI	Central Processing	N/A	9	MITIM	Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the specimen collection?	Collection Time	Char	R/C	Record time of collection (as complete as possible).	MIDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on 1 day or when the timing in relationship to study treatment is required for analysis.
Findings	MI	Central Processing	N/A	10	MICAT	Category for Microscopic Finding	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the microscopic finding?	[Microscopic Category]; NULL	Char	O	Record the microscopic finding category, if not preprinted on the CRF.	MICAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MI	Central Processing	N/A	11	MISCAT	Subcategory for Microscopic Finding	A sub-division of the MICAT values based on user-defined characteristics.	What was the subcategory of the microscopic finding?	[Microscopic Subcategory]; NULL	Char	O	Record the microscopic finding subcategory, if not preprinted on the CRF.	MISCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MISCAT can only be used if there is an MICAT and it must be a subcategorization of MICAT.
Findings	MI	Central Processing	N/A	12	MISPEC	MI Specimen Material Type	Defines the type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	R/C	Record the specimen material type.	MISPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MI	Central Processing	N/A	13	MISPCCND	MI Specimen Condition	Describes the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	R/C	Record condition of specimen.	MISPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MI	Central Processing	N/A	14	MILOC	MI Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location from which the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MILOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	MI	Central Processing	N/A	15	MILAT	MI Specimen Laterality within Subject	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MILAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MI	Central Processing	N/A	16	MIDIR	MI Specimen Directionality within Subjct	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MIDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MI	Local Processing	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	MI	Local Processing	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	MI	Local Processing	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participa nt] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	MI	Local Processing	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	MI	Local Processing	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	The date the Microscopic Findings were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the Microscopic Findings at that visit, or the collection date can be included on the Microscopic Findings CRF using the date (MIDAT) field.
Findings	MI	Local Processing	N/A	6	MIPERF	Microscopic Examination Performed	An indication of whether or not a planned microbiology measurement, series of microbiology measurements, test, or observation was performed or specimens collected.	Was the microscopic examination performed?	Microscopic Examination Performed	Char	O	Indicate whether or not microscopic examination performed.	MISTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable MISTAT. If MIPERF="N", the value of MISTAT will be "NOT DONE". If MIPERF="Y", MISTAT should be null. A combination of SDTMIG variables (e.g., MICAT and MISCAT, MITPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable MITESTCD would be populated as MIALL and an appropriate test name (MITEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for an entire panel. This general prompt question is used as a data management tool to verify that missing results are confirmed missing.
Findings	MI	Local Processing	N/A	7	MIREFID	MI Reference ID	An internal or external identifier such as specimen identifier.	What was the (microscopic test) [reference identifier/accession number]?	(Microscopic test) [Reference identifier/ Accession Number]	Char	O	Record the specimen [accession/reference] number assigned.	MIREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to reconcile CRF data. May be included for linking back to specimens (e.g., Specimen ID).
Findings	MI	Local Processing	N/A	8	MISPID	MI Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	MISPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	MI	Local Processing	N/A	9	MIDAT	Specimen Collection Date	The date of specimen collection, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the specimen collection?	Collection Date	Char	R/C	Record the date of specimen collection using this format (DD- MON-YYYY).	MIDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A A	complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	MI	Local Processing	N/A	10	MITIM	Specimen Collection Time	The time of specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the (start) time of the specimen collection?	Collection Time	Char	R/C	Record time of collection (as complete as possible).	MIDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable MIDTC in ISO 8601 format.	N/A	N/A	May be required when multiple assessments are done on one day or when the timing in relationship to study treatment is required for analysis.
Findings	MI	Local Processing	N/A	11	MICAT	Category for Microscopic Finding	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the microscopic finding?	[Microscopic Category]; NULL	Char	O	Record the microscopic finding category, if not preprinted on the CRF.	MICAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	MI	Local Processing	N/A	12	MISCAT	Subcategory for Microscopic Finding	A sub-division of the MICAT values based on user-defined characteristics.	What was the subcategory of the microscopic finding?	[Microscopic Subcategory]; NULL	Char	O	Record the microscopic finding subcategory, if not preprinted on the CRF.	MISCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. MISCAT can only be used if there is an MICAT and it must be a subcategorization of MICAT.
Findings	MI	Local Processing	N/A	13	MITEST	Microscopic Examination Name	Descriptive name of the microscopic test or examination used to obtain the measurement or finding.	What [is/was] the name (of the microscopic [measurement/test/exa mination])?	[Microscopic Measurement/Te st/ Examination Name]	Char	HR	Record the type or name of the microscopic examination, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	MITEST; MITESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable MITESTCD may be determined from the value collected in MITEST. Both MITESTCD and MITEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(MITS)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	MI	Local Processing	N/A	14	MITSTDTL	Microscopic Examination Detail	Detail of the microscopic examination used to obtain the measurement or finding.	What [is/was] the [microscopic measurement/test/exa mination] detail name?	[Examination Name Detail]	Char	O	Record the detail of the microscopic examination, if not preprinted on the CRF.	MITSTDTL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(MIFTSDTL)	N/A	Provides additional details for the microscopic examination. It is recommended that the test detail be preprinted on the CRF. If the form is laid out as a grid, then words such as "Test Detail" can be included as the column header.
Findings	MI	Local Processing	N/A	15	MIORRES	MI Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the examination?	(Result)	Char	HR	Record test result, interpretation or finding.	MIORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	MI	Local Processing	N/A	16	MIORRESU	MI Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	MIORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Should be included if applicable and not available elsewhere. For some tests the units may not be applicable (e.g., reaction score for HER2).
Findings	MI	Local Processing	N/A	17	MICLSIG	MI Clinical Significance	An indication whether the test results were clinically significant.	Was the result clinically significant?	Clinically Significant	Char	O	Indicate whether the results were clinically significant.	SUPPMI.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPMI dataset as the value of SUPPMI.QVAL where SUPPMI.QNAM="MICLSIG" and SUPPMI.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	N/A
Findings	MI	Local Processing	N/A	18	MIRESCAT	MI Result Category	Used to categorize the result of a finding.	What was the result category?	Result Category	Char	O	Record the category of the test results.	MIRESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Used to categorize the results of a finding (e.g., MALIGNANT or BENIGN, RESISTANCE VARIANT for genetic variation).
Findings	MI	Local Processing	N/A	19	MINAM	Laboratory/Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the vendor used?	Vendor Name	Char	O	Record the laboratory name.	MINAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if lab names was not collected at the site/study level or if multiple labs are used by a site.
Findings	MI	Local Processing	N/A	20	MISPEC	MI Specimen Material Type	Defines the type of specimen used for a measurement.	What is the specimen material type?	Specimen Type	Char	R/C	Record the specimen material type.	MISPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	MI	Local Processing	N/A	21	MISPCCND	MI Specimen Condition	Describes the condition of the specimen.	What was the condition of the specimen?	Specimen Condition	Char	R/C	Record condition of specimen.	MISPCCND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. This can be used when results may be affected by whether conditions for specimen were properly met.
Findings	MI	Local Processing	N/A	22	MILOC	MI Specimen Collection Location	A description of the anatomical location of the subject relevant to the collection of specimen.	What was the anatomical location from which the specimen was collected?	Anatomical Location	Char	O	Record or select the anatomical location of specimen collection.	MILOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	MI	Local Processing	N/A	23	MILAT	MI Specimen Laterality within Subject	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the specimen collection?	Side	Char	O	Record the side of the anatomical location of the specimen collection.	MILAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MI	Local Processing	N/A	24	MIDIR	MI Specimen Directionality within Subjct	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the specimen collection?	Directionality	Char	O	Record the directionality of the anatomical location of the specimen collection.	MIDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	MI	Local Processing	N/A	25	MIMETHOD	MI Method of Test or Examination	Method of the test or examination.	What was the method used for the test or examination?	Method	Char	O	Record the method of test or examination.	MIMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than one method is possible, and collecting the method used is necessary. This could include technique or type of staining used for the slides.
Findings	MI	Local Processing	N/A	26	MIEVAL	MI Evaluator	The role of the person who provided the evaluation.	Who was the evaluator?	[Evaluator/Report er]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	MIEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.

Assumptions for the CDASHIG MI - Microscopic Findings Domain

1. This domain is used for findings resulting from the microscopic examination of tissue samples. These examinations are performed on a specimen which has been prepared with some type of stain. Some examinations of cells in fluid specimens (e.g., blood, urine) are classified as lab tests and should be represented in the LB domain. Tests classified as pathology or cytology should be represented in the MI domain. Biomarkers assessed by histologic or histopathological examination (by employing cytochemical/immunocytochemical stains) will be represented in the MI domain.

2. Sponsors should decide which scenario is appropriate for each protocol.

3. The variable MITSTDTL is used when biomarker tests are represented in the MI domain. It represents test parameter details descriptive of slide stain results (e.g., cells at 1+ intensity cytoplasm stain, H-Score, nuclear reaction score).

4. These CDASHIG variables are generally not used for this domain: --POS, --MODIFY, --ORNRLO, --ORNRHI, --LEAD.

Example CRFs for the CDASHIG MI - Microscopic Findings Domain

Example 1

Title: Microscopic Findings-Programmed Death Ligand



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
MIPERF	1	Was the microscopic examination performed?	Microscopic Examination Performed	Indicate whether or not the microscopic examination was performed.	Text	MISTAT	If MIPERF = "N", then MISTAT = "NOT DONE" and MITESTCD = "MIALL". If MIPERF = "Y", then MISTAT is NULL.	(NY)	Yes; No		Qtext
MIDAT	6	What was the specimen collection date?	Collection Date	Record the date when specimen collection occurred using this format (DD-MON-YYYY).	Date	MIDTC
MILOC	3	What was the anatomical location were the specimen was collection?	Anatomical Location	Record or select the anatomical location of specimen collection.	Text	MILOC		(LOC)		LUNG			Y
MIMETHOD	4	What was the method used for the test or examination?	Method	Record the method of test or examination.	Text	MIMETHOD		(METHOD)		IHC			Y
MITEST	5	What was the microscopic examination test name?	Microscopic Test Name	Record the type or name of the microscopic examination, if not pre- printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	MITEST		(MITEST)		Programmed Death Ligand 1	Y
MISPEC	2	What is the specimen material type?	Specimen Type	Record the specimen material type.	Text	MISPEC		(SPECTYPE)		TISSUE			Y
MISPID	7	What is the microscopic test identifier?	[Line Number/ MI Number]	If collected on the CRF, the sponsor may insert instructions to ensure each record has a unique identifier.	Text	MISPID
MIORRES_PDL1	9	What is the PDL1 Tumor Proportion Score?	Result	Record test result, interpretation, or finding.	integer	MIORRES	MIORRES where MITESTCD="PDL1" and MITSTDTL = "TUMOR PROPORTION SCORE."
MIORRESU_PDL1	10	What was the unit of the result?	Unit	Record or select the original unit in which these data were collected, if not pre- printed on CRF.	Text	MIORRESU		(UNIT)		%

Example 2

Title: Histopatholgy-Lung Specimen Collection



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
MICAT	1	What was the category of the microscopic finding?	Microscopic Category	Record the microscopic finding category, if not pre- printed on the CRF.	Text	MICAT				HISTOPATHOLOGY	Prompt		Y
MIPERF	2	Was the microscopic examination performed?	Microscopic Examination Performed	Indicate whether or not microscopic examination performed.	Text	MISTAT	If MIPERF = "N", then MISTAT = "NOT DONE" and MITESTCD = "MIALL". If MIPERF = "Y", then MISTAT is NULL.	(NY)	Yes; No			Radio
MIDAT	3	What was the specimen collection date?	Collection Date	Record the date when specimen collection occurred using this format (DD-MON-YYYY).	Date	MIDTC					Prompt
MITIM	4	What was the time of the specimen collection?	Collection Time	Record time of collection (as complete as possible).	Time	MIDTC					Prompt
MIREFID	5	What was the accession number?	Accession Number	Record the specimen accession number assigned.	Text	MIREFID
MISPEC	6	What is the specimen material type?	Specimen Type	Record the specimen material type.	Text	MISPEC		(SPECTYPE)		Tissue		Radio
MISPCCND	9	What was the condition of the specimen?	Specimen Condition	Record condition of specimen.	Text	MISPCCND		(SPECCOND)	Fresh; Frozen			Radio
MILOC	7	What was the anatomical location were the specimen was collection?	Anatomical Location	Record or select the anatomical location of specimen collection.	Text	MILOC		(LOC)		Lung	Prompt	Radio
MILAT	8	What was the side of the anatomical location of the specimen collection?	Side	Record the side of the anatomical location of the specimen collection.	Text	MILAT		(LAT)	Left; Right			Radio

8.3.10 PC - Pharmacokinetics Sampling

Description/Overview for the CDASHIG PC - Pharmacokinetics Concentrations Domain

Information about sampling for pharmacokinetic (PK) concentration is collected on CRFs with the goal to reconcile or link sampling information (e.g., collection timing and specimen volumes) with PK concentration results provided by the laboratory. SDTMIG PC records are compiled when joining CRF sampling information and PK concentration results. This is similar to Scenario 1 in Section 8.3.6, LB - Laboratory Test Results.

The goals of the CDASHIG PC domain are:

• To standardize specimen collection details in the CRF for PK samples collected at fixed time points or over timed intervals.

• To document the data flow from the CDASHIG CRF to the SDTMIG PC dataset.

The CDASHIG PC domain defines fields for:

• The date and time of PK sample collections

o Either at fixed defined time points (e.g., 4 HRS POSTDOSE) or across a collection interval (e.g., 2-4 HRS POSTDOSE).

o How the body metabolizes and clears the analyte often determines which of these sampling approaches may be required.

• Sample properties (e.g., pH, sample volume)

Samples collected to measure drug concentration at an instant in time are generally associated with specimen types such as plasma, serum, or whole blood. Samples collected over a timed interval are generally associated with specimen types such as urine or feces.

PK Sample Collection at Fixed Time Points

In the case of fixed time points, the date (PCDAT) and time (PCTIM) of collection for each sample is recorded on the CRF. The protocol defines the time points at which samples are to be collected in relation to an intervention such as a dose of study treatment. This "reference" is depicted in Figure 1 by the longer vertical line and would correspond to a date and time in the Exposure as Collected (EC) or Exposure (EX) domain.

Figure 1. PK Sample Collection at Fixed Time Points



PK Sample Collection Over a Time Interval

Similarly, for PK specimens collected to measure drug excretion over a time interval, PCDAT and PCTIM capture the start date and time of the interval collection. End date (PCENDAT) and end time (PCENTIM) capture the end of the timed interval collection. As with fixed-time point collections, these timed intervals are performed in relation to an intervention such as a dose of study treatment. This "reference" is depicted in Figure 2 by the longer vertical line and would correspond to a date and time in the EC or EX domain.

Figure 2. Sample Collection Over a Time Interval



CDASHIG-SDTMIG PK Data Flow

The following concept map illustrates the data flow from PK sample collection at the site through the tabulation of both PK concentration and PK parameter results.

Concept Map. CDASHIG-SDTMIG PK Data Flow



Specification for the CDASHIG PC - Pharmacokinetic Concentrations Domain

Pharmacokinetic Concentrations Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/ Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	The date the PK samples were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the PK samples at that visit, or the collection date can be collected on the PK CRF using the date (PCDAT) field.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	6	PCPERF	PK Sampling Performed	An indication whether or not PK samples were collected.	Were PK samples collected?	Collected	Char	O	Check "No" if none of the samples were collected.	PCSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable PCSTAT. If PCPERF="N", the value of PCSTAT will be "NOT DONE". If PCPERF="Y", PCSTAT should be null. PCTEST and PCTESTCD must reflect what tests were not done. A combination of SDTMIG variables ( e.g., PCCAT and PCSCAT, PCTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable PCTESTCD would be populated as PCALL and an appropriate test name (PCTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	General prompt question to be used as a data management tool to verify that missing results are confirmed missing. This may be implemented at form level or sample level. These may be all samples of a particular type or all samples taken for some purpose and may need to be identified by the organization of the data on the form. Each sample collected could result in 1 or more tests performed, so there can be a one-to-one or one-to-many relationship between samples and tests/results.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	7	PCSTAT	PK Sampling Completion Status	The variable used to indicate that data are not available by having the site recording the value as "Not Done".	Record Not Done ifthe PK sample was not collected.	Not Done	Char	HR	Indicate if the specimen was not done.	PCSTAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ND)	N/A	A Not Done check box, which indicates the test was "NOT DONE". Typically, there would be one check box for each measurement. This field can be useful on individual sample collections to confirm that a blank result field is meant to be blank.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	8	PCREASND	PK Sampling Reason Not Done	An explanation of why the data are not available.	What was the reason the PK sample was not collected?	Reason Not Collected	Char	O	Provide the reason why a PK sample was not collected.	PCREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor-defined list (e.g., broken equipment, subject refused) or entered as free text. When PCREASND is used, the SDTMIG variable PCSTAT should also be populated in the SDTM-based dataset.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	9	PCDAT	PK Sample Collection Date	The date of PK sample collection or the start date of PK sample collection over a period of time (protocol-defined time-point range), represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the date of the PK sample collection?	Collection Date	Char	HR	Record the date when PK sample collection occurred using this format (DD-MON-YYYY). If left blank, "PCDATFL" for this specimen must be populated (or "PCPERF" must be flagged to indicate this sample was not collected).	PCDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The date of collection may be determined from the date of visit (VISDAT) and if so, a separate assessment date field is not required. The SDTMIG PCDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	10	PCDATFL	PK Sampling Date Flag	Flag indicating that the PK date (or start date) is the same as the previous specimen collection date (or start date).	Was the specimen/sample collected on the same date as the [last/previous specimen/sample] [collected/collection ended]?	Same as Previous (Specimen/Sample Collection End) Date	Char	O	Select when the date of this specimen collection is the same as the date of the previous specimen collected. If left blank, "PCDAT" for this specimen must be populated. (or "PCPERF" must be flagged to indicate this sample was not collected)	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	N/A	N/A	When a series of specimen are taken on a single form, this field is tied to the collection date to allow for the flag to be used as a surrogate for the date field. Its selection means that the date of this specimen is the same as the date of the last specimen collected (in the series). This variable may be used when collecting PK data and re-entering dates is more cumbersome than selecting the check box.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	11	PCTIM	PK Sample Collection Time	The time of PK sample collection or start time for a specimen collected over a period of time (protocol- defined time-point range), represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the PK sample collection?	Collection Time	Char	HR	Record time of collection (as complete as possible).	PCDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	A complete time is expected. The SDTMIG PCDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	12	PCTPT	PK Sampling Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the PK sample collection?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for the PK sample collection, if not preprinted on the CRF. Note: Planned time points are often described as relative to the dosing of the study drug.	PCTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors PCTPTREF (text description) and PCRFTDTC (date/time) may be needed, as well as SDTMIG variables PCTPTNUM, PCELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	13	PCFAST	PK Sampling Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	R/C	Record whether the subject was fasting prior to the test being performed.	PCFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. Some study treatments may have a food effect and it is important to know whether the dose was taken while the subject was fasted.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	14	PCCOND	PK Sampling Test Condition Met	Indication whether the testing conditions defined in the protocol were met (e.g., low-fat diet).	Were the protocol- defined testing conditions met?	Test Condition Met	Char	R/C	Record whether protocol defined testing conditions were met.	SUPPPC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPC dataset as the value of SUPPPC.QVAL where SUPPPC.QNAM ="PCCOND" and SUPP.PCLABEL= "Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	This information is collected when the test results may be affected by whether conditions for testing were properly met. The specific testing conditions required should be preprinted on the CRF (e.g., "Did subject meet diet requirements?"). This may not be relevant for all tests. Examples of conditions imposed may include: Calorie fast, Fluid fast, High-fat meal, Low-fat meal, or Exercise.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	15	PCREFID	PK Sampling Reference ID	An internal or external identifier (e.g., specimen identifier).	What was the (PK) [reference identifier/accession number]?	(PK) [Reference Identifier/Accession Number]	Char	O	Record the specimen or accession number assigned.	PCREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to reconcile CRF data. May be included for linking back to specimens (e.g., Specimen ID).
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	16	PCSPEC	PK Sampling Specimen Type	The type of specimen used for a PK sample.	What was the specimen (material) type?	[Specimen Type]	Char	HR	Record the specimen material type, if not preprinted on the CRF.	PCSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	17	PCTEST	PK Sampling Test Name	Descriptive name of the analyte or specimen characteristics used to obtain the PK measurement or finding.	What was the test name?	[Test Name]	Char	O	Record the name of the measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	PCTEST; PCTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable PCTESTCD may be determined from the value collected in PCTEST. The SDTMIG variables PCTESTCD and PCTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Sponsors typically collect tests related to the specimen characteristics on the CRF (e.g., Volume, Ph). Results for tests on an analyte (e.g., Concentration) would typically be populated when the SDTM- based datasets are created. If the analyte test results are collected on the CRF, the test would be the analyte name. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	18	PCORRES	PK Sampling Result in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the test?	(Result)	Char	O	Record the test result, interpretation or finding.	PCORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	PC	PK Sample Collection at Fixed Time Points	N/A	19	PCORRESU	PK Sampling Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	O	Record or select the original unit in which these data were collected, if not preprinted on CRF.	PCORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	PC	PK Sample Collection over a Time Interval	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	PC	PK Sample Collection over a Time Interval	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	PC	PK Sample Collection over a Time Interval	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What is the subject identifier?	Subject	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	PC	PK Sample Collection over a Time Interval	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	PC	PK Sample Collection over a Time Interval	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	The date the PK samples were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the PK samples at that visit, or the collection date can be collected on the PK CRF using the date (PCDAT) field.
Findings	PC	PK Sample Collection over a Time Interval	N/A	6	PCPERF	PK Sampling Performed	An indication whether or not PK samples were collected.	Were PK samples collected?	Collected	Char	O	Indicate that all of the PK samples in this group were collected.	PCSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable PCSTAT. If PCPERF="N", the value of PCSTAT will be "NOT DONE". If PCPERF="Y", PCSTAT should be null. PCTEST and PCTESTCD must reflect what tests were not done. A combination of SDTMIG variables (e.g., PCCAT and PCSCAT, PCTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable PCTESTCD would be populated as PCALL and an appropriate test name (PCTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This general prompt question is used as a data management tool to verify that missing results are confirmed missing. This may be implemented at form level or sample level. These may be all samples of a particular type or all samples taken for some purpose and may need to be identified by the organization of the data on the form. Each sample collected could result in 1 or more tests performed, so there can be a one-to-one or one-to-many relationship between samples and tests/results.
Findings	PC	PK Sample Collection over a Time Interval	N/A	7	PCREASND	PK Sampling Reason Not Done	An explanation of why the data are not available.	What was the reason the PK sample was not collected?	Reason Not Collected	Char	O	Provide the reason why a PK sample was not collected.	PCREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor-defined list (e.g., broken equipment, subject refused) or entered as free text. When PCREASND is used, the SDTMIG variable PCSTAT should also be populated in the SDTM-based dataset.
Findings	PC	PK Sample Collection over a Time Interval	N/A	8	PCDAT	PK Sample Collection Date	The date of PK sample collection or the start date of PK sample collection over a period of time (protocol-defined time-point range), represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the date of the PK sample collection?	Collection Date	Char	HR	Record the date when PK sample collection occurred using this format (DD-MON-YYYY). If left blank, "PCDATFL" for this specimen must be populated (or "PCPERF" must be flagged to indicate this sample was not collected).	PCDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. The SDTMIG PCDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	PC	PK Sample Collection over a Time Interval	N/A	9	PCTIM	PK Sample Collection Time	The time of PK sample collection or start time for a specimen collected over a period of time (protocol- defined time-point range), represented in an unambiguous time format (e.g., hh:mm:ss).	What was the start time of the PK sample collection?	Collection Start Time	Char	HR	Record start time of collection (as complete as possible).	PCDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PCDTC in ISO 8601 format.	N/A	N/A	A complete time is expected. In interval collection, start can be added as needed to the question text, prompt and CRF directions. The SDTMIG PCDTC variable contains either a date/time when a specimen is collected at a point in time or the start date/time, when a specimen is collected over time.
Findings	PC	PK Sample Collection over a Time Interval	N/A	10	PCENDAT	PK Sample Collection End Date	The end date of the specimen collection, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the end date of the specimen collection?	(Collection) End Date	Char	HR	Record the date when PK sample collection stopped using this format (DD-MON-YYYY).	PCENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable PCENDTC in ISO 8601 format.	N/A	N/A	The end date of specimen collection may be determined from the date of visit and if so, a separate assessment date field is not required.
Findings	PC	PK Sample Collection over a Time Interval	N/A	11	PCENTIM	PK Sample Collection End Time	The end time of the specimen collection, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the specimen collection end time?	(Collection) End Time	Char	HR	Record end time of collection (as complete as possible).	PCENDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH END DATE and TIME components and populate the SDTMIG variable PCENDTC in ISO 8601 format.	N/A	N/A	A complete end time is expected. The SDTMIG variable PCENDTC variable contains the end date/time, when a specimen is collected over time. If there is no end date/time, the SDTMIG variable PCENDTC should be Null.
Findings	PC	PK Sample Collection over a Time Interval	N/A	12	PCTPT	PK Sampling Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point of the PK sample collection?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for the PK sample collection, if not preprinted on the CRF. Note: Planned time points are often described as relative to the dosing of the study drug.	PCTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors PCTPTREF (text description) and PCRFTDTC (date/time) may be needed, as well as SDTMIG variables PCTPTNUM, PCELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as Planned Time Point can be included as the column header.
Findings	PC	PK Sample Collection over a Time Interval	N/A	13	PCFAST	PK Sampling Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	Was the subject fasting?	Fasting	Char	R/C	Record whether the subject was fasting prior to the test being performed.	PCFAST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. Some study treatments may have a food effect and it is important to know whether the dose was taken while the subject was fasted.
Findings	PC	PK Sample Collection over a Time Interval	N/A	14	PCCOND	PK Sampling Test Condition Met	Indication whether the testing conditions defined in the protocol were met (e.g., low fat diet).	Were the protocol- defined testing conditions met?	Test Condition Met	Char	R/C	Record whether protocol defined testing conditions were met.	SUPPPC.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPC dataset as the value of SUPPPC.QVAL where SUPPPC.QNAM ="PCCOND" and SUPP.PCLABEL= "Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	This information is collected when the test results may be affected by whether conditions for testing were properly met. The specific testing conditions required should be preprinted on the CRF (e.g., "Did subject meet diet requirements?"). This may not be relevant for all tests. Examples of conditions imposed may include: Calorie fast, Fluid fast, High-fat meal, Low-fat meal, or Exercise.
Findings	PC	PK Sample Collection over a Time Interval	N/A	15	PCREFID	PK Sampling Reference ID	An internal or external identifier (e.g., specimen identifier).	What was the (PK) [reference identifier/accession number]?	(PK) [Reference Identifier/Accession Number]	Char	O	Record the specimen or accession number assigned.	PCREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	This can be used to reconcile CRF data. May be included for linking back to specimens (e.g., Specimen ID).
Findings	PC	PK Sample Collection over a Time Interval	N/A	16	PCSPEC	PK Sampling Specimen Type	The type of specimen used for a PK sample.	What was the specimen (material) type?	Specimen Type	Char	HR	Record the specimen material type, if not preprinted on the CRF.	PCSPEC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	PC	PK Sample Collection over a Time Interval	N/A	17	PCTEST	PK Sampling Test Name	Descriptive name of the analyte or specimen characteristics used to obtain the PK measurement or finding.	What was the test name?	[Test Name]	Char	O	Record the name of the measurement or finding, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	PCTEST; PCTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable PCTESTCD may be determined from the value collected in PCTEST. The SDTMIG variables PCTESTCD and PCTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Sponsors typically collect tests related to the specimen characteristics on the CRF (e.g., Volume, pH). Results for tests on an analyte (e.g., Concentration) would typically be populated when the SDTM- based datasets are created. If the analyte test results are collected on the CRF, the test would be the analyte name. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	PC	PK Sample Collection over a Time Interval	N/A	18	PCORRES	PK Sampling Result in Original Units	Result of the measurement or finding as originally received or collected.	What was the result of the test?	(Result)	Char	O	Record the PK sampling test result.	PCORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive Findings or summaries may be recorded here.
Findings	PC	PK Sample Collection over a Time Interval	N/A	19	PCORRESU	PK Sampling Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	O	Record the PK sampling test result.	PCORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.

Assumptions for the CDASHIG PC - Pharmacokinetic Concentrations Domain

1. This domain contains details regarding the collection of the PK samples from subjects at the site (e.g., timing of sample collection and associated specimen properties). Typically, the CDASHIG PC domain does not include concentration results generated by the bioanalytical laboratory. However, if the sponsor has occasion to collect concentration results directly on the same CRF, variables may be created based on CDASH Model variables, using the rules previously discussed.

2. Other data may be needed for PK analysis, such as Demographics, Vital Signs, Substance Use, and Exposure. Refer to the appropriate CDASHIG sections for each of these domains.

Example CRFs for the CDASHIG PC - Pharmacokinetic Concentrations Domain

Example 1

Title: Pharmacokinetics



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
VISIT	1	What is the visit name?	Visit Name (defaulted)	N/A	Text	VISIT				Day 1	Prompt
PCSTAT	2	Indicate if the PK sample was not done.	Not Done	Indicate if the specimen was not done.	Text	PCSTAT		(ND)	Not Done		Prompt	checkbox
PCREASND	3	What was the reason the PK sample was not collected?	Reason Not Collected	Provide the reason why a PK sample was not collected.	Text	PCREASND					Prompt
PCREFID	4	What was the PK accession number?	Accession Number	Record the specimen or accession number assigned.	Text	PCREFID					Prompt
PCTPT	5	What was the planned time point of the PK sample collection?	Planned Time Point Name	Record the planned time point labels for the PK sample collection, if not pre- printed on the CRF. Note: Planned time points are often described as relative to the dosing of the study drug.	Text	PCTPT			Pre-dose; Hour 1; Hour 2; Hour 3		Prompt	radio
PCDATFL	6	Check if the specimen was collected on the same date as the previous specimen collected.	Same as Previous (Specimen Collection) Date	Select when the date of this specimen collection is the same as the date of the previous specimen collected. If left blank, "PCDAT" for this specimen must be populated.	Text	N/A			Same as Previous Date		Prompt	checkbox
PCDAT	7	What was the date of the PK sample collection?	Collection Date	Record the date when PK sample collection occurred using this format (DD-MON-YYYY). If left blank, "PCDATFL" for this specimen must be populated.	Date	PCDTC					Prompt
PCTIM	8	What was the time of the PK sample collection?	Collection Time	Record time of collection as complete as possible.	Time	PCDTC					Prompt
PCSPEC	9	What was the specimen material type?	Specimen Type	Record the specimen material type, if not pre-printed on the CRF.	Text	PCSPEC		(SPECTYPE)	BLOOD; PLASMA; URINE		Prompt
PCORRES	10	What was the result of the volume measurement?	Volume	Record the result of the volume measurement.	Float	PCORRES	PCORRES where PCTESTCD = "VOLUME"				Prompt
PCORRESU	11	What was the unit of the result?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on the CRF.	Text	PCORRESU	PCORRESU where PCTESTCD = "VOLUME"	(UNIT)	mL; L		Prompt	radio

Example 2

Title: Pharmacokinetics



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
PCREFID	1	What was the (PK) [reference identifier/accession number]?	Accession Number	Record the accession number assigned.	Text	PCREFID					Prompt
PCTPT	2	What was the planned time point of the PK sample collection?	Planned Time Point Name	Record the planned time point labels for the PK sample collection, if not pre-printed on the CRF. Note: Planned time points are often described as relative to the dosing of the study drug.	Text	PCTPT			0-4 Hours Post Dose; 4-8 Hours Post Dose; 8-12 Hours Post Dose; 12-16 Hours Post Dose; 16-20 Hours Post Pose; 20-24 Hours Post Dose		Prompt	radio
PCSTAT	3	Indicate if the PK sample was not done.	Not Done	Indicate if the specimen was not done.	Text	PCSTAT		(ND)	Not Done			checkbox
PCDAT	4	What was the date of the PK sample collection?	Collection Start Date	Record the date when PK sample collection occurred using this format (DD- MON-YYYY).	Date	PCDTC					prompt
PCTIM	5	What was the (start) time of the PK sample collection?	Collection Start Time	Record start time of collection (as complete as possible).	Time	PCDTC					prompt
PCENDAT	6	What was the end date of the specimen collection?	Collection End Date	Record the date when PK sample collection stopped using this format (DD- MON-YYYY).	Date	PCENDTC					prompt
PCENTIM	7	What was the specimen collection end time?	Collection End Time	Record end time of collection (as complete as possible).	Time	PCENDTC					prompt
PCSPEC	8	What was the specimen material type?	Specimen Type	Record the specimen material type, if not preprinted on the CRF.	Text	PCSPEC		(SPECTYPE)	Blood; Plasma; Urine		prompt	dropdown
PCORRES	9	What was the result of the volume measurement?	Volume	Record the result of the volume measurement.	Float	PCORRES	PCORRES where PCTESTCD = "VOLUME"				prompt
PCORRESU	10	What was the unit of the result?	Unit	Record or select the original unit in which these data were collected, if not preprinted on CRF.	Text	PCORRESU	PCORRES where PCTESTCD = "VOLUME"	(UNIT)	mL; L		prompt	radio

8.3.11 PE - Physical Examination

Description/Overview for the CDASHIG PE - Physical Examination Domain

The scope of the metadata for the PE domain is limited to general physical examinations as part of overall safety data collection. The data collection fields defined in the CDASHIG Metadata Tables may not fit the needs of targeted body system evaluations as part of therapeutic area-specific assessments. There are 3 scenarios that may be used for collecting physical exam data:

• Scenario 1 (Best Practice): The PE CRF is used 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 a medical history (MH) form, a targeted medical history form (e.g., a study-specific form requesting assessment of a predefined set of medical and/or surgical history events), or a baseline conditions form. Sites are typically instructed to record any post-baseline abnormalities or baseline conditions that worsened post-baseline on the adverse effects (AE) form.

• Scenario 2 (Traditional): The PE CRF is used at baseline and post-baseline visits.

• Scenario 3 (Traditional): The PE CRF is used 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 AE form.

In Scenarios 2 and 3, similar fields are captured: date of exam, body system/code, normal/abnormal, and description of abnormality. Scenario 1 is recommended as the best practice for the following reasons:

1. It 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, an MH form, or other similar form.

2. It reduces number of queries, thus reducing workload for data managers and site personnel.

3. It supports consistency and standardization for data reporting purposes. Physical examination data are rarely summarized, only tabulated in listing format. Any trend analysis or summarization of abnormalities is performed on AE data, and MH data are available for reference.

4. It reduces coding needs (if PE abnormalities are coded).

Best Practice Domain Model

Specification for the CDASHIG - Scenario 1 (Best Practice) Physical Examination

Scenario 1 is a change from the more traditional approach for the submission of physical examination data. In this approach, the SDTMIG PE domain is not submitted. The physical examination results are submitted in the appropriate SDTMIG domain using the following conventions:

• Screening/baseline results are submitted in the SDTMIG MH domain.

• Post-baseline abnormalities or baseline conditions that worsened are submitted in the SDTMIG AE domain.

• Sponsors may submit information on whether physical examinations were performed and when they were performed in the SDTMIG Procedures (PR) domain.

Note: There is no CDASH PE domain specification for this approach in the CDASHIG Metadata Table. Assumptions for the CDASHIG - Scenario 1 (Best Practice) Physical Examination

1. Because the data from a general physical examination are not required for safety or efficacy evaluations, a sponsor may decide not to collect them on a separate PE CRF. The data would be collected on other CRFs, typically the AE and MH CRFs.

2. If the sponsor chooses to create a physical examination CRF to capture only the information "Was the physical examination performed?" and Date/Time of Examination, these may be considered as optional fields intended for monitoring and data cleaning only. However, the sponsor could elect to submit this information in the SDTMIG PR domain.

Example CRF for the CDASHIG - Scenario 1 (Best Practice) Physical Examination

Example 1

The CDASH Physical Examination best practice recommends not submitting physical examination data in the SDTM PE domain. The record of a physical examination being performed may be recorded in the PR domain, as annotated below. Findings from a physical examination should be reported in the AE or MH domain, depending on whether the finding/abnormality started before or after the protocol-specified time period.

Title: Physical Examination-Scenario 1 (Best Practice)

Example CRF Completion Instructions If the physical finding/abnormality started prior to [protocol-specific time period], then it must be recorded as Medical History. If the physical finding started after [protocol-specific time period], it must be recorded as an Adverse Event.



Traditional Domain Models

Specification for the CDASHIG PE -Scenarios 2 and 3 (Traditional) Physical Examination Domain

In Scenarios 2 and 3, the sponsor may elect to submit physical exam results in the SDTMIG PE domain, following the more traditional approach for data collection. The CDASHIG Metadata Table includes this traditional PE scenario.

Physical Exam (PE) Scenarios 2 and 3 (Traditional) Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	PE	PE- Traditional	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	PE	PE- Traditional	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	PE	PE- Traditional	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	PE	PE- Traditional	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	PE	PE- Traditional	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable PEDTC in ISO 8601 format.	N/A	N/A	The date of the physical examination can be determined from the Visit Date variable (VISDAT) and applying that date to all of the physical examination findings at that visit, or the collection date can be included collected on the PE CRF using the date (PEDAT) field.
Findings	PE	PE- Traditional	N/A	6	PEPERF	Physical Examination Performed	An indication whether or not a planned physical examination was performed.	Was the physical examination performed?	Physical Exam Performed	Char	O	If physical examination was performed as planned then select Yes, otherwise, select No.	PESTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable PESTAT. If PEPERF="N" the value of PESTAT="NOT DONE". If PEPERF="Y", then the actual physical exam results would be reported by body system (see PERES). PECAT, PESCAT, PETEST and PETESTCD must reflect what tests were not done. If used for an entire CRF or other set of multiple tests with PECAT and PESCAT, PETESTCD=PEALL.	(NY)	N/A	This general prompt question is used as a data management tool to verify that missing results are confirmed missing. Used to ask if the physical exam was performed at the overall subject level 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 overall examination was performed, then the value of PESTAT would be null for each examined body systems and "NOT DONE" for any body systems not examined (see PERES).
Findings	PE	PE- Traditional	N/A	7	PECAT	Category for Examination	A grouping of topic- variable values based on user- defined characteristics.	What was category of the physical examination?	[PE Category]; NULL	Char	O	Record the physical examination category, if not preprinted on the CRF.	PECAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. The CRF can capture the different types of Physical Exams using PECAT (e.g., GENERAL, OPHTHAMOLOGIC, NEUROLOGICAL). This may be preprinted on the CRF. If PECAT is not collected (e.g., it is self- evident from the protocol design), it could be populated during the SDTM-based dataset creation process.
Findings	PE	PE- Traditional	N/A	8	PESCAT	Subcategory for Examination	A sub-division of the PECAT values based on user- defined characteristics.	What was subcategory of the physical examination?	[PE Subcategory]; NULL	Char	O	Record the physical examination subcategory, if not preprinted on the CRF.	PESCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. The CRF can capture the different subtypes of PE categories using PESCAT. This may be preprinted on the CRF. If PESCAT is not collected (e.g. it is self-evident from the protocol design), it could be populated during the SDTM-based dataset creation process. PESCAT can only be used if there is a PECAT and it must be a subcategorization of PECAT.
Findings	PE	PE- Traditional	N/A	9	PEDAT	Physical Examination Date	The date when the physical examination was performed, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the date of the physical examination?	Exam Date	Char	R/C	Record complete date of examination using this format (DD-MON-YYYY).	PEDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PEDTC in ISO 8601 format.	N/A	N/A	The date of examination may be determined from the date of the visit (VISDAT) and if so, a separate assessment date field is not required.
Findings	PE	PE- Traditional	N/A	10	PETIM	Physical Examination Time	The time of examination, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the physical examination?	Exam Time	Char	O	Record the time of examination (as complete as possible).	PEDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable PEDTC in ISO 8601 format.	N/A	N/A	Collect time if it is relevant for the analysis.
Findings	PE	PE- Traditional	N/A	11	PESPID	Physical Exam Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	PESPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	PE	PE- Traditional	N/A	12	PETEST	Body System Examined	Name of the body system.	What was the body system examined?	[Body System]	Char	HR	Per protocol, perform physical examinations of specified body systems.	PETEST; PETESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable PETESTCD may be determined from the value collected in PETEST.	N/A	N/A	Sponsor should pre-print all body systems to be examined on the CRF. The use of a complete list of body systems eliminates the need for another, specify category as any abnormalities identified should fall under 1 of the prespecified categories. If the form is laid out as a grid, then words such as "Body System" can be included as the column header.
Findings	PE	PE- Traditional	N/A	13	PERES	Physical Exam Verbatim Finding	Overall assessment of examined body system.	Were the results normal, abnormal, or not done?	(Result)	Char	HR	Indicate the overall assessment for each exam category/body system listed.	PEORRES	This does not map directly to an SDTMIG variable. May be used to populate a value into the SDTMIG variable PEORRES. If PERES="Normal", populate PEORRES with the value of PERES. If PERES="Abnormal", populate PEORRES with the value of PEDESC.	N/A	N/A	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 (PEDESC). If the sponsor's data collection system allows for up- front recording of the abnormality and status using a single variable, then the SDTM variable name PEORRES may be used in place of CDASH variable names PERES and PEDESC. When the SDTM- based datasets are created, PESTRESC is the standardized value for PEORRES and is populated for any record where PEORRES is not null. If the abnormal findings are coded using a dictionary, then PESTRESC should be the dictionary preferred term or if not coded PEORRES.
Findings	PE	PE- Traditional	N/A	14	PEDESC	Physical Exam Abnormal Findings	Text description of any abnormal findings.	If the result was abnormal, what were the findings?	Abnormal Findings	Char	HR	Record all abnormal findings for the given body system in the space provided.	PEORRES	This does not map directly to an SDTMIG variable. May be used to populate a value into the SDTMIG variable PEORRES. If PERES="Normal", populate PEORRES with the value of PERES. If PERES="Abnormal", populate PEORRES with the value of PEDESC.	N/A	N/A	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 (PEDESC). If the sponsor's data collection system allows for up front recording of the abnormality and status using a single variable then the SDTM variable name PEORRES may be used in place of CDASH variable names PERES and PEDESC.
Findings	PE	PE- Traditional	N/A	15	PECLSIG	Physical Exam Clinical Significance	An indication whether the physical examination abnormality is clinically significant.	Was the physical examination result clinically significant?	Clinically Significant	Char	O	Was the physical examination result clinically significant? If Yes select Yes, otherwise, select No.	SUPPPE.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPPE dataset as the value of SUPPPE.QVAL where SUPPPE.QNAM ="PECLSIG" and SUPPPE.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	If this level of information is needed for reconciliation with adverse events, this field may be added to the CRF.
Findings	PE	PE- Traditional	N/A	16	PEEVAL	Physical Exam Evaluator	The role of the person who provided the evaluation.	Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	PEEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	PE	PE- Traditional	N/A	17	PEREASND	Physical Exam Reason Not Examined	An explanation of why the data are not available.	What is the reason that data was not collected?	Reason Not Done	Char	O	Provide the reason the assessment was not done.	PEREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Captures the reason why the measurement or test was not done. The reason may be chosen from a sponsor-defined list (e.g., broken equipment, subject refused) or entered as free text.
Findings	PE	PE- Traditional	N/A	18	PEBODSYS	Body System or Organ Class	Body System or Organ Class that is involved for a finding from the standard hierarchy for dictionary-coded results.	What is/was the [body system/ organ system]?	[Body System/Organ System]	Char	O	N/A	PEBODSYS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	PEBODSYS should be assigned using a coding system. If included on the CRF, it is prepopulated and must be paired by the sponsor with specific prespecified verbatim terms. If not included on the CRF, PEBODSYS is assigned through the coding process.
Findings	PE	PE- Traditional	N/A	19	PEMODIFY	Physical Exam Modified Reported Term	If the value for PEORRES is modified for coding purposes, then the modified text is placed here.	N/A	N/A	Char	O	N/A	PEMODIFY	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This is not a data collection field that would appear on the CRF. Sponsors will populate this through the coding process. PEMODIFY contains any modified text used for coding. Used only when the reported abnormalities in PEORRES are coded to a dictionary. This is in contrast to Events and Interventions domains where the topic variable (TERM or TRT) is modified for coding.
Findings	PE	PE- Traditional	N/A	20	PELOC	Location of Physical Exam Finding	A description of the anatomical location of the subject relevant to the collection of physical examination.	What was the anatomical location of the body system examined or the finding?	Anatomical Location	Char	O	Indicate the anatomical location of the abnormal finding.	PELOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	PE	PE- Traditional	N/A	21	PELAT	Physical Exam Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the body system examined or the finding?	Side	Char	O	Record the side of the anatomical location of the abnormal finding.	PELAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	PE	PE- Traditional	N/A	22	PEDIR	Physical Exam Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the of the body system examined or the finding?	Directionality	Char	O	Record the directionality of the anatomical location of the abnormal finding.	PEDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	PE	PE- Traditional	N/A	23	PEPORTOT	PE Location Portion or Totality	Qualifier for anatomical location further detailing the distribution, which means arrangement of, apportioning of.	What was the portion or totality of the anatomical location of the body system examined or the finding?	or Totality	Char	O	Indicate the proportionality of the anatomical location of the of the abnormal finding.	PEPORTOT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	PE	PE- Traditional	N/A	24	PEMETHOD	PE Method of Test or Examination	Method of the test or examination.	What was the method used for the test or examination?	Method	Char	O	Record the method of test or examination.	PEMETHOD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	This information may be collected when more than 1 method is possible, and collecting the method used is necessary.

Assumptions for the CDASHIG PE - Scenarios 2 and 3 (Traditional) Physical Examination Domain

1. If the sponsor chooses to create a traditional PE CRF, PEYN is still considered an optional field intended for monitoring and data cleaning only. If a sponsor wants to document information about overall physical examination at the subject level that were not performed in the SDTM submission, this field is mapped to PESTAT. If PEPERF="N", then PECAT="GENERAL", PETEST="PHYSICAL EXAMINATION", PETESTCD="PEALL", and PESTAT="NOT DONE". If PEPERF="Y", then the actual physical examination results would be reported by body system (see PERES).

2. Original and Standardized Results

a. The CDASHIG variable PERES is used to collect test results or findings in the original units in character format as well as to collect the information on what specific body systems were not examined.

b. When the results of a test or examination are reported as Normal or Abnormal, a description of the abnormal finding may also be collected using the CDASHIG element PEDESC.

c. Information on what body system reviews were not done is mapped to the appropriate SDTMIG variables (i.e., PETEST, PETESTCD, PESTAT, with ORRES being NULL). The value of "NOT DONE" in CDASHIG variable PERES should not be mapped to the SDTMIG variable PEORRES.

d. The standardization of the original findings results is expected to be performed when the SDTM submission datasets are created. The SDTM mapping rules are provided in the CDASHIG Metadata Table.

3. Date of Collection is the date that the examination was performed. The SDTMIG variable PEDTC can be populated from the date of visit.

Example CRF for the CDASHIG PE - Scenarios 2 and 3 (Traditional) Physical Examination Domain

Example 1

Title: Body System Physical Examination

Example CRF Completion Instructions The physical examination must be performed by a qualified health care professional (i.e., MD, PA or NP) listed on the FDA form 1572. If the physical finding/abnormality started prior to/at [protocol-specific time period], then it must be recorded on the medical history page. If the physical finding/abnormality started after [protocol-specific time period], it must be recorded as an Adverse Event.





CRF Metadata

CDASHIG Variable	Order Number	Question Text	Prompt	Case Report Form Completion Instructions	Data Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	CRF Implementation Notes	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
PEPERF	1	Was the physical examination performed?	Physical Exam Performed	If physical examination was performed as planned then select Yes, otherwise, select No.	text	PESTAT	If PEPERF="N" the value of PESTAT="NOT DONE". If PEPERF="Y", PESTAT= NULL.	(NY)	If used for an entire CRF or other set of multiple tests with PECAT and PESCAT, PETESTCD=PEALL.	Yes; No;
PECAT	2	What was category of the physical examination?	[PE Category]; NULL	Record the physical examination category, if not pre-printed on the CRF.	text	PECAT		N/A			Sponsor Defined			Y
PEDAT	4	What was the date of the physical examination?	Exam Date	Record complete date of examination using this format (DD-MON-YYYY).	text	PEDTC		N/A				prompt
PESPID	6	[Sponsor defined question]	[Sponsor defined]	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	text	PESPID		N/A
PETEST	7	What was the body system examined?	[Body System]	Per protocol, perform physical examinations of specified body systems.	text	PETEST; PETESTCD		N/A
PERES	8	Were the results normal, abnormal or not done?	(Result)	Indicate the overall assessment for each exam category/body system listed.	text	PEORRES	If PERES="Normal", populate PEORRES with the value of PERES. If PERES="Abnormal", populate PEORRES with the value of PEDESC.	N/A		NORMAL; ABNORMAL; NOT DONE
PEDESC	9	If the result was abnormal, what were the findings?	Abnormal Findings	Record all abnormal findings for the given body system in the space provided.	text	PEORRES	If PERES="Normal", populate PEORRES with the value of PERES. If PERES="Abnormal", populate PEORRES with the value of PEDESC.	N/A
PECLSIG	10	Was the physical examination result clinically significant?	Clinically Significant	Was the physical examination result clinically significant? If Yes select Yes, otherwise, select No.	text	SUPPPE.QVAL	SUPPPE.QVAL where SUPPPE.QNAM ="PECLSIG" and SUPPPE.QLABEL="Clinically Significant".	(NY)		YES; NO
PEEVAL	11	Who was the evaluator?	[Evaluator/Reporter]	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	text	PEEVAL		(EVAL)
PEREASND	12	What is the reason that data was not collected?	Reason Not Done	Provide the reason the assessment was not done.	text	PEREASND		N/A
PEBODSYS	13	What was the body system/ organ system?	[Body System/Organ System]	N/A	text	PEBODSYS		N/A
PELOC	15	What was the anatomical location of the body system examined or the finding?	Anatomical Location	Indicate the anatomical location of the abnormal finding.	text	PELOC		(LOC)
PELAT	16	What was the side of the anatomical location of the body system examined or the finding?	Side	Record the side of the anatomical location of the abnormal finding.	text	PELAT		(LAT)		RIGHT; LEFT; BILATERAL
PEDIR	17	What was the directionality of the anatomical location of the of the body system examined or the finding?	Directionality	Record the directionality of the anatomical location of the abnormal finding.	text	PEDIR		(DIR)		UPPER; LOWER
PEMETHOD	19	What was the method used for the test or examination?	Method	Record the method of test or examination.	text	PEMETHOD		(METHOD)		CLINICAL EVALUATION; PATHOLOGICAL EVALUATION

8.3.12 QRS - Questionnaires, Ratings, and Scales

Description/Overview for the CDASHIG QRS - Questionnaires, Ratings, and Scales Domain

Questionnaires, ratings, and scales (QRS) are standardized and often validated instruments, and the data collected using them are represented in SDTMIG domains including Questionnaires (QS), Disease Response and Clin Classification (RS), and Functional Tests (FT). Refer to the SDTMIG or the QRS web page (https://www.cdisc.org/foundational/qrs) for complete information on these domains. CDISC publishes supplemental specifications called QRS Supplements, including example annotated CRFs (aCRFs) for many of these instruments. CDISC Operational Procedure 017 (https://www.cdisc.org/system/files/) describes the development methodology for new QRS terminology. Because the nature of QRS precludes implementers from modifying the published data collection structure, the CDASHIG Metadata Table does not include specifications for QRS. Instead, implementers should refer to instrument-specific QRS Supplements on the QRS web page for example aCRFs, instrument-specific assumptions, and data examples.

For definitions and descriptions of the different types of questionnaires, ratings, and scales, visit the QRS web page.

The released QRS documentation is maintained on the CDISC QRS web page.

Specification for the CDASHIG QRS - Questionnaires, Ratings, and Scales Domain

Reference the QRS Supplements posted on the QRS web page (https://www.cdisc.org/foundational/qrs) and the specifications for specific domains (QS, RS, and FT) in the SDTMIG.

Assumptions for the CDASHIG QRS - Questionnaires, Ratings, and Scales Domain

1. CDISC standards for QRS include controlled terminology for test codes (--TESTCD), test names (--TEST), standard timing values, standard results for database values, and an aCRF with SDTMIG domain variable names. These standards can be used to create an electronic data collection (EDC) structure following the same conventions that would be used for any Findings class domain. The SDTMIG QS, RS, and FT domains utilize a normalized data structure; that is, 1 variable (--TEST) is used to capture the test name and another variable (--ORRES) is used to capture the result. Even though these domain variables are presented as a normalized structure in the CDASHIG Metadata Table, implementers using a denormalized structure (1 variable for each test) should create variable names that mirror the values in QRS controlled terminology (e.g., QSTESTCD, RSTESTCD, FTTESTCD).

2. Electronic representations of QRS instruments should reflect the title, subheadings, and exact numbering and wording of questions as they appear in original versions.

3. Electronic response fields should allow either the original response (--ORRES) or coded value (--STRESC) to be input—but usually not both, to avoid discrepancies.

4. Checkboxes that appear on validated QRS instruments should remain checkboxes in the CRF/eCRF.

5. Copyrighted instruments may include the copyright notice on the eCRF/CRF. For more copyright Information about QRS instruments, see the QRS web page (https://www.cdisc.org/foundational/qrs).

6. Instrument-specific assumptions are included in the QRS Supplements posted on the QRS web page. http://www.cdisc.org/qrs

Example CRF for the CDASHIG QRS - Questionnaires, Ratings, and Scales Domain

Example 1

Title: European Quality of Life Five Dimension Five Level Scale Questionnaire (EQ-5D-5L)



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
QSCAT	1	What is the category of the questionnaire?	Category of Questionnaire	Record the questionnaire category, if not pre-printed on the CRF.	Text	QSCAT				EQ-5D-5L			Yes
QSPERF_EQ5D02	2	Was the European Quality of Life Five Dimension Five Level Scale Questionnaire performed?	EQ-5D-5L Performed	Please select Yes or No. If Yes, complete the rest of items in the EQ-5D-5L CRF. If No, complete the Reason Not Done and leave the rest of the CRF blank.	Text	N/A	IF QSPERF_EQ5D02 = "NO", THEN QSSTAT = "NOT DONE" WHERE QSTESTCD = "QSALL"	(NY)	No;Yes			radio
QSREASND_EQ5D02	3	What was the reason that the EQ- 5D-5L was not done?	Reason Not Done	If the EQ-5D-5L was not done, then choose from the available options the reason the questionnaire was not administered.	Text	QSREASND					Prompt
QSDAT_EQ5D02	4	What was the date the EQ-5D-5L was collected?	EQ-5D-5L Collection Date	Record the full date the assessment was completed using the format DD-MM-YYYY.	Date	QSDTC					Prompt
EQ5D0201_QSORRES	6	Mobility	EQ5D02-Mobility	Select the appropriate response from the list of available options that best describes your health TODAY.	Text	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0201"		I have no problems walking about; I have slight problems walking about; I have moderate problems walking about; I have severe problems walking about; I am unable to walk about			radio
EQ5D0202_QSORRES	7	Self-Care	EQ5D02-Self-Care	Select the appropriate response from the list of available options that best describes your health TODAY.	Text	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0202"		I have no problems washing or dressing myself; I have slight problems washing or dressing myself; I have moderate problems washing or dressing myself; I have severe problems washing or dressing myself; I am unable to wash or dress myself			radio
EQ5D0203_QSORRES	8	Usual Activities (e.g. work, study, housework, family or leisure activities)	EQ5D02-Usual Activities	Select the appropriate response from the list of available options that best describes your health TODAY.	Text	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0203"		I have no problems doing my usual activities; I have slight problems doing my usual activities; I have moderate problems doing my usual activities; I have severe problems doing my usual activities; I am unable to do my usual activities			radio
EQ5D0204_QSORRES	9	Pain / Discomfort	EQ5D02- Pain/Discomfort	Select the appropriate response from the list of available options that best describes your health TODAY.	Text	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0204"		I have no pain or discomfort; I have slight pain or discomfort; I have moderate pain or discomfort; I have severe pain or discomfort; I have extreme pain or discomfort			radio
EQ5D0205_QSORRES	10	Anxiety / Depression	EQ5D02- Anxiety/Depression	Select the appropriate response from the list of available options that best describes your health TODAY.	Text	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0205"		I am not anxious or depressed; I am slightly anxious or depressed; I am moderately anxious or depressed; I am severely anxious or depressed; I am extremely anxious or depressed			radio
EQ5D0206_QSORRES	11	Indicate how your health is today.	EQ5D02-EQ VAS Score	Indicate how good or bad your health is TODAY. Select a number from 0 to 100 that best represents your health today. 0 means the worst health you can imagine and 100 means the best health you can imagine.	integer	QSORRES	QSORRES WHERE QSTESTCD = "EQ5D0206"
QSEVAL	12	Who was the evaluator?	Evaluator		Text	QSEVAL				STUDY SUBJECT			Yes
QSEVINTX	13	Evaluation Interval Text	Evaluation Interval Text		Text	QSEVINTX				TODAY			Yes

For additional examples, see the aCRFs that are part of the QRS Supplements on the QRS web page (https://www.cdisc.org/foundational/qrs).

Example Data for the CDASHIG QRS - Questionnaires, Ratings and Scales Domain

See the examples in the QRS Supplements posted on the QRS web page (https://www.cdisc.org/foundational/qrs).

8.3.13 RP - Reproductive System Findings

Description/Overview for the CDASHIG RP - Reproductive System Findings Domain

The RP domain is used to collect all reproductive detail information about a subject, such as reproductive ability, reproductive history (e.g., number of previous pregnancies, number of births), pregnancy during the study, and so on. All reproductive system findings for a subject are contained in the RP domain rather than other SDTMIG domains. Although sponsors previously may have reported this information in the Subject Characteristics (SC) domain, this information is now consolidated into the RP domain.

Specification for the CDASHIG RP - Reproductive System Findings Domain

Reproductive System Findings Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	RP	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	RP	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	RP	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	RP	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	RP	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable RPDTC in ISO 8601 format.	N/A	N/A	The date the reproductive system findings were collected can be determined from the Visit Data variable (VISDAT) and applying that date to all of the reproductive system findings at that visit, or the collection date can be included on the RP CRF using the date (RPDAT) field.
Findings	RP	N/A	N/A	6	RPCAT	Category for Repro System Findings	A grouping of topic- variable values based on user-defined characteristics.	What was the category of the reproductive system?	[Reproductive System Category]; NULL	Char	O	Record the reproductive system category, if not preprinted on the CRF.	RPCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	RP	N/A	N/A	7	RPSCAT	Subcategory for Repro System Findings	A sub-division of the RPCAT values based on user-defined characteristics.	What was the subcategory of the reproductive system?	Reproductive System Subcategory]; NULL	Char	O	Record the reproductive system subcategory, if not preprinted on the CRF.	RPSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. RPSCAT can only be used if there is an RPCAT and it must be a subcategorization of RPCAT.
Findings	RP	N/A	N/A	8	RPPERF	Reproductive System Evaluation Performed	An indication whether or not a planned measurement, series of measurements, test, or observation was performed.	Was a reproductive system evaluation performed?	Reproductive System Evaluation Performed	Char	O	Indicate whether or not a planned reproductive system evaluation was done.	RPSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable RPSTAT. If the CDASH field RPPERF="N", the value of RPSTAT will be "NOT DONE". If RPPERF="Y", RPSTAT should be null. A combination of SDTMIG variables (e.g., RPCAT and RPSCAT, RPTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable RPTESTCD would be populated as RPALL and an appropriate test name (RPTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This may be implemented for a series of reproductive system evaluations, or a specific reproductive system test. This general prompt question is used as a data management tool to verify that missing results are confirmed missing.
Findings	RP	N/A	N/A	9	RPREASND	RP Reason Not Performed	An explanation of why the data are not available.	What was the reason the reproductive system test was not collected?	Reason Not Done	Char	O	Provide the reason the measurement or test was not done.	RPREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor-defined list (e.g., broken equipment, subject refused) or entered as free text. When PCREASND is used, the SDTMIG variable PCSTAT should also be populated in the SDTM-based dataset.
Findings	RP	N/A	N/A	10	RPYN	Any Reproductive System Findings	General prompt question regarding whether or not there are any reproductive system findings available.	Were there any reproductive system findings?	Any Reproductive System Findings	Char	O	Indicate if the there are reproductive system findings. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTMIG variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that all other fields on the CRF were deliberately left blank.
Findings	RP	N/A	N/A	11	RPSPID	RP Sponsor- Defined Identifier	A sponsor-defined identifier. In CDASH, This is typically used for preprinted or auto- generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	RPSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	RP	N/A	N/A	12	RPTEST	Reproductive System Findings Test Name	Descriptive name for Reproductive System Finding.	What is the reproductive finding name?	[Reproductive System Findings Test Name]	Char	HR	Record the name of the reproductive system finding if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	RPTEST; RPTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable RPTESTCD may be determined from the value collected in RPTEST. The SDTMIG variables RPTESTCD and RPTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(RPTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	RP	N/A	N/A	13	RPORRES	RP Result or Finding in Original Units	Result of the finding defined in reproductive system finding, as originally received or collected.	What was the result for the reproductive system question?	(Result)	Char	HR	Record reproductive system finding.	RPORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	RP	N/A	N/A	14	RPORRESU	RP Original Units	The unit of the result as originally received or collected.	What was the unit of the result?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	RPORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	RP	N/A	N/A	15	RPDAT	Reproductive System Finding Date	The date on which the reproductive system result or finding was collected, represented in an unambiguous date format (e.g., DD- MON-YYYY) .	What was the date the reproductive system question was collected?	Collection Date	Char	R/C	Record date of collection using this format (DD-MON- YYYY).	RPDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable RPDTC in ISO 8601 format.	N/A	N/A	This should be a complete date. The date of collection may be determined from the date of visit (VISDAT).

Assumptions for the CDASHIG RP - Reproductive System Findings Domain

Any information on medications related to reproduction (e.g., contraceptives, fertility treatments) should not be collected in the RP domain; instead, they will need to be collected in the Concomitant/Prior Medications (CM) domain.

Example CRF for the CDASHIG RP - Reproductive System Findings Domain

Example 1

Title: Reproductive System Findings



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
RPCAT	1	What was the category of the reproductive system?	Reproductive System Category	Record the reproductive system category, if not pre-printed on the CRF.	Text	RPCAT				FEMALE REPRODUCTIVE STATUS			Yes
RPYN	2	Were there any reproductive system findings?	Any Reproductive System Findings	Indicate if the there are reproductive system findings. If yes, include the appropriate details where indicated on the CRF.	Text	N/A		(NY)	Yes; No			radio
RPDAT	4	What was the date the reproductive system question was collected?	Collection Date	Record date of collection using this format (DD- MON-YYYY).	Date	RPDTC					Prompt
MENARAGE_RPORRES	5	What was the subject's menarche age?	Menarche Age	Record the subject's age at menarche.	Integer	RPORRES	RPORRES WHERE RPTESTCD = "MENARAGE"
MENARAGE_RPORRESU	6	What was the unit?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	RPORRESU	RPORRESU WHERE RPTESTCD = "MENARAGE"	(UNIT)		YEARS	Prompt
PREGNN_RPORRES	7	What was the number of pregnancies?	Number of Pregnancies	Record the number of pregnancies.	Integer	RPORRES	RPORRES WHERE RPTESTCD = "PREGNN"
BRTHLVN_RPORRES	8	What was the number of live births?	Number of Live Births	Record the number of live births.	Integer	RPORRES	RPORRES WHERE RPTESTCD = "BRTHLVN"
MENOAGE_RPORRES	9	What was the subject's menopause age?	Menopause Age	Record the subject's age at menopause.	Integer	RPORRES	RPORRES WHERE RPTESTCD = "MENOAGE"
MENOAGE_RPORRESU	10	What was the unit?	Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	RPORRESU	RPORRESU WHERE RPTESTCD = "MENOAGE"	(UNIT)		YEARS	Prompt

8.3.14 RS - Disease Response and Clin Classification

Description/Overview for the CDASHIG RS - Disease Response and Clin Classification Domain

The CDASHIG RS domain describes assessment of disease response to treatment or clinical classifications, which are often based on published criteria. Clinical classifications may be based solely on objective data from clinical records, or they may involve a clinical judgment or interpretation of the directly observable signs, behaviors, or other physical manifestations related to a condition or subject status.

Specification for the CDASHIG RS - Disease Response and Clin Classification Domain

Disease Response and Clin Classification Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/CDASH Codelist Name	Implementation Notes
Findings	RS	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	RS	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	RS	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	RS	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	RS	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD- MON-YYYY format.	N/A	This field is not an SDTM variable. If the date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM), concatenate the CDASH VISDAT/VISTIM components and populate the SDTMIG variable RSDTC in ISO 8601 format.	N/A	N/A	If the date the tests were collected can be determined from the Visit Date variable (VISDAT), apply that date to all of the tests at that visit, or the collection date can be collected on the CRF using the date (RSDAT). In this domain, it may not be appropriate to use the visit date as RSDTC.
Findings	RS	N/A	N/A	6	RSCAT	Category for Response or Clin Class	A grouping of topic-variable values based on user-defined characteristics.	What is the [category/ criteria] for the [disease response/clinical classification] or What is the [response/clinical classification] criteria?	[Disease Response/Clinical Classification Category]; NULL	Char	R/C	N/A	RSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	(CCCAT);(ONCRSCAT)	This is most commonly either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response is typically a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. There are separate codelists used for categorizations of records about oncology response criteria (ONCRCAT) or other clinical classification (CRSCAT). Collect if multiple clinical classifications, or disease responses are active in a single study/database; otherwise, information should be distinguished somewhere on a form (e.g., table name, title, tab).
Findings	RS	N/A	N/A	7	RSSCAT	Subcategory for Response or Clin Class	A sub-division of the RSCAT values based on user-defined characteristics.	What is the sub - category for the [disease response/clinical classification]?	[Disease Response/Clinical Classification Sub- Category]; NULL	Char	R/C	N/A	RSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. RSSCAT can only be used if there is an RSCAT and it must be a subcategorization of RSCAT.
Findings	RS	N/A	N/A	8	RSPERF	Response or Clin Class Performed	An indication whether or not a planned disease response or clinical classification assessment was performed.	Was the [(disease) response/clinical classification] assessment performed?	[Disease Response/Clinical Classification] Assessment	Char	O	Indicate whether or not the [disease response/clinical classification] assessment was performed.	RSSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTMIG variable RSSTAT. If RSPERF="N", the value of RSSTAT will be "NOT DONE". If RSPERF="Y", RSSTAT should be null. A combination of SDTMIG variables ( e.g., RSCAT and RSSCAT, RSTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable RSTESTCD would be populated as RSALL and an appropriate test name (RSTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	A Not Done check box, which indicates the test was "NOT DONE". Typically, there would be one check box for each measurement. This field can be useful to confirm that a blank result field is meant to be blank.
Findings	RS	N/A	N/A	9	RSREASND	Response or Clin Class Reason Not Done	An explanation of why the data are not available.	Why was the [disease response/clinical classification] assessment not performed?	Reason Response Assessment Not Performed	Char	O	If the response was not collected, indicate why.	RSREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor defined list (e.g., Not Imaged, Patient Refusal, Site Error) or entered as free text. When RSREASND is used, the SDTMIG variable RSSTAT should also be populated in the SDTM-based dataset.
Findings	RS	N/A	N/A	10	RSEVAL	Response or Clin Class Evaluator	The role of the person who provided the information.	What was the role of the person performing the [disease response/clinical classifiaction] assessment?	Evaluator	Char	R/C	Indicate who performed the assessment.	RSEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (assigned by a person or a group). RSEVAL is expected for oncology response criteria. It can be null when the investigator provides all the data in a study. It should contain no null values when data from 1 of more evaluator are used in a study.
Findings	RS	N/A	N/A	11	RSEVALID	Response or Clin Class Evaluator ID	Used to distinguish multiple evaluators with the same role.	What is the evaluator identifier?	Evaluator Identifier	Char	O	Identify the evaluator providing this evaluation.	RSEVALID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(MEDEVAL)	N/A	When multiple assessors play the role identified in RSEVAL, values of RSEVALID will attribute a row of data to a particular assessor.
Findings	RS	N/A	N/A	12	RSLNKID	Response or Clin Class Link ID	An identifier used to link the disease response assessment to the related record in another domain which was used to determine the response result.	What was the [Disease Response or Clinical Classification ]Link ID Identifier?	[Disease Response or Clinical Classification ]Link ID	Char	O	If collected, record the unique [Disease Response or Clinical Classification ] Link ID Identifier.	RSLNKID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This variable is used to provide a unique code in order to link records across related CRFs (e.g., RS and TR) when appropriate. Sponsors develop their own conventions for populating RSLNKID.
Findings	RS	N/A	N/A	13	RSLNKGRP	Response or Clin Class Link Group	A grouping identifier used to link the disease response assessment to a group of related record in another domain which was used to determine the response result.	What was the [Disease Response or Clinical Classification] Link Group Identifier?	[Disease Response or Clinical Classification ]Link Group	Char	O	If collected, record the unique [Disease Response or Clinical Classification ] Link Group Identifier.	RSLNKGRP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This variable is used to provide a unique code in order to link a group of records across related CRFs (e.g., RS and TR) when appropriate. Sponsors develop their own conventions for populating RSLNKGRP.
Findings	RS	N/A	N/A	14	RSTEST	Response or Clin Class Assessment Name	Descriptive name of the disease response or clinical classification used to obtain the measurement or finding.	What was the [disease response/clinical classification] test name?	[Disease Response / Clinical Classification Test Name]	Char	HR	Record the name of the RS test, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	RSTEST; RSTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable RSTESTCD may be determined from the value collected in RSTEST. The SDTMIG variables RSTESTCD and RSTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(ONCRTS)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	RS	N/A	N/A	15	RSORRES	Response or Clin Class Original Result	Result of the disease response or clinical classification as originally received, collected,or calculated.	What was the [disease response/clinical classification]?	(Result)	Char	HR	Indicate the response classification	RSORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Both quantitative results and interpretive findings or summaries may be recorded here.
Findings	RS	N/A	N/A	16	RSORRESU	Response or Clin Class Original Units	The unit of the result as originally received or collected.	What was the [disease response/clinical classification] unit?	Unit	Char	HR	Record or select the original units in which these data were collected, if not preprinted on CRF	RSORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Should be included if applicable and not available elsewhere.

Assumptions for the CDASHIG RS - Disease Response and Clin Classification Classifications

1. This domain is for clinical classifications, including oncology disease response criteria.

2. Whenever possible, all physical manifestations that are collected to determine the disease response or clinical classification should be represented in the topic-based domains (e.g., labs, vital signs, tumor results, clinical events) to which they pertain. For example, if a lab test value is collected and then scored for a response evaluation or clinical classification measure, the lab test value should be collected in the LB domain using the rules that apply to that domain.

3. The RS domain is applicable for representing responses to assessment criteria used in oncology studies.

4. When using the RS domain to represent response evaluation or clinical classification determined from data from other domains (i.e., relates back to another source domain), the appropriate identifier must be collected to allow the relevant RELRECs to be created. These may include --LNKID, --LNKGRP, – SPID, REFID, or the CDASH --NO variables.

5. RSCAT is used to group a set of assessments based on a disease response criterion (published or protocol- defined) or a clinical classification. There are two codelists for RSCAT:

a. ONCRSCAT contains controlled terminology terms for oncology disease response assessments.

b. CCCAT contains controlled terminology for other clinical classifications instruments.

6. Within CDISC, Clinical Classification instruments represented in the RS domain fall under the concept of Questionnaires, Ratings and Scales (QRS).

a. Oncology response criteria do not currently follow the processes for other clinical classifications instruments. Note that in oncology studies, RSSTRESC is subject to controlled terminology in the SDTM datasets.

b. For other clinical classification instruments, QRS Naming Rules apply to the codelists. CDISC publishes standard QRS Supplements to the SDTMIG along with controlled terminology.

i. All standard supplement development is coordinated with the CDISC SDTM QRS Subteam as the governing body. The process involves drafting the controlled terminology and defining measure-specific, standardized values for qualifier, timing, and result variables to populate the SDTM QS, FT, and RS domains. These supplements are developed based on user demand and therapeutic area standards development needs. Sponsors should always consult the CDISC website to review the terminology and supplements prior to modeling any QRS measure data in the RS domain.

ii. Sponsors may participate and/or request the development of additional supplements and terminology through the CDISC SDTM QRS Subteam and the Controlled Terminology QRS Subteam.

iii. Once generated, the Clinical Classifications Supplement is posted on the CDISC website (http://www.cdisc.org/qrs).

iv. Sponsors should always consult the published QRS Supplements for guidance on submitting derived information in SDTM-based domains.

7. When a clinical classification result is based on multiple procedures, scans, images, or physical exams performed on different dates, the individual procedure, scan, image, and physical exam dates should be collected. RSDTC data may then be derived from these individual dates as specified by the sponsor.

8. The RS domain is intended for collected data. This includes records derived by the investigator or with a data collection tool, but not sponsor-derived records. Sponsor-derived records and results should be provided in an analysis dataset. However, totals and subtotals in clinical classification measures are considered collected data if recorded by an assessor. If these totals are operationally derived through a data collection tool (e.g., eCRF or ePRO device), then RSDRVL should be "Y".

Example CRF for the CDASHIG RS - Disease Response and Clin Classification

Example 1

Title: Child-Pugh Classification





CRF Metadata

Order Number	CDASH Variable	Question Text	Prompt	Data Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
1	RSCAT	What is the clinical classification criteria?	Child-Pugh Classification	text	N/A	RSCAT	N/A	(CCCAT);(ONCRSCAT)		CHILD-PUGH CLASSIFICATION	prompt		Y
2	RSPERF	Was the Child-Pugh Classification assessment performed?	Child-Pugh Classification Assessment Performed	text	Indicate whether or not the Child-Pugh Classification assessment was performed.	RSSTAT	If RSPERF = "N", the value of RSSTAT will be "NOT DONE". If RSPERF = "Y", RSSTAT should be null	(NY)
3	RSREASND	Why was the Child-Pugh Classification assessment not performed?	Reason Child-Pugh Classification assessment Not Performed	text	If the response was not collected, indicate why.	RSREASND	N/A	N/A
4	CPS0101_RSORRES	What was the Encephalopathy Grade?	Encephalopathy Grade	text	Indicate the Encephalopathy Grade.	RSORRES where RSTESTCD = "CPS0101"		N/A	None; 1 or 2;3 or 4;
5	CPS0102_RSORRES	What was the Ascites grade?	Ascites Grade	text	Indicate the Ascites Grade.	RSORRES where RSTESTCD = "CPS0102"		N/A	Absent;Slight;Moderate
6	CPS0103_RSORRES	What was the Serum Bilirubin?	Serum Bilirubin	text	Indicate the Serum Bilirubin Grade.	RSORRES where RSTESTCD = "CPS0103"		N/A	<2; 2 to 3;>3
7	CPS0103_RSORRESU	What was the Serum Bilirubin unit?	Serum Bilirubin Unit	text	Indicate the Serum Bilirubin Units.	RSORRESU where RSTESTCD = "CPS0103"		N/A	mg/dL
8	CPS0103_RSLBNO	What was the identifier for the laboratory result used to make this serum bilirubin classification?	Related Laboratory Result Identifier	text	If local labs were used, record the identifier for the source serum bilirubin result.	N/A	Associate with related LB record via RELREC	N/A
9	CPS0104_RSORRES	What was the Serum Albumin Grade?	Serum Albumin Grade	text	Indicate the Serum Albumin Grade.	RSORRES where RSTESTCD = "CPS0104"		N/A	>3.5;2.8 to 3.5 ; <2.8;
10	CPS0104_RSORRESU	What was the Serum Albumin unit?	Serum Albumin Unit	text	Indicate the Serum Albumin Unit.	RSORRESU where RSTESTCD = "CPS0104"		N/A	g/dL
11	CPS0104_RSLBNO	What was the identifier for the laboratory result used to make this serum albumin classification?	Related Laboratory Result Identifier	text	If local labs were used, record the identifier for the source serum albumin result.	N/A	Associate with related LB record via RELREC	N/A
12	CPS0105A_RSORRES	What was the Prothrombin Time (sec prolonged)?	Prothrombin Time (sec prolonged) Result	text	Indicate the Prothrombin Time (sec prolonged).	RSORRES where RSTESTCD = "CPS0105A"		N/A	<4;4 to 6; >6
13	CPS0105A_RSLBNO	What was the identifier for the laboratory result used to make this prothrombin time (sec prolonged) classification?	Related Laboratory Result Identifier	text	If local labs were used, record the identifier for the sourceprothrombin time (sec prolonged).	N/A	Associate with related LB record via RELREC	N/A
14	CPS0105B_RSORRES	What was the Prothrombin Time (international normalized ratio)?	Prothrombin Time (international normalized ratio Result	text	Indicate the Prothrombin Time (international normalized ratio) Grade.	RSORRES where RSTESTCD = "CPS0105B"		N/A	<1.7;1.7-2.3;>2.3;
15	CPS0105B_RSLBNO	What was the identifier for the laboratory result used to make this prothrombin time ((international normalized ratio) classification?	Related Laboratory Result Identifier	text	If local labs were used, record the identifier for the source prothrombin time (international normalized ratio).	N/A	Associate with related LB record via RELREC	N/A
16	CPS0106_RSORRES	What was the Child-Pugh Total Score?	Child-Pugh Total Score	text	Indicate the Child-Pugh Grade Total Score.	RSORRES where RSTESTCD = "CPS0106"		N/A
17	CPS0107_RSORRES	What was the Child-Pugh Grade?	Child-Pugh Grade	text	Indicate the Child-Pugh Grade (A=5 or 6 points, Grade B=7 to 9 points, C=10 to 15 points).	RSORRES where RSTESTCD = "CPS0107"		N/A	A;B;C;

8.3.15 SC - Subject Characteristics

Description/Overview for the CDASHIG SC - Subject Characteristics Domain

The SC domain describes protocol-specified characteristics of the study subjects and serves as an extension of the data contained in the Demographics (DM) domain. It is important to note that:

1. Data in this domain are collected only once per subject.

2. SC data that are collected once at the beginning of the trial and are not expected to change during the trial.

3. SC contains data such as additional information about education level, marital status, and national origin.

4. There is extensible CDASHIG controlled terminology for SCTEST. These data might be useful, for example, for risk-benefit or quality-of-life analyses, or for sub-setting a subject population.

5. The SDTMIG SC domain utilizes a normalized data structure; that is, 1 variable (SCTEST) is used to capture the test name and another variable (SCORRES) is used to capture the result. Subject Characteristics are presented as a normalized structure in the CDASHIG Metadata Table, but implementers using a denormalized structure (1 variable for each test) should create variable names that mirror the SCTESTCDs in controlled terminology.

Specification for the CDASHIG SC - Subject Characteristics Domain

Subject Characteristics Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	SC	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	SC	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	SC	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	SC	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	SC	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable SCDTC in ISO 8601 format.	N/A	N/A	The date the subject characteristics were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the subject characteristics at that visit, or the collection date can be included on the SC CRF using the date (SCDAT) field.
Findings	SC	N/A	N/A	6	SCCAT	Category for Subject Characteristic	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the subject characteristics?	[Subject Characteristics Category ]; NULL	Char	O	Record the subject characteristics category, if not preprinted on the CRF.	SCCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	SC	N/A	N/A	7	SCSCAT	Subcategory for Subject Characteristic	A sub-division of the SCCAT values based on user-defined characteristics.	What was the subcategory of the subject characteristics?	[Subject Characteristics Subcategory]; NULL	Char	O	Record the subject characteristics subcategory, if not preprinted on the CRF.	SCSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. SCSCAT can only be used if there is an SCCAT and it must be a subcategorization of SCCAT.
Findings	SC	N/A	N/A	8	SCPERF	SC Assessment Performed	An indication whether or not any subject characteristics were collected.	Were subject characteristics collected?	Subject Characteristics Collected	Char	O	Indicate if subject characteristics information was collected. If yes, record the appropriate details.	SCSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable SCSTAT. If SCPERF="N", the value of SCSTAT will be "NOT DONE". If SCPERF="Y", SCSTAT should be null. A combination of SDTMIG variables (e.g., SCCAT and SCSCAT, SCTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable SCTESTCD would be populated as SCALL and an appropriate test name (SCTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	SC	N/A	N/A	9	SCSPID	SC Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	SCSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	SC	N/A	N/A	10	SCDAT	Subject Characteristic Collection Date	The date of collection represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date the subject characteristic(s) was collected?	Date	Char	R/C	Record date the subject characteristic(s) was collected using the format (DD-MON- YYYY).	SCDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable SCDTC in ISO 8601 format.	N/A	N/A	The date of collection can be determined from a collected date of the visit (VISDAT) and in such cases a date field is not required.
Findings	SC	N/A	N/A	11	SCTEST	Subject Characteristic	Descriptive name of the subject characteristic of interest.	What is the Subject Characteristics name?	[Subject Characteristic Test Name]	Char	HR	Record the name of the Subject Characteristics if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	SCTEST;SCTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable SCTESTCD may be determined from the value collected in SCTEST. The SDTMIG variables SCTESTCD and SCTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(SCTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	SC	N/A	N/A	12	SCORRES	SC Result or Finding in Original Units	Result of the subject characteristic as originally received or collected.	What is the subject's characteristic?	(Result)	Char	HR	Record the subject characteristic.	SCORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	SC	N/A	Horizontal- Generic	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM- based dataset creation before submission.
Findings	SC	N/A	Horizontal- Generic	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	SC	N/A	Horizontal- Generic	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be provided to the site using a prepopulated list in the system. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM.
Findings	SC	N/A	Horizontal- Generic	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	SC	N/A	Horizontal- Generic	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable SCDTC in ISO 8601 format.	N/A	N/A	The date the subject characteristics were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the subject characteristics at that visit, or the collection date can be included on the SC CRF using the date (SCDAT) field.
Findings	SC	N/A	Horizontal- Generic	6	[SCTESTCD]_SCCAT	Category for Subject Characteristic	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the subject characteristics??	[Subject Characteristics Category]; NULL	Char	O	Record the subject characteristics category, if not preprinted on the CRF.	SCCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	SC	N/A	Horizontal- Generic	7	[SCTESTCD]_SCSCAT	Subcategory for Subject Characteristic	A sub-division of the SCCAT values based on user-defined characteristics.	What was the subcategory of the subject characteristics?	[Subject Characteristics Subcategory]; NULL	Char	O	Record the subject characteristics subcategory, if not preprinted on the CRF.	SCSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. SCSCAT can only be used if there is an SCCAT and it must be a subcategorization of SCCAT. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	SC	N/A	Horizontal- Generic	8	[SCTESTCD]_SCPERF	SC Assessment Performed	An indication whether or not any subject characteristics were collected.	Were subject characteristics collected for [SCTESTCD]?	[SCTEST] Collected	Char	O	Indicate if subject characteristics information was collected. If yes, include the appropriate details where indicated on the CRF.	SCSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable SCSTAT. If [SCTESTCD]_SCPERF ="N", the value of SCSTAT will be "NOT DONE". If [SCTESTCD]_SCPERF ="Y", SCSTAT should be null. A combination of SDTMIG variables (e.g., SCCAT and SCSCAT, SCTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable SCTESTCD would be assigned SCALL and an appropriate test name ( SCTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	General prompt question to be used as a data management tool to verify that missing results are confirmed missing. This may be implemented for all tests collected on the same horizontal record or for each specific test. When the SDTM-based datasets are created, the value of SCPERF would apply to all tests on the same record. Use the CDASH variable [SCTESTCD]_SCPERF when implemented on a specific test basis. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	SC	N/A	Horizontal- Generic	9	SCGRPID	Subject Characteristics Group ID	A sponsor- defined identifier used to tie together a block of related records in a single domain.	What is the test group identifier?	Test Group ID	Char	O	Record unique group identifier. Sponsor may insert additional instructions to ensure each record has a unique group identifier.	SCGRPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	It can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This group identifier ties together all the tests collected on this horizontal record. This field may be populated by the sponsor's data collection system.
Findings	SC	N/A	Horizontal- Generic	10	[SCTESTCD]_SCORRES	SC Result or Finding in Original Units	Result of the Subject Characteristics as originally received or collected.	What is the subject's [SCTEST]?	[SCTEST] Result	Char	HR	Record the subject characteristic.	SCORRES;SCTEST;SCTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A

Assumptions for the CDASHIG SC - Subject Characteristics Domain

1. The subject characteristics that should be collected are not specified by CDASH; this is a medical and scientific decision that should be based on the needs of the protocol.

2. The SDTMIG variable SCDTC can be determined from a collected date of the visit (VISDAT); in such cases, a CDASH date of collection field is not required on the CRF.

Example CRF for the CDASHIG SC - Subject Characteristics Domain

Example 1

Title: Subject Characteristics



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
SCPERF	1	Were subject characteristics collected?	Subject Characteristics Collected	Indicate if subject characteristics information was collected. If Yes, record the appropriate details.	Text	SCSTAT	If SCPERF = "Y", NOT SUBMITTED. If SCPERF = "N", SCSTAT where SCTESTCD = "SCALL".	(NY)	Yes; No
EDLEVEL_SCORRES	2	What is the subject's education level?	Education Level	Indicate the subject's education level.	Text	SCORRES;SCTEST;SCTESTCD	SCORRES WHERE SCTESTCD = "EDLEVEL"		Did not complete Secondary School or Less than High School; Some Secondary School or High School Education; High School or Secondary School Degree Complete; Associate’s or Technical Degree Complete; College or Baccalaureate Degree Complete; Doctoral or Postgraduate Education		prompt	radio
JOBCLAS_SCORRES	3	What is the subject’s employment status?	Employment Status	Indicate the subject's employment status.	Text	SCORRES;SCTEST;SCTESTCD	SCORRES WHERE SCTESTCD = "JOBCLAS"	(EMPSTAT)	Full-time; Part-time; Not employed		prompt	radio
MARISTAT_SCORRES	4	What is the subject's marital status?	Marital Status	Indicate the subject's marital status.	Text	SCORRES;SCTEST;SCTESTCD	SCORRES WHERE SCTESTCD = "MARISTAT"	(MARISTAT)	Never Married; Married; Legally Divorced; Divorced; Widowed		prompt	radio

8.3.16 TU - Tumor/Lesion Identification Domain

Description/Overview for the CDASHIG TU - Tumor/Lesion Identification Domain

The TU domain represents data that uniquely identifies tumors/lesions (i.e., malignant tumors, culprit lesions, other sites of disease such as lymph nodes). Commonly, tumors/lesions are identified by an investigator and/or independent assessor and classified according to the disease assessment criteria. For example, for an oncology study using RECIST evaluation criteria, this equates to the identification of Target, Non-Target, or New tumors. When designing CRFs, it is common that a single CRF is designed to collect both the Tumor/Lesion Identification information and the results of any assessments on these identified tumors/lesions.

Specification for the CDASHIG TU - Tumor/Lesion Identification Domain

Tumor/Lesion Identification Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	TU	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	TU	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	TU	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	TU	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	TU	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. If the date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM), then concatenate the CDASH VISDAT/VISTIM components and populate the SDTMIG variable TUDTC in ISO 8601 format.	N/A	N/A	If the date the test was collected can be determined from the Visit Date variable (VISDAT), apply that date to all of the tests at that visit, or the collection date can be collected on the CRF using the date (TUDAT). In this domain, it may not be appropriate to use the visit date as TUDTC.
Findings	TU	N/A	N/A	6	TUCAT	Category of Tumor/Lesion Identification	A grouping of topic- variable values based on user-defined characteristics.	What is the category of the [tumor/lesion] identification?	[Tumor/Lesion] Identification Category]; or NULL	Char	O	Record the Tumor Identification category, if not preprinted on the CRF.	TUCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This is most commonly either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	TU	N/A	N/A	7	TUSCAT	Subcategory Tumor/Lesion Identification	A sub-division of the TUCAT values based on user-defined characteristics.	What is the sub - category for the [tumor/lesion] identification?	[Tumor/Lesion] Identification Subcategory; or NULL	Char	O	Record the Tumor Identification subcategory, if not preprinted on the CRF.	N/A	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This is most commonly preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. TUSCAT can only be used if there is an TUCAT and it must be a subcategorization of TUCAT.
Findings	TU	N/A	N/A	8	TUYN	Any Tumors/ Lesions Identification	An indication whether or not any tumors were identified.	Were any [target/non- target/new/sponsor- defined) [tumors/lesions] identified?	Any ([Target/Non- target/New/Sponsor- defined) [Tumors/Lesions] Identified	Char	O	Indicate if the there are [tumors/lesions] identified. If yes, include the appropriate details where indicated on the CRF.	N/A	Not Submitted.	(NY)	N/A	This is intended to be used as a data management tool to verify that missing tumor/lesions evaluations are confirmed missing. The sponsor may decide to map "No" responses using the appropriate SDTMIG variables. Typically, this would use the SDTMIG variable, TUOCCUR, with an appropriate TUTEST.
Findings	TU	N/A	N/A	9	TUDAT	Tumor/Lesion Identification Date	The date of the [examination/procedure] used for tumor/lesion identification, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the [examination/procedure] used for [tumor/lesion] identification?	[Tumor/Lesion] Identification Procedure Date	Char	R/C	Record the scan/image/physical exam date used to identify the tumor/lesion using this format (DD- MON-YYYY.	TUDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable TUDTC in ISO 8601 format.	N/A	N/A	This is the date of the scan/image/physical exam used to identified the tumor/lesion. It is not the date the MRI or scan was read. This is typically not the visit date.
Findings	TU	N/A	N/A	10	TUEVAL	Tumor/Lesion Evaluator	The role of the person who provided the information.	Who provided the information?; or Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TUEVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted, or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Findings	TU	N/A	N/A	11	TUEVALID	Tumor/Lesion Evaluator Identifier	Used to distinguish multiple evaluators with the same role.	What was the identifier of the evaluator?	[Evaluator/Reporter] Identifier	Char	O	Record the unique identifier assigned to the person making the evaluation.	TUEVALID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(MEDEVAL)	N/A	Collect if multiple evaluators are used in the study (may be omitted if multiple evaluators are not used); values should follow controlled terminology.
Findings	TU	N/A	N/A	12	TULNKID	Tumor/Lesion Identification Link ID	An identifier used to link identified tumor/lesion to the assessment result.	What was the [Tumor/Lesion] (link) identifier?	[Tumor/ Lesion] ID	Char	HR	If collected, record the unique identifier for this tumor/lesion.	TULNKID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This variable is used to provide a unique code for each identified tumor in order to link records across related CRFs (TU and TR) when appropriate. Sponsors develop their own conventions for populating --LNKID. Typically, the lesion/tumor is assigned the --LNKID at baseline when the tumor/lesion is identified, and the this --LNKID is used at other visits to collect assessments on this tumor/lesion.
Findings	TU	N/A	N/A	13	TUPRNO	Tumor/Lesion Related Procedure ID	The identifier for the procedure used to identify the tumor.	What was the identifier for the procedure used to identify this tumor?	Procedure Identifier	Char	O	Record the procedure [ID or Line Number] used to evaluate the tumor/lesion.	N/A	This does not map directly to an SDTMIG variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the PR domain.	N/A	N/A	Intent is to establish a link between the TU identified and the procedure undergone to identify this tumor/lesion. TUPRNO can be used to identify a relationship between records in the TU dataset and records in the PR dataset. See SDTMIG v3.2 Section 8.2 for information on RELREC.
Findings	TU	N/A	N/A	14	TUMETHOD	Tumor/Lesion Method of Identification	Method of the test or examination.	What was the method used to [evaluate/identify] the tumor/lesion?	Method of [Evaluation/Identification]	Char	O	Record the method used to evaluate/identify the tumor/lesion.	TUMETHOD	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(METHOD)	N/A	The method used to identify the tumor/lesions. Sponsors may collect the method using a codelist which includes the most commonly known/generally recognized terms. The values will represent the method generically, not the product of the method (e.g., photograph) A sponsor may customize or restrict the list of values per response criteria or protocol needs. At a minimum, the primary method of identification should be entered and is expected to be consistent throughout the study; recording secondary methods is at the discretion of the sponsor.
Findings	TU	N/A	N/A	15	TUREFID	Tumor/Lesion Identification Reference ID	An internal or external identifier such as image ID number (e.g., CT scan, MRI, ultrasound identifier).	What was the procedure [reference identifier/accession number]?	[Tumor/Lesion] Reference ID	Char	O	Record the internal or external identifier assigned to the procedure/method used to identify the tumor/lesion.	TUREFID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This variable may be used to collect a reference/accession number associated with the method used to identify the tumor/lesion. A sponsor may also decide to use the CDASH variable TUPRNO as an identifier for the procedure.
Findings	TU	N/A	N/A	16	TUTEST	Tumor/Lesion Identification Test Name	Descriptive name of the measurement or finding.	What was the tumor/lesion Identification test name?	[Tumor or Lesion Identification Test Name]	Char	HR	Record the name of the TU test, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUTEST; TUTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable TUTESTCD may be determined from the value collected in TUTEST. The SDTMIG variables TUTESTCD and TUTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(TUTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	TU	N/A	N/A	17	TUORRES	Tumor/Lesion Identification Result	Result of the tumor identification (e.g., classification or type of tumor).	What is the [type/classification] of [tumor/lesion] as defined by the criteria being employed?	(Result)	Char	HR	Record the Tumor Identification classification. This may be preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Each test may be collected using the CDASH variable [TESTCD], for example, TUMERGE, TUSPLIT, TUMIDENT or [TESTCD]_TUORRES where TESTCD is the appropriate CT for the TU test code. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	TU	N/A	N/A	18	TULOC	Location of the Tumor/Lesion	A description of the anatomical location of the identified tumor/lesion.	What was the anatomical location of the [tumor/lesion] identified?	Anatomical Location	Char	O	Record or select the anatomical location of the identified tumor/lesion.	TULOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location. A location detail text field (TULOCDTL) is conditional for entry (i.e., can be left blank) and allows the study site to specify the lesion in its own terms or can be used to distinguish tumors within the same location if other location qualifiers are not specific enough.
Findings	TU	N/A	N/A	19	TULAT	Tumor/Lesion Identification Laterality	Qualifier for anatomical location further detailing the side of the body relevant for the event.	What was the laterality of the anatomical location?	[Tumor/Lesion Identification]Side	Char	O	Record the side of the body within the anatomical location of the identified [tumor/lesion].	TULAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	TU	N/A	N/A	20	TUDIR	Tumor/Lesion Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location?	[Tumor/Lesion Identification] Directionality	Char	O	Record the directionality within the anatomical location of the identified [tumor/lesion].	TUDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	TU	N/A	N/A	21	TULOCDTL	TU Identification Location Detail	A detail description of the location of the identified tumor/lesion.	What [were/are] additional details on the exact location of the tumor so that it can be distinguished from other tumors in the same anatomical location?	[Tumor/Lesion Identification] Location Detail	Char	O	Describe additional detail on the exact location of the tumor so that it can be distinguished from other tumors in the same anatomical location.	SUPPTU.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPTU dataset as the value of SUPPTU.QVAL where SUPPTU.QNAM="TULOCDTL" and SUPPTU.QLABEL= "TU Identification Location Detail".	N/A	N/A	Use if TULOC and TULAT and/or TUDIR values cannot provide uniqueness from other identified tumors. TULOCDTL is not meant to replace TULOC, TULAT, and/or TUDIR or serve as the free-text description field for TULOC (e.g., Location, Other).
Findings	TU	N/A	N/A	22	TUNAM	Tumor/Lesion Identification Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the vendor used?	[Tumor/Lesion Identification] Vendor Name	Char	O	Record the name of the vendor providing the evaluation.	TUNAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if vendor names was not collected at the site/study level or if multiple vendors are used by a site.

Assumptions for the CDASHIG TU - Tumor/Lesion Identification Domain

1. This domain only includes the information needed to identify the tumor/lesion. Results (e.g., size of a tumor/lesion) would be represented in the associated TR domain.

2. Typically in oncology studies, the initial identification of a tumor/lesion is done once, usually at baseline. New tumors/lesions identified subsequent to baseline or changes to tumors/lesions initially identified are also collected in this domain.

3. The identification information would typically include the location description.

4. The TULNKID variable is used to provide a unique code for each identified tumor/lesion. The unique code is not specified by CDASH; this is a decision that is based on the needs of the protocol. Suggestions for the unique TULNKID codes are provided in the oncology TAUGs and the SDTMIG.

5. TULNKID is used to relate an identification record in TU domain to assessment/result records in the TR domain. Therefore, the values must be identical. Suggestions for the unique TULNKID codes used for the identification of tumors/lesions in oncology trials are provided in the oncology TAUGs and the SDTMIG.

6. The SDTM identifiers, --GRPID, --REFID, and --SPID) must not be used to link the identified tumor/lesion with the results/assessments for this identified tumor. These identifiers are used for other purposes, as described in the SDTMIG.

7. TUEVAL and TUEVALID are used indicate who provided the data. TUEVALID provides more details when multiple evaluators are used. TUEVAL must be collected or defaulted when TUEVALID is collected.

Example CRFs for the CDASHIG TU - Tumor/Lesion Identification Domain

Example 1

Title: Tumor Identification/Evaluation





CRF Metadata

Order Number	CDASHIG Variable	Question Text	Prompt	Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	TUYN	Were any ([target/non- target/new/sponsor-defined) [tumors/lesions]identified?	Any ([Target/Non- target/New/Sponsor-defined) Tumors/Lesions Identification	text	Indicate if the there are [tumors/lesions] identified. If Yes, include the appropriate details where indicated on the CRF.	N/A		(NY)	Yes; No
2	TUTRDAT	What was the date of the procedure used for [tumor/lesion] identification?	Procedure Date	text	Record the date when the scan or image was made or when the physical exam occurred using this format (DD-MON-YYYY).	TUDTC;TRDTC	TUDTC and TRDTC	N/A
3	TUTREVAL	Who was the evaluator?	Tumor Identification [Evaluator/Reporter]	text	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TUEVAL;TREVAL	TUEVAL and TREVAL	(EVAL)
4	TUTREVALID	What was the identifier of the evaluator?	Tumor Identification Evaluator Identifier	text	Record the unique identifier assigned to the person making the evaluation.	TUEVALID;TREVALID	TUEVALID and TREVALID	(MEDEVAL)
5	TUTRLNKID	What was the [Tumor/Lesion] Identifier?	[Tumor/ Lesion] ID	text	If collected, record the unique identifier for this tumor/lesion.	TULNKID;TRLNKID	TULNKID and TRLNKID	N/A
6	TUTRMETHOD	What was the method used to [evaluate/identify] the tumor/lesion?	Method of [Evaluation/Identification]	text	Record the method used to evaluate/identify the tumor/lesion.	TUMETHOD		(METHOD)
7	TUTRREFID	What was the procedure [reference identifier/accession number] ?	Reference ID	text	Record the internal or external identifier assigned to the procedure/method used to identify the tumor/lesion	TUREFID;	TUREFID and TRREFID	N/A
8	TUTEST	What was the tumor/lesion identification test name?	Tumor/Lesion Identification Test Name	text	Record the name of the TU test, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUTEST	TUTEST	(TUTEST)					y
9	TUMIDENT	What is the [type/classification] of [tumor/lesion] as defined by the criteria being employed?	Result	text	Record the Tumor Identification classification. This may be preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUORRES:TUEST:TUTESTCD:	TUORRES where TUTESTCD="TUMIDENT"	N/A	TARGET; NON- TARGET; NEW TARGET; NEW- NON-TARGET
10	TUCHANGE	Indicate what type of change to the tumor was identified.	Changes to Tumor (Result)	text	Record what type of change to the tumor was identified.	TUORRES:TUEST:TUTESTCD	If TUCHANGE = "SPLIT", TUORRES = "TARGET" where TUTESTCD = "TUSPLIT" ; If TUCHANGE = "MERGED", TUORRES = "TARGET" where TUTESTCD = "TUMERGE"	N/A	SPLIT; MERGED
11	TULOC	What was the anatomical location of the [tumor/lesion] identified?	Anatomical Location	text	Record or select the anatomical location of the identified tumor/lesion.	TULOC		(LOC)
12	TULAT	If applicable, what was the laterality of the anatomical location?	Side	text	Record the side of the anatomical location of the identified [tumor/lesion].	TULAT		(LAT)
13	TUDIR	If applicable, what was the directionality of the anatomical location?	Directionality	text	Record the directionality of the anatomical location of the identified [tumor/lesion].	TUDIR		(DIR)
14	TULOCDTL	If applicable, what is the additional detail about the tumor location?	Location Detail	text	Describe additional detail on the exact location of the tumor so that it can be distinguished from other tumors in the same anatomical location.	SUPPTU.QVAL	SUPPTU.QVAL where SUPPTU.QNAM = "TULOCDTL" and SUPPTU.QLABEL = "Tumor Location Details"	N/A
15	TUNAM	What was the name of the vendor used?	Vendor Name	text	Record the name of the vendor providing the evaluation.	TUNAM		N/A
16	LDIAM_TRORRES	What was the longest diameter of the tumor?	Longest Diameter	text	Record the longest diameter.	TRORRES; TRTESTCD; TRTEST:	TRORRES where TRTESTCD = "LDIAM"	N/A
17	LDIAM_TRORESSU	What was the unit?	Unit	text	Record the unit.	TRORESSU	N/A

Example 2

This is an example of a single CRF collecting both acne lesion identification data (TU) and the lesion result data (TR). It collects the number of lesions of each type at each location. This is a normalized CRF. One record is collected for each anatomical location, and each type of lesion. The sponsor must determine how the TULNKID/TRLNKID are created and assigned. Other lesion types or location were not of interest.

At subsequent assessments, post-baseline, the CRF may be designed so that only the relevant questions are displayed (e.g., –EVAL, --LNKID, --DAT –REFID, TRORRES).

Title: Acne Vulgaris Lesion Evaluations



CRF Metadata

Order Number	CDASH Variable	Question Text	Prompt	Data Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	TUYN	Were any acne vulgaris lesions identified?	Any Acne Vulgaris Lesions	text	Indicate if there are any acne vulgaris lesion identified. If Yes, include the appropriate details where indicated on the CRF.	N/A		(NY)	Yes;No
2	TUEVAL	Who was the evaluator?	[Evaluator/Reporter]	text	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TUEVAL; TREVAL	TUEVAL and TREVAL	(EVAL)		BLINDED EVALUATOR		checkbox	y
3	TUTEST	What was the lesion] Identification test name?	Lesion] Identification Test Name	text	Record the name of the TU test, if not pre- printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUTEST; TUTESTCD;	TUTEST and TUTESTCD	(TUTEST)		Tumor Identification			y
4	TUORRES	What is the type of lesion?	Result	text	Record the Tumor Identification classification. This may be pre-printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUORRES:TUTEST;TESTCD:	TUORRES where TUTESTCD="LESIDENT"	(TUMIDENT)	Inflammatory Papules; Inflammatory Pustules;Non- Inflammatory - Open;Inflammatory Closed
5	TULOC	What was the anatomical location of the lesions?	Anatomical Location	text	Record or select the anatomical location of the lesion.	TULOC		(LOC)	Forehead; Chin; Cheek;
6	TULAT	If applicable, what was the laterality of the anatomical location?	Side	text	Record the side of the anatomical location of the identified.	TULAT		(LAT)	Right; Left;		prompt
7	TULNKID	What was the lesion identifier?	Lesion ID	text	If collected, record the unique identifier for the lesion	TULNKID; TRLNKID	TULNKID and TRLNKID	N/A
8	TUDAT	What was the date the lesions were photographed and counted?	Date	text	Record the date when lesions were photographed and counted using this format (DD-MON-YYYY).	TUDTC; TRDTC;	TUDTC and TRDTC	N/A
9	TUREFID	What was the photograph reference identifier?	Reference ID	text	Record the internal or external identifier assigned to the photograph.	TUREFID		N/A
10	TRORRES	What was the number of lesions?	Number of Lesions	integer	Record the number of lesions. When no lesions are identified at a site of interest, record 0.	TRORRES;TRTEST;TRTESTCD	TRORRES where TRTESTCD="NUMLES"

8.3.17 TR - Tumor/Lesion Results

Description/Overview for the CDASHIG TR - Tumor/Lesion Results Domain

The TR domain represents measurements and/or assessments of the tumors/lesions identified in the Tumor/Lesion Identification (TU) domain. When the TR domain is used, there must be a corresponding TU domain present. This multiple-domain approach was developed largely to reduce the need to collect tumor identification information at each assessment (e.g., anatomical location). A unique tumor/lesion identification number (populated in TULNKID/TRLNKID) is used to link the tumor/lesion identification (TU) with the measurement/assessments (TR). When designing CRFs, it is common that a single CRF is designed to collect both the Tumor/Lesion Identification information and the results of any assessments on these identified tumors/lesions.

Specification for the CDASHIG TR - Tumor/Lesion Identification Domain

Tumor/Lesion Identification Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	TR	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	TR	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	TR	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	TR	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	TR	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. If the date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable TRDTC in ISO 8601 format.	N/A	N/A	If the date the test was collected can be determined from the Visit Date variable (VISDAT), apply that date to all of the tests at that visit, or the collection date can be collected on the CRF using the date (TRDAT). In this domain, it may not be appropriate to use the vist date as TRDTC.
Findings	TR	N/A	N/A	6	TRLNKGRP	Tumor/Lesion Result Link Group	An identifier used to link related records across domains.	What was the [tumor/lesion] [link group] identifier?	[Tumor/Lesion] [Link Group] ID	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has the appropriate identifier.	TRLNKGRP	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Because TRLNKGRP is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. This is typically used in oncology clincial trials. It is intended to group all the assessments at a evaluation time point represented in the TR domain with the associated response assessments represented in the RS domain.
Findings	TR	N/A	N/A	7	TRCAT	Category of Tumor/Lesion Result	A grouping of topic-variable values based on user-defined characteristics.	What is the category of the [tumor/lesion] results?	[Tumor/Lesion Result Category]; or NULL	Char	O	Record the Tumor/Lesion Result category, if not preprinted on the CRF.	TRCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading or a preprinted category value on the CRF, and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	TR	N/A	N/A	8	TRSCAT	Subcategory of Tumor/Lesion Result	A subgrouping of topic-variable values based on user-defined characteristics.	What is the subcategory of the [tumor/lesion] results?	[Tumor/Lesion Result Subcategory]; or NULL	Char	O	Record the Tumor/Lesion Result subcategory, if not preprinted on the CRF.	TRSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be preprinted on the CRF or screen and prepopulated in the data management system. This is not typically a question to which the site would provide an answer. TRSCAT can only be used if there is an TRCAT and it must be a subcategorization of TRCAT.
Findings	TR	N/A	N/A	9	TRSTAT	Tumor/Lesion Result Completion Status	The variable used to indicate that data are not available by having the site record the value as "Not Done".	Indicate if the [tumor/lesion] evaluation was not done.	Not Done	Char	O	Indicate if the [Tumor/Lesion] evaluation was not done.	TRSTAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ND)	N/A	A Not Done check box, which indicates the test was NOT DONE. Typically, there would be one check box for each result. This field can be useful to confirm that a blank result field is meant to be blank.
Findings	TR	N/A	N/A	10	TRREASND	Reason Tumor Measurement Not Performed	An explanation of why the data are not available.	What was the reason that the [tumor/lesion] was not [evaluated/assessed]?	Reason Not Done	Char	O	Provide the reason the result was not provided.	TRREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology may be used. The reason the data are not available may be chosen from a sponsor-defined codelist (e.g., broken equipment, subject refused) or entered as free text. When TRREASND is used, TRSTAT should also be populated in the SDTM-based dataset.
Findings	TR	N/A	N/A	11	TREVAL	Tumor/Lesion Result Evaluator	The role of the person who provided the information.	Who provided the information? OR Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TREVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	TR	N/A	N/A	12	TREVALID	Tumor/Lesion Result Evaluator Identifier	Used to distinguish multiple evaluators with the same role.	What was the identifier of the evaluator?	Evaluator Identifier	Char	O	Record the unique identifier assigned to the person making the evaluation.	TREVALID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(MEDEVAL)	N/A	Collect if multiple evaluators are used in the study (may be omitted if multiple evaluators are not used); values should follow controlled terminology.
Findings	TR	N/A	N/A	13	TRDAT	Tumor/Lesion Result Date	The date of the procedure used for tumor/lesion assessment, represented in an unambiguous date format (e.g., DD- MON-YYYY).	What was the date of the procedure used for [tumor/lesion] assessment?	Date	Char	R/C	Record the date when the method used to assess the tumor/lesion occurred using this format (DD- MON-YYYY).	TRDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable TRDTC in ISO 8601 format.	N/A	N/A	This is the date of the scan/image/physical exam used to evaluate the tumor/lesion. It is not the date the MRI or scan was read. This is typically not the visit date.
Findings	TR	N/A	N/A	14	TRLNKID	Tumor/Lesion Result Link ID	An identifier used to link identified tumor/lesion to the assessment result.	What was the [tumor/lesion] Identifier?	[Tumor/ Lesion] ID	Char	R/C	If collected, record the unique identifier for this tumor/lesion.	TRLNKID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This variable is used to provide a unique code for each identified tumor in order to link records across related CRFs (TU and TR) when appropriate. Sponsors develop their own conventions for populating -- LNKID. Typically, the lesion/tumor is assigned the -- LNKID at baseline when the tumor/lesion is identified, and this --LNKID is used at other visits to collect assessments on this tumor /lesion. Note: This variable may be collected using one CDASH variable name (e.g., TULNKID) and populated into TRLNKID when the submisson datasets are created.
Findings	TR	N/A	N/A	15	TRTEST	Tumor/Lesion Assessment Test Name	Descriptive name of the measurement or finding.	What was the [tumor/ lesion] (assessment) test name?	[Tumor/Lesion] (Assessment) Test Name]	Char	HR	Record the name of the tumor lesion assessment, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TRTEST; TRTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable TRTESTCD may be determined from the value collected in TRTEST. The SDTMIG variables TRTESTCD and TRTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(TRTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	TR	N/A	N/A	16	TRORRES	TR Result or Finding in Original Units	Result of the tumor/lesion assessment.	What is the result for the [tumor/lesion assessment]?	(Result)	Char	HR	Record the Tumor/Lesion Assessment result.	TRORRES;TRTESTCD; TRTEST	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. In addition to the SDTMIG variable TRORRES, create TRTESTCD from the CDASH variable name and determine the value of TRTEST from TRTESTCD. The CDASH prompt may also contain the TRTEST. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Result of the tumor/lesion assessment. Both quantitative and qualitatve results may be recorded here.
Findings	TR	N/A	N/A	17	TRORRESU	TR Original Units	The unit of the result as originally received or collected.	What was the unit of the [result/measurement]?	Unit	Char	R/C	Record or select the original units in which these data were collected, if not preprinted on CRF.	TRORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Usually the unit of the test is preprinted on the CRF.
Findings	TR	N/A	N/A	18	TRNAM	Tumor/Lesion Result Vendor Name	The name or identifier of the vendor (e.g., laboratory) that provided the test results.	What was the name of the vendor used?	Vendor Name	Char	O	Record the name of the vendor providing the evaluation.	TRNAM	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Recommended to collect on the CRF if vendor names was not collected at the site/study level or if multiple vendors are used by a site.

Assumptions for the CDASHIG TR - Tumor/Lesion Identification Domain

1. This domain only includes the information on the tumor/lesion assessment results (e.g., size of a tumor/lesion). This may be a single assessment or multiple assessments over time.

2. The identification information is provided in the TU domain. The TULNKID and TRLNKID variables contain the same unique code to link each identified tumor/lesion and each identified tumor result/assessment. The unique code is not specified by CDASH; this is a decision that is based on the needs of the protocol. Suggestions for the unique TULNKID/TRLNKID codes are provided in the oncology TAUGs and the SDTMIG.

3. The SDTM identifiers --GRPID, --REFID, and --SPID must not be used to link the identified tumor/lesion with the results/assessments for this identified tumor. These identifiers are used for other purposes, as described in the SDTMIG.

4. Link identifiers (e.g., TRLNKID, TRLNKGRP) may be used to link the assessments in the TR domain to the Disease Response and Clin Classification (RS) domain. The RS domain would typically provide the classification or response assessments associated with these TR results.

5. TREVAL and TREVALID are used indicate who provided the data. TREVALID provides more details when multiple evaluators are used. TREVAL must be collected or defaulted when TREVALID is collected.

Example CRFs for the CDASHIG TR - Tumor/Lesion Identification Domain

Example 1

Title: Tumor Identification/Evaluation





CRF Metadata

Order Number	CDASHIG Variable	Question Text	Prompt	Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	TUYN	Were any ([target/non- target/new/sponsor-defined) [tumors/lesions]identified?	Any ([Target/Non- target/New/Sponsor-defined) Tumors/Lesions Identification	text	Indicate if the there are [tumors/lesions] identified. If Yes, include the appropriate details where indicated on the CRF.	N/A		(NY)	Yes; No
2	TUTRDAT	What was the date of the procedure used for [tumor/lesion] identification?	Procedure Date	text	Record the date when the scan or image was made or when the physical exam occurred using this format (DD-MON-YYYY).	TUDTC;TRDTC	TUDTC and TRDTC	N/A
3	TUTREVAL	Who was the evaluator?	Tumor Identification [Evaluator/Reporter]	text	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TUEVAL;TREVAL	TUEVAL and TREVAL	(EVAL)
4	TUTREVALID	What was the identifier of the evaluator?	Tumor Identification Evaluator Identifier	text	Record the unique identifier assigned to the person making the evaluation.	TUEVALID;TREVALID	TUEVALID and TREVALID	(MEDEVAL)
5	TUTRLNKID	What was the [Tumor/Lesion] Identifier?	[Tumor/ Lesion] ID	text	If collected, record the unique identifier for this tumor/lesion.	TULNKID;TRLNKID	TULNKID and TRLNKID	N/A
6	TUTRMETHOD	What was the method used to [evaluate/identify] the tumor/lesion?	Method of [Evaluation/Identification]	text	Record the method used to evaluate/identify the tumor/lesion.	TUMETHOD		(METHOD)
7	TUTRREFID	What was the procedure [reference identifier/accession number] ?	Reference ID	text	Record the internal or external identifier assigned to the procedure/method used to identify the tumor/lesion	TUREFID;	TUREFID and TRREFID	N/A
8	TUTEST	What was the tumor/lesion identification test name?	Tumor/Lesion Identification Test Name	text	Record the name of the TU test, if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUTEST	TUTEST	(TUTEST)					y
9	TUMIDENT	What is the [type/classification] of [tumor/lesion] as defined by the criteria being employed?	Result	text	Record the Tumor Identification classification. This may be preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUORRES:TUEST:TUTESTCD:	TUORRES where TUTESTCD="TUMIDENT"	N/A	TARGET; NON- TARGET; NEW TARGET; NEW- NON-TARGET
10	TUCHANGE	Indicate what type of change to the tumor was identified.	Changes to Tumor (Result)	text	Record what type of change to the tumor was identified.	TUORRES:TUEST:TUTESTCD	If TUCHANGE = "SPLIT", TUORRES = "TARGET" where TUTESTCD = "TUSPLIT" ; If TUCHANGE = "MERGED", TUORRES = "TARGET" where TUTESTCD = "TUMERGE"	N/A	SPLIT; MERGED
11	TULOC	What was the anatomical location of the [tumor/lesion] identified?	Anatomical Location	text	Record or select the anatomical location of the identified tumor/lesion.	TULOC		(LOC)
12	TULAT	If applicable, what was the laterality of the anatomical location?	Side	text	Record the side of the anatomical location of the identified [tumor/lesion].	TULAT		(LAT)
13	TUDIR	If applicable, what was the directionality of the anatomical location?	Directionality	text	Record the directionality of the anatomical location of the identified [tumor/lesion].	TUDIR		(DIR)
14	TULOCDTL	If applicable, what is the additional detail about the tumor location?	Location Detail	text	Describe additional detail on the exact location of the tumor so that it can be distinguished from other tumors in the same anatomical location.	SUPPTU.QVAL	SUPPTU.QVAL where SUPPTU.QNAM = "TULOCDTL" and SUPPTU.QLABEL = "Tumor Location Details"	N/A
15	TUNAM	What was the name of the vendor used?	Vendor Name	text	Record the name of the vendor providing the evaluation.	TUNAM		N/A
16	LDIAM_TRORRES	What was the longest diameter of the tumor?	Longest Diameter	text	Record the longest diameter.	TRORRES; TRTESTCD; TRTEST:	TRORRES where TRTESTCD = "LDIAM"	N/A
17	LDIAM_TRORESSU	What was the unit?	Unit	text	Record the unit.	TRORESSU		N/A

Example 2

This is an example of a single CRF collecting both acne lesion identification data (TU) and the lesion result data (TR). It collects the number of lesions of each type at each location. This is a normalized CRF. One record is collected for each anatomical location, and each type of lesion. The sponsor must determine how the TULNKID/TRLNKID are created and assigned. Other lesion types or location were not of interest.

At subsequent assessments, post-baseline, the CRF may be designed so that only the relevant questions are displayed (e.g., –EVAL, --LNKID, --DAT –REFID, TRORRES).

Title: Acne Vulgaris Lesion Evaluations



CRF Metadata

Order Number	CDASH Variable	Question Text	Prompt	Data Type	Case Report Form Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Codelist Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
1	TUYN	Were any acne vulgaris lesions identified?	Any Acne Vulgaris Lesions	text	Indicate if there are any acne vulgaris lesion identified. If Yes, include the appropriate details where indicated on the CRF.	N/A		(NY)	Yes;No
2	TUEVAL	Who was the evaluator?	[Evaluator/Reporter]	text	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	TUEVAL; TREVAL	TUEVAL and TREVAL	(EVAL)		BLINDED EVALUATOR		checkbox	y
3	TUTEST	What was the lesion] Identification test name?	Lesion] Identification Test Name	text	Record the name of the TU test, if not pre- printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUTEST; TUTESTCD;	TUTEST and TUTESTCD	(TUTEST)		Tumor Identification			y
4	TUORRES	What is the type of lesion?	Result	text	Record the Tumor Identification classification. This may be pre-printed on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	TUORRES:TUTEST;TESTCD:	TUORRES where TUTESTCD="LESIDENT"	(TUMIDENT)	Inflammatory Papules; Inflammatory Pustules;Non- Inflammatory - Open;Inflammatory Closed
5	TULOC	What was the anatomical location of the lesions?	Anatomical Location	text	Record or select the anatomical location of the lesion.	TULOC		(LOC)	Forehead; Chin; Cheek;
6	TULAT	If applicable, what was the laterality of the anatomical location?	Side	text	Record the side of the anatomical location of the identified.	TULAT		(LAT)	Right; Left;		prompt
7	TULNKID	What was the lesion identifier?	Lesion ID	text	If collected, record the unique identifier for the lesion	TULNKID; TRLNKID	TULNKID and TRLNKID	N/A
8	TUDAT	What was the date the lesions were photographed and counted?	Date	text	Record the date when lesions were photographed and counted using this format (DD-MON-YYYY).	TUDTC; TRDTC;	TUDTC and TRDTC	N/A
9	TUREFID	What was the photograph reference identifier?	Reference ID	text	Record the internal or external identifier assigned to the photograph.	TUREFID		N/A
10	TRORRES	What was the number of lesions?	Number of Lesions	integer	Record the number of lesions. When no lesions are identified at a site of interest, record 0.	TRORRES;TRTEST;TRTESTCD	TRORRES where TRTESTCD="NUMLES"

8.3.18 VS - Vital Signs

Description/Overview for the CDASHIG VS - Vital Signs Domain

In CDASH, vital signs are measurements including but not limited to blood pressure, temperature, respiration, body surface area, body mass index (BMI), height, and weight.

Specification for the CDASHIG VS - Vital Signs Domain

Vital Signs Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	VS	N/A	Horizontal- Generic	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	VS	N/A	Horizontal- Generic	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	VS	N/A	Horizontal- Generic	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	VS	N/A	Horizontal- Generic	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	VS	N/A	Horizontal- Generic	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	The date the VS measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit, or the collection date can be included on the VS CRF using the Vital Signs Date (VSDAT) field.
Findings	VS	N/A	Horizontal- Generic	6	[VSTESTCD]_VSPERF	Vital Signs Performed	An indication whether or not a planned vital signs measurement, series of vital signs measurements, tests, or observations was performed.	Were [vital signs/[VSTEST] performed?	Vital Signs Performed ; [VSTEST] Performed	Char	O	Indicate if the vital signs were collected. If yes, include the appropriate details where indicated on the CRF.	VSSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable VSSTAT. If VSPERF="N", the value of VSSTAT will be "NOT DONE". If VSPERF="Y", VSSTAT should be null. A combination of SDTMIG variables (e.g., VSCAT and VSSCAT, VSTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable VSTESTCD would be populated as VSALL and an appropriate test name (VSTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This general prompt question is used as a data management tool to verify that missing results are confirmed missing. This may be implemented for all tests collected on the same horizontal record or for each specific test. When mapped to SDTM, the value of VSPERF would apply to all tests on the same record. Use the CDASH variable [VSTESTCD]_VSPERF when implemented on a specific test basis.
Findings	VS	N/A	Horizontal- Generic	7	[VSTESTCD]_VSDAT	Vital Signs Date	The date of the vital signs measurement, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the measurement(s)?	[VSTEST] Date	Char	R/C	Record date of measurements using this format (DD- MON-YYYY).	VSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	A single date may be collected for all the vital sign measurements when they are performed on the same date. The date of each measurement can also be collected for each measurement using a CDASH variable [VSTESTCD]_VSDAT. The date of the measurements may be determined from a collected date of visit and in such cases a separate measurement date field is not required.
Findings	VS	N/A	Horizontal- Generic	8	[VSTESTCD]_VSTIM	Vital Signs Time	The time of measurement, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the measurement(s)?	[VSTEST] Time	Char	R/C	Record time of measurement (as complete as possible).	VSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	A single collection time (e.g., VSTIM) may be collected for all the measurements when they are performed at the same time. The time of each measurement can also be collected using a CDASH variable [VSTESTCD]_VSTIM.
Findings	VS	N/A	Horizontal- Generic	9	VSCAT	Category for Vital Signs	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the vital signs?	[Vital Signs Category]; NULL	Char	O	Record the vital signs category, if not preprinted on the CRF.	VSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	VS	N/A	Horizontal- Generic	10	VSSCAT	Subcategory for Vital Signs	A sub-division of the VSCAT values based on user-defined characteristics.	What was the subcategory of the vital signs?	[Vital Signs Subcategory]; NULL	Char	O	Record the vital signs subcategory, if not preprinted on the CRF.	VSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. VSSCAT can only be used if there is a VSCAT and it must be a subcategorization of VSCAT.
Findings	VS	N/A	Horizontal- Generic	11	VSGRPID	Vital Signs Group ID	A sponsor- defined identifier used to tie a block of related records in a single domain.	What is the vital signs group identifier?	Test Group ID	Char	O	Record unique group identifier. Sponsor may insert additional instructions to ensure each record has a unique group identifier.	VSGRPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	It can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question. This group identifier ties together all the tests collected on the same horizontal record. This field may be populated by the sponsor's data collection system.
Findings	VS	N/A	Horizontal- Generic	12	[VSTESTCD]_VSTPT	Vital Signs Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What is the planned time point for this vital signs measurement?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for vital signs, if not preprinted on the CRF.	VSTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors VSTPTREF (text description) and VSRFTDTC (date/time) may be needed, as well as SDTMIG variables VSTPTNUM, VSELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header. The planned time point of each measurement can also be collected using a CDASH variable [VSTESTCD]_VSTPT.
Findings	VS	N/A	Horizontal- Generic	13	[VSTESTCD]_VSSTAT	Vital Signs Completion Status	The variable used to indicate that data are not available by having the site recording the value as "Not Done".	Indicate if the [VSTEST] measurement was not done	Not Done	Char	O	Indicate if the vital signs measurement was not done.	VSSTAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ND)	N/A	A single "Not Done" can be collected once for all the tests on the same horizontal record using VSSTAT. The value of VSSTAT applies to all measurements on that record when mapped to SDTM. If needed, for each test "NOT DONE" may be collected using the CDASH variable [VSTESTCD]_VSSTAT.
Findings	VS	N/A	Horizontal- Generic	14	[VSTESTCD]_VSORRES	VS Result or Finding in Original Units	Result of the vital signs measurement as originally received or collected.	What was the result of the [VSTEST] measurement?	[VSTEST] (Result)	Char	HR	Record the vital sign results.	VSORRES; VSTEST; VSTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. In addition to the SDTMIG variable VSORRES, create VSTESTCD from the CDASH variable name and determine the value of VSTEST from VSTESTCD. The CDASH prompt may also contain the VSTEST. Use appropriate CDISC Controlled Terminology for the test and test code.	N/A	N/A	Each test may be collected using the CDASH variable [TESTCD] e.g., SYSBP or [TESTCD]_VSORRES where TESTCD is the appropriate CT for the VS test code e.g., SYSBP_VSORRES. This CDASH variable name is an example of what "variable name" can be used in a denormalized data structure.
Findings	VS	N/A	Horizontal- Generic	15	[VSTESTCD]_VSORRESU	VS Original Units	The unit of the result as originally received or collected.	What was the unit of the [VSTEST] measurement?	[VSTEST] Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	VSORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(VSRESU)	N/A	A single Unit field can be collected once for all measurements collected on the same horizontal record using VSUNIT. The value of VSUNIT applies to all measurements on that record when mapped to SDTM. If needed for each measurement, unit may be collected using the CDASH variable [VSTESTCD]_VSSTAT. Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	VS	N/A	Horizontal- Generic	16	[VSTESTCD]_VSCLSIG	Vital Signs Clinical Significance	An indication whether the vital signs results were clinically significant.	Was the [VSTEST] result clinically significant?	[VSTEST] Clinically Significant	Char	O	Record whether vital sign result was clinically significant.	SUPPVS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPVS dataset as the value of SUPPVS.QVAL where SUPPVS.QNAM = "VSCLSIG" and SUPPVS.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	In horizontal data collection, a CDASH variable [VSTESTCD]_VSCLSIG may be created for each VSTESTCD and added to the CRF if needed.
Findings	VS	N/A	Horizontal- Generic	17	[VSTESTCD]_VSPOS	Vital Signs Position of Subject	The position of the subject during a measurement or examination.	What was the position of the subject during the [VSTEST] measurement?	[VSTEST] Position	Char	R/C	Record the position of subject at time of test (e.g. SITTING).	VSPOS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(POSITION)	(VSPOS)	Results may be affected by whether conditions for vital signs as specified in the protocol were properly met. One common condition is the subject's position. If the protocol requires this type of information, then a CDASH variable [VSTESTCD]_VSPOS may be created for each VSTESTCD and added to the CRF, if needed.
Findings	VS	N/A	Horizontal- Generic	18	[VSTESTCD]_VSLOC	Location of Vital Signs Measurement	A description of the anatomical location of the subject relevant to the collection of Vital Signs measurement.	What was the anatomical location where the [VSTEST] measurement was taken?	[VSTEST] Anatomical Location	Char	O	Record or select location on body where measurement was performed, if not preprinted on CRF.	VSLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location (e.g., ARM for blood pressure). Sponsors may collect the data using a subset list of controlled terminology on the CRF. In horizontal data collection, a CDASH variable [VSTESTCD]_VSLOC may be created for each VSTESTCD and added to the CRF, if needed. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	VS	N/A	Horizontal- Generic	19	[VSTESTCD]_VSLAT	Vital Signs Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the [VSTEST] measurement?	Side	Char	O	Record the side of the anatomical location of the vital signs measurement.	VSLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	VS	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	VS	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	VS	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What is the subject identifier?	Subject	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be provided to the site using a prepopulated list in the system. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM.
Findings	VS	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is represented only in the SDTMIG DM domain. For more information, refer to SDTM Table 2.2.4.
Findings	VS	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	The date the VS measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the observations at that visit, or the collection date can be included on the VS CRF using the Vital Signs Date (VSDAT) field.
Findings	VS	N/A	N/A	6	VSPERF	Vital Signs Performed	An indication whether or not a planned vital signs measurement, series of vital signs measurements, tests, or observations was performed.	Were vital signs performed?	Vital Signs Performed	Char	O	Indicate if the vital signs were collected. If yes, include the appropriate details where indicated on the CRF.	VSSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable VSSTAT. If VSPERF="N", the value of VSSTAT will be "NOT DONE". If VSPERF="Y", VSSTAT should be null. A combination of SDTMIG variables (e.g., VSCAT and VSSCAT, VSTPT) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable VSTESTCD would be populated as VSALL and an appropriate test name VSTEST provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This general prompt question is used as a data management tool to verify that missing results are confirmed missing.
Findings	VS	N/A	N/A	7	VSDAT	Vital Signs Date	The date of the vital signs measurement, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the vital signs measurement?	Date	Char	R/C	Record date of measurements using this format (DD- MON-YYYY).	VSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	The date of measurement can be determined from a collected date of visit (VISDAT) and in such cases a separate measurement date field is not required.
Findings	VS	N/A	N/A	8	VSTIM	Vital Signs Time	The time of measurement, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the vital signs measurement?	Time	Char	R/C	Record time of measurement (as complete as possible).	VSDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable VSDTC in ISO 8601 format.	N/A	N/A	Collect time if it is relevant for the analysis.
Findings	VS	N/A	N/A	9	VSSPID	Vital Signs Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	VSSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor- defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g. line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	VS	N/A	N/A	10	VSTPT	Vital Signs Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What is the planned time point for this vital signs measurement?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for vital signs, if not preprinted on the CRF.	VSTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. The SDTMIG time point anchors VSTPTREF (text description) and VSRFTDTC (date/time) may be needed, as well as SDTMIG variables VSTPTNUM, VSELTM.	N/A	N/A	Planned time points are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	VS	N/A	N/A	11	VSCAT	Category for Vital Signs	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the vital signs?	[Vital Signs Category]; NULL	Char	O		Record the vital signs category, if not preprinted on the CRF.	VSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	VS	N/A	N/A	12	VSSCAT		Subcategory for Vital Signs A sub-division of the VSCAT values based on user-defined characteristics.	What was the subcategory of the vital signs?	[Vital Signs Subcategory]; NULL	Char	O	Record the vital signs subcategory, if not preprinted on the CRF.	VSSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. VSSCAT can only be used if there is a VSCAT and it must be a subcategorization of VSCAT.
Findings		VS	N/A	N/A	13	VSREPNUM	Vital Signs Repetition Number	The instance number of a test that is repeated within a given timeframe for the same test. The level of granularity can vary (e.g., within a time point, within a visit).	What was the repetition number within the time point for this measurement?	Repetition Number	Char	O	Record the repetition number of the measurement within the time point.	SUPPVS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPVS dataset as the value of SUPPVS.QVAL where SUPPVS.QNAM= "VSREPNUM" and SUPPVS.QLABEL= "Repetition Number within time point". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	N/A The repetition number of the test/measurement within the time point may be preprinted on the CRF (e.g., multiple measurements of blood pressure, multiple analyses of a sample).
Findings	VS	N/A	N/A	14	VSTEST	Vital Signs Test Name	Descriptive name of the test or examination used to obtain the measurement or finding.	What is the vital sign test name?	[Vital Signs Test Name]	Char	HR	Record the name of the vital sign test if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	VSTEST; VSTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. The SDTMIG variable VSTESTCD may be determined from the value collected in VSTEST. Both VSTESTCD and VSTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(VSTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	VS	N/A	N/A	15	VSSTAT	Vital Signs Completion Status	The variable used to indicate that data are not available by having the site recording the value as "Not Done".	Indicate if the vital signs measurement was not done	Not Done	Char	O	Indicate if the vital sign measurement was not done.	VSSTAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(ND)	N/A	A Not Done check box, which indicates the test was NOT DONE. Typically, there would be one check box for each measurement. This field can be useful on individual vital signs tests to confirm that a blank result field is meant to be blank.
Findings	VS	N/A	N/A	16	VSORRES	VS Result or Finding in Original Units	Result of the vital signs measurement as originally received or collected.	What was the result of the measurement?	(Result)	Char	HR	Record the vital sign result.	VSORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	VS	N/A	N/A	17	VSORRESU	VS Original Units	The unit of the result as originally received or collected.	What was the unit of the measurement?	Unit	Char	R/C	Record or select the original unit in which these data were collected, if not preprinted on CRF.	VSORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(VSRESU)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	VS	N/A	N/A	18	VSCLSIG	Vital Signs Clinical Significance	An indication whether the vital sign result was clinically significant.	Was the result clinically significant?	Clinically Significant	Char	O	Record whether vital sign result was clinically significant.	SUPPVS.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPVS dataset as the value of SUPPVS.QVAL where SUPPVS.QNAM = "VSCLSIG" and SUPPVS.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	N/A
Findings	VS	N/A	N/A	19	VSLOC	Location of Vital Signs Measurement	A description of the anatomical location of the subject relevant to the collection of Vital Signs measurement.	What was the anatomical location where the measurement was taken?	Anatomical Location	Char	O	Record or select location on body where measurement was performed, if not preprinted on CRF.	VSLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location (e.g., ARM for blood pressure). Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	VS	N/A	N/A	20	VSPOS	Vital Signs Position of Subject	The position of the subject during a measurement or examination.	What was the position of the subject during the measurement?	Position	Char	R/C	Record the position of subject at time of test (e.g. SITTING).	VSPOS	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(POSITION)	(VSPOS)	Results may be affected by whether conditions for vital signs as specified in the protocol were properly met. One common condition is the subject's position.
Findings	VS	N/A	N/A	21	VSDIR	Vital Signs Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the measurement?	Directionality	Char	O	Record the directionality.	VSDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	VS	N/A	N/A	22	VSLAT	Vital Signs Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the vital signs measurement?	Side	Char	O	Record the side of the anatomical location of the vital signs measurement.	VSLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.

Assumptions for the CDASHIG VS - Vital Signs Domain

1. Vital Signs may be collected using either a normalized or a denormalized horizontal data structure, depending on the functionality of the data management or data capture system being used.

2. In a denormalized structure, Vital Signs are collected using a unique variable name for each test, resulting in a wide, horizontal dataset with multiple test results in each record. The SDTMIG VS structure is normalized, using 1 variable (VSTEST) for the name of the test and 1 variable (VSORRES) for the collected results, resulting in a vertical data structure in which there is 1 record for each test/result. CDASH recommendations are intended to facilitate moving denormalized data to the SDTM normalized data structure, because standard transformation programming can be written when the variable naming syntax is consistent and uses CDISC root variables and Controlled Terminology.

3. The set of variables needed for a particular study may include only test result and result unit, or it may include other variables such as location, laterality, position, or method. The examples in this section show a couple of different ways that denormalized variable names can be created based on the general variable- naming rules of CDASH, using the root variables found in the CDASH Model in combination with the controlled terminology from the Vital Signs Test Code codelist (VSTESTCD) in a consistent syntax.

Example CRFs for the CDASHIG VS - Vital Signs Domain

Example 1

This example shows a vital signs data collection in a denormalized structure with variable names that could be 8 or more characters. The following syntax was used to create the denormalized variable names: _.

Title: Vital Signs





CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
VSDAT	1	What was the date of the measurements?	Date	Record date of measurements using this format (DD-MON- YYYY).	Date	VSDTC					Prompt
VSTIM	2	What was the time of the measurements?	Time	Record time of measurement.	Time	VSDTC					Prompt
HEIGHT_VSORRES	3	What was the result of the height measurement?	Height	Record the height result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "HEIGHT"				Prompt
HEIGHT_VSORRESU	4	What was the unit of the height measurement?	Height Unit	Record or select the original unit in which the height was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "HEIGHT"	(VSRESU)	cm; in		Prompt
WEIGHT_VSORRES	5	What was the result of the weight measurement?	Weight	Record the weight result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "WEIGHT"				Prompt
WEIGHT_VSORRESU	6	What was the unit of the weight measurement?	Weight Unit	Record or select the original unit in which the weight collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "WEIGHT"	(VSRESU)	kg; LB		Prompt
TEMP_VSORRES	7	What was the result of the temperature measurement?	Temperature	Record the temperature result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "TEMP"				Prompt
TEMP_VSORRESU	8	What was the unit of the temperature measurement?	Temperature Unit	Record or select the original unit in which the temperature was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "TEMP"	(VSRESU)	C; F		Prompt
TEMP_VSLOC	9	What was the anatomical location where the temperature measurement was taken?	Temperature Anatomical Location	Record or select location on body where the measurement was performed, if not pre- printed on CRF.	Text	VSLOC	VSLOC where VSTESTCD = "TEMP"	(LOC)	AXILLA; EAR; FOREHEAD; ORAL CAVITY; RECTUM		Prompt
TEMP_VSCLSIG	10	Was the temperature result clinically significant?	Temperature Clinically Significant	Record whether the temperature result was clinically significant.	Text	SUPPVS.QVAL	SUPPVS.QVAL where QNAM = "VSCLSIG" and QLABEL = "Clinically Significant" and VSTESTCD = "TEMP"	(NY)	Yes; No		Prompt
RESP_VSORRES	11	What was the result of the respiratory rate measurement?	Respiratory Rate	Record the vital sign result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "RESP"				Prompt
RESP_VSORRESU	12	What was the unit of the respiratory rate measurement?	Respiratory Rate Unit	Record or select the original unit in which the respiratory rate was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "RESP"	(VSRESU)		breaths/min	Prompt
RESP_VSCLSIG	13	Was the respiratory rate result clinically significant?	Respiratory Rate Clinically Significant	Record whether the respiratory rate result was clinically significant.	Text	SUPPVS.QVAL	SUPPVS.QVAL where QNAM = VSCLSIG and QLABEL = "Clinically Significant" and VSTESTCD = "RESP"	(NY)	Yes; No		Prompt
SYSBP_VSORRES	14	What was the result of the systolic blood pressure measurement?	Systolic Blood Pressure	Record the systolic blood pressureresult.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "SYSBP"				Prompt
SYSBP_VSORRESU	15	What was the unit of the systolic blood pressure measurement?	Systolic Blood Pressure Unit	Record or select the original unit in which the systolic blood pressure was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "SYSBP"	(VSRESU)		mmHg	Prompt
SYSBP_VSCLSIG	16	Was the systolic blood pressure result clinically significant?	Systolic Blood Pressure Clinically Significant	Record whether the systolic blood pressure result was clinically significant.	Text	SUPPVS.QVAL	SUPPVS.QVAL where QNAM = "VSCLSIG" and QLABEL = Clinically Significant and VSTESTCD = "SYSBP"	(NY)	Yes; No		Prompt
SYSBP_VSPOS	17	What was the position of the subject during the systolic blood pressure measurement?	Systolic Blood Pressure Position	Record the position of subject at time of test (e.g. SITTING).	Text	VSPOS	VSPOS where VSTESTCD = "SYSBP"	(POSITION)	STANDING; SITTING; SUPINE		Prompt
SYSBP_VSLOC	18	What was the anatomical location where the systolic blood pressure measurement was taken?	Systolic Blood Pressure Anatomical Location	Record or select location on body where the measurement was performed, if not pre- printed on CRF.	Text	VSLOC	VSLOC where VSTESTCD = "SYSBP"	(LOC)	BRACHIAL ARTERY; RADIAL ARTERY; PERIPHERAL ARTERY		Prompt
SYSBP_VSLAT	19	What was the side of the anatomical location of the systolic blood pressure measurement?	Systolic Blood Pressure Side	Record the side of the anatomical location of the systolic blood pressure measurement.	Text	VSLAT	VSLAT where VSTESTCD = "SYSBP"	(LAT)	RIGHT; LEFT		Prompt
DIABP_VSORRES	20	What was the result of the diastolic blood pressure measurement?	Diastolic Blood Pressure	Record the diastolic blood pressure result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "DIABP"				Prompt
DIAPU_VSORRESU	21	What was the unit of the diastolic blood pressure measurement?	Diastolic Blood Pressure Unit	Record or select the original unit in which the diastolic blood pressure was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "DIABP"	(VSRESU)		mmHg	Prompt
DIABP_VSCLSIG	22	Was the diastolic blood pressure result clinically significant?	Diastolic Blood Pressure Clinically Significant	Record whether the diastolic blood pressure result was clinically significant.	Text	SUPPVS.QVAL	SUPPVS.QVAL where QNAM = "VSCLSIG" and QLABEL = "Clinically Significant" and VSTESTCD = "DIABP"	(NY)	Yes; No		Prompt
DIABP_VSPOS	23	What was the position of the subject during the diastolic blood pressure measurement?	Diastolic Blood Pressure Position	Record the position of subject at time of test (e.g. SITTING).	Text	VSPOS	VSPOS where VSTESTCD = "DIABP"	(POSITION)	STANDING; SITTING; SUPINE		Prompt
DIABP_VSLOC	24	What was the anatomical location where the diastolic blood pressure measurement was taken?	Diastolic Blood Pressure Anatomical Location	Record or select location on body where the measurement was performed, if not pre- printed on CRF.	Text	VSLOC	VSLOC where VSTESTCD = "DIABP"	(LOC)	BRACHIAL ARTERY; RADIAL ARTERY; PERIPHERAL ARTERY		Prompt
DIABP_VSLAT	25	What was the side of the anatomical location of the diastolic blood pressure measurement?	Diastolic Blood Pressure Side	Record the side of the anatomical location of the diastolic blood pressure measurement.	Text	VSLAT	VSLAT where VSTESTCD = "DIABP"	(LAT)	RIGHT; LEFT		Prompt
PULSE_VSORRES	26	What was the result of the pulse measurement?	Pulse Rate	Record the pulse rate result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "PULSE"				Prompt
PULSE_VSORRESU	27	What was the unit of the pulse rate measurement?	Pulse Rate Unit	Record or select the original unit in which the pulse rate was collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "PULSE"	(VSRESU)		beats/min	Prompt
PULSE_VSCLSIG	28	Was the pulse rate result clinically significant?	Pulse Rate Clinically Significant	Record whether the pulse rate result was clinically significant.	Text	SUPPVS.QVAL	SUPPVS.QVAL where QNAM = "VSCLSIG" and QLABEL = "Clinically Significant" and VSTESTCD = "PULSE"	(NY)	Yes; No		Prompt
PULSE_VSPOS	29	What was the position of the subject during the pulse rate measurement?	Pulse Rate Position	Record the position of subject at time of test (e.g. SITTING).	Text	VSPOS	VSPOS where VSTESTCD = "PULSE"	(POSITION)	STANDING; SITTING; SUPINE		Prompt
PULSE_VSLOC	30	What was the anatomical location where the pulse rate measurement was taken?	Pulse Rate Anatomical Location	Record or select location on body where pulse rate measurement was performed.	Text	VSLOC	VSLOC where VSTESTCD = "PULSE"	(LOC)	BRACHIAL ARTERY; CAROTID ARTERY; DORSALIS PEDIS ARTERY; FEMORAL ARTERY; RADIAL ARTERY		Prompt
PULSE_VSLAT	31	What was the side of the anatomical location of the pulse rate measurement?	Pulse Rate Side	Record the side of the anatomical location of the pulse rate measurement.	Text	VSLAT	VSLAT where VSTESTCD = "PULSE"	(LAT)	RIGHT; LEFT		Prompt

Example 2

This example shows a vital signs data collection in a denormalized structure with variable names restricted to 8 characters or less. The VSTESTCD values were used to create the denormalized variable names.

Title: Vital Signs



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
VSDAT	1	What was the date of the measurements?	Date	Record date of measurements using this format (DD-MON-YYYY).	Date	VSDTC					Prompt
VSTIM	2	What was the time of the measurements?	Time	Record time of measurement.	Time	VSDTC					Prompt
HEIGHT	3	What was the result of the height measurement?	Height	Record the height result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "HEIGHT"				Prompt
HEIGHTU	4	What was the unit of the height measurement?	Height Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "HEIGHT"	(VSRESU)	cm; in		Prompt
WEIGHT	5	What was the result of the weight measurement?	Weight	Record the weight result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "WEIGHT"				Prompt
WEIGHTU	6	What was the unit of the weight measurement?	Weight Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "WEIGHT"	(VSRESU)	kg; LB		Prompt
TEMP	7	What was the result of the temperature measurement?	Temperature	Record the temperature result.	Float	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "TEMP"				Prompt
TEMPU	8	What was the unit of the temperature measurement?	Temperature Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "TEMP"	(VSRESU)	C; F		Prompt
RESP	9	What was the result of the respiratory rate measurement?	Respiratory Rate	Record the respiratory rate result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "RESP"				Prompt
RESPU	10	What was the unit of the respiratory rate measurement?	Respiratory Rate Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "RESP"	(VSRESU)		breaths/min	Prompt
SYSBP	11	What was the result of the systolic blood pressure measurement?	Systolic Blood Pressure	Record the systolic blood pressure result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "SYSBP"				Prompt
SYSBPU	12	What was the unit of the systolic blood pressure measurement?	Systolic Blood Pressure Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "DIABP"	(VSRESU)		mmHg	Prompt
DIABP	13	What was the result of the diastolic blood pressure measurement?	Diastolic Blood Pressure	Record the diastolic blood pressure result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "DIABP"				Prompt
DIABPU	14	What was the unit of the diastolic blood pressure measurement?	Diastolic Blood Pressure Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "DIABP"	(VSRESU)		mmHg	Prompt
PULSE	15	What was the result of the pulse measurement?	Pulse Rate	Record the pulse rate result.	Integer	VSORRES; VSTEST; VSTESTCD	VSORRES where VSTESTCD = "PULSE"				Prompt
PULSEU	16	What was the unit of the pulse rate measurement?	Pulse Rate Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	Text	VSORRESU	VSORRESU where VSTESTCD = "PULSE"	(VSRESU)		beats/min	Prompt

8.3.19 FA - Findings About Events or Interventions

Description/Overview for the CDASHIG FA - Findings About Events or Interventions Domain

The Findings class also includes the subtype Findings About, which is used to record findings related to observations in the Interventions or Events class.

Specification for the CDASHIG FA - Findings About Events or Interventions Domain

Findings About Events or Interventions Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	FA	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	FA	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	FA	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier? [Subject/Participant] (Identifier)	>	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	FA	N/A	N/A	4	FAOBJ	Findings About Object of the Observation	A description of the object or focal point of the findings observation that is represented by FATEST.	[Sponsored-defined phrase]	[Sponsored-defined phrase]	Char	HR	[Protocol specific]	FAOBJ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The FAOBJ will usually be preprinted or hidden, and not solicited as an actual question. These FA domains are usually created by the sponsor.
Findings	FA	N/A	N/A	5	FAYN	Findings About Collected	An indication whether or not any data was collected for the finding topic.	Has the subject had any [Findings topic(s)] (after/ before [study specific time frame])?; [Was/ Were] (there) any [Findings topic(s)] (reported) (after/before [study specific time frame])?; Were all eligibility criteria met?	Any [Finding Topic]	Char	O	Indicate if the there are findings. If yes, include the appropriate details where indicated on the CRF.	N/A	Does not map to an SDTM variable. The SDTM aCRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	N/A	This is a field that can be used in any CRF to indicate whether or not there is data to record. Used primarily as a data cleaning field. This provides verification that all other fields on the CRF were deliberately left blank. FAPERF should be used to capture a response about whether planned measurements, tests, observations were done.
Findings	FA	N/A	N/A	6	FAPERF	Findings About Performed	An indication of whether or not a planned measurement, series of measurements, test, observation or specimen was performed or collected.	[Were any/Was the] [FATEST/topic] ([measurement(s)/test(s)/examin ation(s)/ specimen(s)/sample(s))] [performed/collected]?	([FATEST/ topic] ([Measurement (s)/Test(s)/Examination(s)/Specimen(s)/ Sample(s)]) [Performed/Collected]?	Char	O	Indicate if the [FATESTs] was/were collected. If yes, include the appropriate details where indicated on the CRF.	FASTAT	This field does not map directly to an SDTM variable. May be used to populate a value into the SDTM variable FASTAT. If the CDASH variable FAPERF="N", the value of the STDM variable FASTAT is "OT DONE". If FAPERF="Y", FASTAT is null. A combination of SDTM variables (e.g., FACAT and FASCAT, FATPT ) is used to indicate that multiple tests were not done. In this situation, the SDTM variable FATESTCD would be populated with FAALL and an appropriate test name (FATEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	This field is used to capture a response to whether or not a planned measurement, test or observation was performed. A negative response can be collected as "N" and mapped to the FASTAT variable in SDTM as "NOT DONE".
Findings	FA	N/A	N/A	7	FATEST	Findings About Test Name	Descriptive name for the test being performed.	What [is/was] the name (of the [measurement/test/examination]) ?	[Measurement/Test/Examination/] (Name)	Char	HR	Record the name of the FATEST if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	FATEST;FATE STCD	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target. The SDTM variable FATESTCD may be determined from the value collected in FATEST. The SDTMIG variables FATESTCD and FATEST are required in SDTM.	N/A	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	FA	N/A	N/A	8	FATSTDTL	Findings About Test Detail	A further description of FATESTCD and FATEST.	What [is/was] the [measurement/test/ examination] detail name?	[Measurement/Test/Examination] Detail (Name)	Char	O	Record the detail of the [FATEST], if not preprinted on the CRF.	FATSTDTL	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	It is recommended that the test detail name be preprinted on the CRF. If the form is laid out as a grid, then words such as "Test," "Test Name" can be included as the column header.
Findings	FA	N/A	N/A	9	FACAT	Category for Findings About	A grouping of topic- variable values based on user- defined characteristics.	What [is/was] the [type/category/name] (of the [measurement/test/examination/ specimen/sample])?	[Category/Category Value]; NULL	Char	O	Record the FA category, if not preprinted on the CRF.	FACAT	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	FA	N/A	N/A	10	FASCAT	Subcategory for Findings About	A sub-division of the FACAT values based on user-defined characteristics.	What [is/was] the [type/subcategory/name] (of the [measurement/test/examination/ specimen/sample])?	[FA Subcategory/FA Subcategory Value]; NULL	Char	O	Record the FA subcategory, if not preprinted on the CRF.	FASCAT	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor-defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. FASCAT can only be used if there is a FACAT and it must be a subcategorization of FACAT.
Findings	FA	N/A	N/A	11	FAPOS	Findings About Position of Subject	The position of the subject during a measurement or examination.	In what position was the subject during the [measurement/ test/examination/specimen collection/sample collection]?; What was the position of the subject (during the [measurement/test/examination/s pecimen collection/sample collection])?	Position	Char	O	Record the position of the subject during the Findings About Test	FAPOS	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(POSITION)	N/A	N/A
Findings	FA	N/A	N/A	12	FAORRES	FA Result or Finding in Original Units	Result of the measurement or finding as originally received or collected.	What [is/was] the [result/amount/(subject's) characteristic] (of the [measurement/test/examination/q uestion/ assessment])?	([Result/Amount] of) [value from FATEST]	Char	HR	Record the FATEST result.	FAORRES	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	In most cases, the Question Text and Item Prompt for the FAORRES are specific to the FATEST. The value of FATEST is most useful as the PROMPT on the field in which the RESULT for that test is collected. If the form is laid out as a grid, then words such as "Result" can be included as the column header.
Findings	FA	N/A	N/A	13	FAORRESU	FA Original Units	The unit of the result as originally received or collected.	What [is/was] the unit (of the [measurement/test/examination]) ?	Unit	Char	R/C	Record or select the unit of measure associated with the test, if not preprinted on the CRF.	FAORRESU	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	The Question Text and Item Prompt for the FAORRESU may be specific to the FATEST. Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text (e.g., IN, LB, kg/L).
Findings	FA	N/A	N/A	14	FAORNRLO	FA Normal Range Lower Limit- Orig Unit	The lower end of normal range or reference range for continuous results stored in --ORRES.	What [is/was] the lower limit of the reference range (for the [measurement/test/ examination])?	Normal Range Lower Limit	Char	O	Record the lower limit of the reference range of the Findings About test.	FAORNRLO	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	--ORNRLO should be populated only for continuous findings. The SDTM variable -- STNRC should be populated only for non-continuous results. These data may be obtained from the lab or the electronic equipment. These data could be derived from a site- or lab- specific set of normal ranges stored in a look-up table.
Findings	FA	N/A	N/A	15	FAORNRHI	FA Normal Range Upper Limit- Orig Unit	The upper end of normal range or reference range for continuous results stored in --ORRES.	What [is/was] the upper limit of the reference range (for the [measurement/test/ examination])?	Normal Range Upper Limit	Char	O	Record the upper limit of the reference range of the Findings About test.	FAORNRHI	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	--ORNRHI should be populated only for continuous findings. The SDTM variable --STNRC should be populated only for non-continuous results. These data may be obtained from the lab or the electronic equipment. These data could be derived from a site- or lab-specific set of normal ranges stored in a look-up table.
Findings	FA	N/A	N/A	16	FANRIND	Findings About Reference Range Indicator	An indication or description about how the value compares to the normal range or reference range.	How [did/do] the reported values compare within the [reference/normal/expected] range?	Comparison to [Reference/Expected/ Normal] Range	Char	O	Record where the test results were categorized within the respective reference range (e.g. HIGH, LOW, ABNORMAL).	FANRIND	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(NRIND)	N/A	Reference ranges may be defined by FAORNRLO, FAORNRHI, FASTNRC or other objective criteria. Reference Range Indicator may be included if not derived or determined programmatically after data collection. Should not be used to indicate clinical significance.
Findings	FA	N/A	N/A	17	FASTAT	Findings About Completion Status	The variable used to indicate that data are not available by having the site recording the value as "Not Done".	Was the [--TEST ] not [completed/answered/done/asses sed/ evaluated ]?; Indicate if the([--TEST] was) not [answered/assessed/done/evalua ted/ performed].	Not Done	Char	O	Indicate if the [FATEST] measurement was not done.	FASTAT	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target. If collected, the Origin (a column in the Define-XML) ="CRF", if populated from other sources such as a free text or sponsor-defined listing for FAREASND, the Origin ="DERIVED".	(ND)	N/A	Used only when the response value is collected as NOT DONE or NULL in lieu of or in addition to the CDASH FAPERF field. Typically a check box which indicates the test was NOT DONE. This field can be useful when multiple questions are asked to confirm that a blank result field is meant to be blank.
Findings	FA	N/A	N/A	18	FAREASND	Findings About Reason Not Performed	An explanation of why the data are not available.	Was the [is/was] the reason that the [Findings topic/data/information/sponsor- defined phrase] was not [collected/answered/done/assess ed/ evaluated]?	Reason Not [Answered/Collected/Done/Evaluated/ Assessed/Available]	Char	O	Provide the reason why a Finding About test was not collected.	FAREASND	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology may be used. The reason the data are not available may be chosen from a sponsor-defined codelist (e.g., broken equipment, subject refused, etc.) or entered as free text. When --REASND is used, --STAT should also be populated in the SDTM-based dataset.
Findings	FA	N/A	N/A	19	FASPEC	Findings About Specimen Type	The type of specimen used for a measurement.	What [is/was] the specimen type? Specimen Type		Char	O	Record the specimen material type.	FASPEC	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(SPECTYPE)	N/A	The type of specimen used for a measure. Should be collected if not available elsewhere, or if required to differentiate multiple specimens.
Findings	FA	N/A	N/A	20	FASPCCND	Findings About Specimen Condition	Description of the condition of the specimen.	What [is/was] the condition of the specimen?	Specimen Condition	Char	O	Record condition of specimen.	FASPCCND	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(SPECCOND)	N/A	May be collected using free or standardized text. Results may be affected by whether conditions for specimen were properly met. When Local Processing is used, sponsors may not routinely collect specimen condition.
Findings	FA	N/A	N/A	21	FALOC	Location of the Finding About	The anatomical location of the subject relevant to the collection of the measurement.	What [is/was] the anatomical location (of the [measurement/test/examination]) or What [is/was] the anatomical location where the [measurement/specimen] was taken/collected)?	Anatomical Location	Char	O	Record or select location on body where measurement was performed, if not preprinted on CRF.	FALOC	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location. Example: ARM for blood pressure. Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	FA	N/A	N/A	22	FALAT	Laterality of Location of Finding About	Qualifier for anatomical location further detailing the side of the body.	What [is/was] the side (of the anatomical location of the [measurement/test/examination]) ?	Side	Char	O	Record the side of the anatomical location of the [FATEST] measurement.	FALAT	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	FA	N/A	N/A	23	FADIR	Findings About Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What [is/was] the directionality (of the anatomical location of the [measurement/test/ examination])?	Directionality	Char	O	Record the directionality.	FADIR	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	FA	N/A	N/A	24	FAPORTOT	FA Location Portion or Totality	Qualifier for anatomical location further detailing the distribution, which means arrangement of, apportioning of.	What [is/was] the portion or totality (of the anatomical location of the [measurement/test/examination]) ?	Portion or Totality	Char	O	Indicate the portion or totality anatomical location of the Findings About.	FAPORTOT	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(PORTOT)	N/A	Collected when the sponsor needs to identify the specific portionality for the anatomical locations of the location of the FATEST. Sponsors may collect the data using a subset list of Controlled Terminology on the CRF.
Findings	FA	N/A	N/A	25	FAMETHOD	Findings About Method	Method of the test or examination.	What was the method (used for the [measurement/test/examination]) ?	Method	Char	O	Record the method used to measure Findings About test.	FAMETHOD	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(METHOD)	N/A	N/A
Findings	FA	N/A	N/A	26	FALEAD	Findings About Lead	The lead or leads identified to capture the measurement for a test from an instrument.	What [is/was] the lead (used to measure [measurement/test/examination]) ?	Lead	Char	O	Record the lead used to measure Findings About test.	FALEAD	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	FA	N/A	N/A	27	FAFAST	Findings About Fasting Status	An indication that the subject has abstained from food/water for the specified amount of time.	[Is/Was] the subject fasting (prior to the [test being performed/sample being collected])?	Fasting	Char	O	Record whether the subject was fasting prior to the test being performed.	FAFAST	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(NY)	N/A	Results may be affected by whether the subject was fasting. This may not be relevant for all tests.
Findings	FA	N/A	N/A	28	FAEVAL	Findings About Evaluator	The role of the person who provided the evaluation.	Who provided the (sponsor- defined phrase) information?; Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	FAEVAL	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted, or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	FA	N/A	N/A	29	FAEVALID	Findings About Evaluator Identifier	An identifier used to distinguish multiple evaluators with the same role recorded in FAEVAL.	What [is/was] the identifier of the [evaluator name/reporter name] (providing the-sponsor-defined phrase-information)?	[Evaluator/Reporter] Identifier	Char	O	Record the unique identifier assigned to the person making the evaluation.	FAEVALID	Maps directly to the SDTM variable listed in the column with the heading SDTMIG Target.	(MEDEVAL)	N/A	This variable is used in conjunction with FAEVAL to provide an additional level of detail.
Findings	FA	N/A	N/A	30	FACLSIG	Findings About Clinical Significance	An indication whether the test results were clinically significant	[Is/Was] the ([measurement/test/examination]) result clinically significant?	([Measurement/Test/Examination/])/Clinically Significant	Char	O	Record whether [FATEST] result was clinically significant.	SUPPFA.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPFA dataset as the value of SUPPFA.QVAL when SUPPFA.QNAM = "CLSIG" and SUPPFA.QLABEL = "Clinical Significance". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.	(NY)	N/A	N/A

Assumptions for the CDASHIG FA - Findings About Events or Interventions Domain

1. The Findings About Events or Intervention domains use the same root variables as the Findings domain with the addition of the --OBJ variable

Example CRFs for the CDASHIG FA - Findings About Events or Interventions Domain

Example 1

In this sample CRF, data on symptoms associated with the clinical event of interest, migraine headaches, are collected.

Title: Migraine Symptoms



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
CETERM	1	What is the clinical event term?	Clinical Event	Record the clinical event or [insert text corresponding to the specific clinical event].	Text	CETERM				MIGRAINE	Prompt		Yes
CESTDAT	2	What was the migraine start date?	Start Date	Record the start date of the clinical event represented in an unambiguous date format (e.g., DD-MON-YYYY).	Date	CESTDTC					Qtext
CESTTIM	3	What was the migraine start time?	Start Time	Record the start time of the clinical event represented in an unambiguous date format (e.g., hh:mm:ss).	Time	CESTDTC					Qtext
FACAT	4	What was the category?	Category	Record the FA category, if not pre-printed on the CRF.	Text	FACAT				MIGRAINE SYMPTOMS	Prompt		Yes
SENSLGHT_FAORRES	6	What was the occurrence of sensitivity to light with the migraine?	Sensitivity to Light	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "SENSITIVITY TO LIGHT"	NY	No; Yes		Prompt	Radio
SENSOUND_FAORRES	7	What was the occurrence of sensitivity to sound with the migraine?	Sensitivity to Sound	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "SENSITIVITY TO SOUND"	NY	No; Yes		Prompt	Radio
NAUSEA_FAORRES	8	What was the occurrence of nausea with the migraine?	Nausea	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "NAUSEA"	NY	No; Yes		Prompt	Radio
AURA_FAORRES	9	What was the occurrence of aura with the migraine?	Aura	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "AURA"	NY	No; Yes		Prompt	Radio

Example

In this sample CRF, data about pre-specified symptoms of the disease under study are collected on a daily basis. The date of the assessment is captured, but start and end timing of the pre-populated symptoms are not.

Title: Findings About GERD Symptoms



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target	SDTM Variable Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
FADAT	1	What is the date of the daily assessment?	Assessment Date	Record the date assessment was done using this format (DD-MON-YYYY).	Date	FADTC					Prompt
OCCUR_VOMIT_FAORRES	2	What was the occurrence of vomiting?	Vomiting	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "VOMITING" when Y or N; FASTAT = "NOT DONE" when ND	(NY); (ND)	No; Yes; Not Done		Prompt	Radio
VOL_VOMIT_FAORRES	3	What was the volume of the vomit?	Volume of Vomit	Record the volume result.	Text	FAORRES	FAORRES where FATESTCD = "VOL" and FAOBJ = "VOMITING"
VOL_VOMIT_FAORRESU	4	What was the unit of the volume?	Unit	Record or select the unit of measure associated with the test, if not pre- printed on the CRF.	Text	FAORRESU	FAORRESU where FATESTCD = "VOL" and FAOBJ = "VOMITING"	(UNIT)	mL	mL	Prompt	Radio
NUMEPISD_VOMIT_FAORRES	5	What was the number of episodes of the vomiting?	Number of Episodes of Vomiting	Record the number of episodes result.	Text	FAORRES	FAORRES where FATESTCD = "NUMEPISD" and FAOBJ = "VOMITING"
SEV_VOMIT_FAORRES	6	What was the maximum severity of the vomiting?	Maximum Severity of Vomiting	Record the severity result.	Text	FAORRES	FAORRES where FATESTCD = "SEV" and FAOBJ = "VOMITING"	(AESEV)	Mild; Moderate; Severe			Radio
OCCUR_DIAR_FAORRES	7	What was the occurrence of diarrhea?	Diarrhea	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "DIARRHEA" when Y or N; FASTAT = "NOT DONE" when ND	(NY); (ND)	No; Yes; Not Done		Prompt	Radio
NUMEPISD_DIAR_FAORRES	8	What was the number of episodes of the diarrhea?	Number of Episodes of Diarrhea	Record the number of episodes result.	Text	FAORRES	FAORRES where FATESTCD = "NUMEPISD" and FAOBJ = "DIARRHEA"
SEV_DIAR_FAORRES	9	What was the maximum severity of the diarrhea?	Maximum Severity of Diarrhea	Record the severity result.	Text	FAORRES	FAORRES where FATESTCD = "SEV" and FAOBJ = "DIARRHEA"	(AESEV)	Mild; Moderate; Severe			Radio
OCCUR_NAUS_FAORRES	10	What was the occurrence of nausea?	Nausea	Record the occurrence result.	Text	FAORRES	FAORRES where FATESTCD = "OCCUR" and FAOBJ = "NAUSEA" when Y or N; FASTAT = "NOT DONE" when ND	(NY); (ND)	No; Yes; Not Done		Prompt	Radio
NUMEPISD_NAUS_FAORRES	11	What was the number of episodes of the nausea?	Number of Episodes of Nausea	Record the number of episodes result.	Text	FAORRES	FAORRES where FATESTCD = "NUMEPISD" and FAOBJ = "NAUSEA"
SEV_NAUS_FAORRES	12	What was the maximum severity of the nausea?	Maximum Severity of Nausea	Record the severity result.	Text	FAORRES	FAORRES where FATESTCD = "SEV" and FAOBJ = "NAUSEA"	(AESEV)	Mild; Moderate; Severe			Radio

8.3.19.1 SR - Skin Response

Description/Overview for the CDASHIG SR - Skin Response Domain

The SR domain is a Findings About domain used to collect dermal responses to antigens.

Specification for the CDASHIG SR - Skin Response Domain

Skin Response Metadata Table

Observation Class	Domain	Data Collection Scenario	Implementation Options	Order Number	CDASHIG Variable	CDASHIG Variable Label	DRAFT CDASHIG Definition	Question Text	Prompt	Data Type	CDASHIG Core	Case Report Form Completion Instructions	SDTMIG Target	Mapping Instructions	Controlled Terminology Codelist Name	Subset Controlled Terminology/ CDASH Codelist Name	Implementation Notes
Findings	SR	N/A	N/A	1	STUDYID	Study Identifier	A unique identifier for a study.	What is the study identifier?	[Protocol/Study]	Char	HR	N/A	STUDYID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	While this field is not typically captured on a CRF, it should be displayed clearly on the CRF and/or the EDC system. This field can be included into the database or populated during SDTM-based dataset creation before submission.
Findings	SR	N/A	N/A	2	SITEID	Study Site Identifier	A unique identifier for a site within a study.	What is the site identifier?	Site (Identifier)	Char	HR	N/A	DM.SITEID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically preprinted in the header of each CRF page for single site studies. For studies with multiple sites, this field may be left blank so that the number can be recorded by the site, or it may be preprinted on the CRFs that are shipped to each site. EDC: This should be prepopulated.
Findings	SR	N/A	N/A	3	SUBJID	Subject Identifier for the Study	A unique subject identifier within a site and a study.	What [is/was] the (study) [subject/participant] identifier?	[Subject/Participant] (Identifier)	Char	HR	Record the identifier for the subject.	DM.SUBJID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Paper: This is typically recorded in the header of each CRF page. EDC: The subject identifiers may be system generated. This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. For more information, refer to the SDTM Implementation Guide.
Findings	SR	N/A	N/A	4	VISIT	Visit Name	The name of a clinical encounter that encompasses planned and unplanned trial interventions, procedures, and assessments that may be performed on a subject.	What is the visit name?	[Visit]	Char	R/C	N/A	VISIT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The name of the visit is typically preprinted on the CRF, and should match the name of the visit in the protocol. May be used to derive the SDTM variable VISITNUM. Note: Sponsors may have CDASH visit numbering or visit naming conventions to handle special circumstances (e.g., unscheduled visits). In these cases, the appropriate visit numbers and visit names, may need to be populated when the SDTM submission datasets are created.
Findings	SR	N/A	N/A	5	VISDAT	Visit Date	Date the clinical encounter occurred (or started).	What [is/was] the date of the visit?	(Visit) Date	Char	R/C	Record the [date/start date] of the visit using DD-MON-YYYY format.	N/A	This field is not an SDTM variable. The date of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM) and then concatenating the CDASH VISDAT/VISTIM components and populating the SDTMIG variable SRDTC in ISO 8601 format.	N/A	N/A	The date the skin response measurements were collected can be determined from the Visit Date variable (VISDAT) and applying that date to all of the skin response measurements at that visit, or the collection date can be included on the Skin Response CRF using the date (SRDAT) field.
Findings	SR	N/A	N/A	6	SRPERF	Skin Response Test Performed	An indication whether or not a planned skin response measurement, series of skin response measurements, tests, or observations was performed.	Was a skin response test performed?	Skin Response Test Performed	Char	O	Indicate if a skin response test as performed.	SRSTAT	This does not map directly to an SDTMIG variable. May be used to derive a value into the SDTM variable SRSTAT. If SRPERF="N", the value of SRSTAT will be "NOT DONE". If SRPERF="Y", SRSTAT should be null. A combination of SDTMIG variables (e.g., SRCAT and SRSCAT, SRTPT ) is used to indicate that multiple tests were not done. In this situation, the SDTMIG variable SRTESTCD would be populated as SRALL and an appropriate test name (SRTEST) provided. See SDTMIG v3.2 Section 4.1.5.1.2.	(NY)	N/A	General prompt question to be used as a data management tool to verify that missing results are confirmed missing.
Findings	SR	N/A	N/A	7	SRREASND	Skin Response Reason Not Done	An explanation of why the data are not available.	What was the reason the test was not done?	Reason Not Done	Char	O	Provide the reason why the test or examination was not done.	SRREASND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	The reason the data are not available may be chosen from a sponsor- defined list (e.g., broken equipment, subject refused) or entered as free text. When SRREASND is used, the SDTMIG variable SRSTAT should also be populated in the SDTM- based dataset.
Findings	SR	N/A	N/A	8	SRCAT	Skin Response Category for Test	A grouping of topic-variable values based on user-defined characteristics.	What was the category of the skin response?	[Skin Response Category]; NULL	Char	O	Record the skin response category, if not preprinted on the CRF.	SRCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Category" can be included as the column header.
Findings	SR	N/A	N/A	9	SRSCAT	Skin Response Subcategory for Test	A sub-division of the SRCAT values based on user-defined characteristics.	What was the subcategory of the skin response?	[Skin Response Subcategory]; NULL	Char	O	Record the skin response subcategory, if not preprinted on the CRF.	SRSCAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	Sponsor-defined controlled terminology. This would most commonly be either a heading, or a preprinted category value on the CRF and not a question to which the site would provide an answer. If a question is asked, the response would typically be a sponsor- defined codelist. If the form is laid out as a grid, then words such as "Subcategory" can be included as the column header. SRSCAT can only be used if there is an SRCAT and it must be a subcategorization of SRCAT.
Findings	SR	N/A	N/A	10	SRSPID	Skin Response Sponsor- Defined Identifier	A sponsor- defined identifier. In CDASH, This is typically used for preprinted or auto-generated numbers on the CRF, or any other type of identifier that does not already have a defined CDASH identifier field.	[Sponsor-defined question]	[Sponsor defined]	Char	O	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	SRSPID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. May be used to create RELREC to link this record with a record in another domain.	N/A	N/A	Because SPID is a sponsor-defined identifier, conformance to Question Text or Item Prompt is not applicable. Typically used as an identifier in a data query to communicate clearly to the site the specific record in question or to reconcile data. May be used to record preprinted number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Findings	SR	N/A	N/A	11	SROBJ	Skin Response Object of the Observation	A description of the object or focal point of the findings observation that is represented by SRTEST.	What intervention was performed to elicit the skin response?	[Intervention] Performed	Char	HR	Record the name of the antigen administered to the skin to elicit the skin response.	SROBJ	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	SR	N/A	N/A	12	SRRFTDAT	SR Date of Reference Time Point	The date of the reference time point, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the [intervention] performed to elicit the skin response?	[Intervention] Administration Date	Char	R/C	Record date of the test material administration using this format (DD-MON- YYYY).	SRRFTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable SRRFTDTC in ISO 8601 format.	N/A	N/A	A complete date is expected. If the date of administration is collected on a separate CRF (e.g., VISDAT), then it should not be collected on the SR CRF.
Findings	SR	N/A	N/A	13	SRRFTTIM	SR Time of Reference Time Point	The time of the reference time point, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the [intervention] performed to elicit the skin response?	[Intervention] Administration Time	Char	R/C	Record time of the test material administration using this format (hh:mm:ss).	SRRFTDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable SRRFTDTC in ISO 8601 format.	N/A	N/A	Collect time if it is relevant for the analysis of the skin response (e.g., multiple [intervention] administrations.)
Findings	SR	N/A	N/A	14	SRLOC	SR Location Used for Measurement	A description of the anatomical location of the subject relevant to the collection of skin response test.	What was the anatomical location of the skin response measurement?	Anatomical Location	Char	O	Record or select location on body where measurement was performed, if not preprinted on CRF.	SRLOC	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LOC)	N/A	Collected or preprinted when the sponsor needs to identify the specific anatomical location (e.g., ARM for skin response). Sponsors may collect the data using a subset list of controlled terminology on the CRF. LAT, DIR, and PORTOT are used to further describe the anatomical location.
Findings	SR	N/A	N/A	15	SRLAT	Skin Response Laterality	Qualifier for anatomical location further detailing the side of the body.	What was the side of the anatomical location of the skin response measurement?	Side	Char	O	Record the side of the anatomical location where the test was performed.	SRLAT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(LAT)	N/A	May be preprinted or collected when the sponsor needs to identify the specific side of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	SR	N/A	N/A	16	SRTEST	Skin Response Test or Examination Name	Descriptive name of the test or examination used to obtain the measurement or finding.	What was the skin response test name?	[Skin Response Test Name]	Char	HR	Record the name of the skin response test if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	SRTEST;SRTESTCD	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. SRTESTCD may be determined from the value collected in SRTEST. The SDTMIG variables SRTESTCD and SRTEST are required in the SDTM submission datasets. Use appropriate CDISC Controlled Terminology for the test and test code.	(SRTEST)	N/A	Required to identify which test the result is for. It is recommended that the test names be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Test" can be included as the column header.
Findings	SR	N/A	N/A	17	SRTPT	Skin Response Planned Time Point Name	A text description of planned time point when measurements should be taken as defined in the protocol.	What was the planned time point for skin response measurement?	[Planned Time Point Name]	Char	R/C	Record the planned time point labels for skin response, if not preprinted on the CRF.	SRTPT	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target. See SDTMIG for additional information on representing time points. Time point anchors SRTPTREF (text description) and SRRFTDTC (date/time) may be needed, as well as SDTMIG variables SRTPTNUM, SRELTM.	N/A	N/A	Planned time point are needed to differentiate multiple sequential assessments. It is recommended that time points should be preprinted on the CRF rather than collected in a field that requires the site to enter text. If the form is laid out as a grid, then words such as "Planned Time Point" can be included as the column header.
Findings	SR	N/A	N/A	18	SRDAT	Skin Response Observation Date	The date of the measurements, represented in an unambiguous date format (e.g., DD-MON- YYYY).	What was the date of the skin response measurement?	Date	Char	R/C	Record date of measurements using this format (DD-MON- YYYY).	SRDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable SRDTC in ISO 8601 format.	N/A	N/A	The date of measurement can be determined from a collected date of the visit (VISDAT) and in such cases a separate measurement date field is not required.
Findings	SR	N/A	N/A	19	SRTIM	Skin Response Observation Time	The time of measurement, represented in an unambiguous time format (e.g., hh:mm:ss).	What was the time of the skin response measurement?	Time	Char	R/C	Record time of measurement (as complete as possible).	SRDTC	This does not map directly to an SDTMIG variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTMIG variable SRDTC in ISO 8601 format.	N/A	N/A	The time of measurement (if required) can be determined from a collected time of the visit (VISTIM) and in such cases a separate measurement date field is not required.
Findings	SR	N/A	N/A	20	SRDIR	Skin Response Directionality	Qualifier further detailing the position of the anatomical location relative to the center of the body, organ, or specimen.	What was the directionality of the anatomical location of the skin response measurement?	Directionality	Char	O	Record the directionality of the anatomical location where the test was performed.	SRDIR	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(DIR)	N/A	May be preprinted or collected when the sponsor needs to identify the directionality of the anatomical location. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	SR	N/A	N/A	21	SREVAL	Skin Response Evaluator	The role of the person who provided the evaluation.	Who was the evaluator?	[Evaluator/Reporter]	Char	O	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	SREVAL	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(EVAL)	N/A	Used only for results that are subjective (e.g., assigned by a person or a group). May be a preprinted or collected. Sponsors may collect the data using a subset list of controlled terminology on the CRF.
Findings	SR	N/A	N/A	22	SREVALID	Skin Response Evaluator Identifier	Used to distinguish multiple evaluators with the same role recorded in SREVAL.	What was the identifier of the evaluator providing the skin response information?	[Evaluator/Reporter] Identifier	Char	O	Record the unique identifier assigned to the person making the evaluation.	SREVALID	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(MEDEVAL)	N/A	If EVALID needs to be collected for each test on the horizontal record the CDASH variable [SRTESTCD]_ EVALID can be used.
Findings	SR	N/A	N/A	23	SRORRES	SR Results or Findings in Original Units	Result of the skin response test as originally received or collected.	What was the result of the skin response measurement?	(Result)	Char	HR	Record the skin response test result.	SRORRES	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	N/A	N/A	N/A
Findings	SR	N/A	N/A	24	SRORRESU	SR Original Units	The unit of the result as originally received or collected.	What was the unit of the skin response measurement?	Unit	Char	R/C	Record or select the unit of measure associated with the test, if not preprinted on the CRF.	SRORRESU	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(UNIT)	N/A	Should be preprinted on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text.
Findings	SR	N/A	N/A	25	SRNRIND	Skin Response Reference Range Indicator	An indication or description about how the value compares to the normal range or reference range.	How [did/do] the reported values compare within the [reference/normal/expected] range?	Comparison to [Reference/Expected/Normal] Range	Char	O	Record where the test results were categorized within the respective reference range (e.g. HIGH, LOW, ABNORMAL).	SRNRIND	Maps directly to the SDTMIG variable listed in the column with the heading SDTMIG Target.	(NRIND)	N/A	The category of the value within the respective reference range. Ranges may be defined by SRORNRLO and SRORNRHI or other objective criteria. Reference Range Indicator may be included if not derived or determined programmatically after data collection. Should not be used to indicate clinical significance.
Findings	SR	N/A	N/A	26	SRCLSIG	Skin Response Clinical Significance	An indication whether the skin response result was clinically significant.	Was the result clinically significant?	Clinically Significant	Char	O	Record whether the skin response result was clinically significant.	SUPPSR.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPSR dataset as the value of SUPPSR.QVAL where SUPPSR.QNAM ="SRCLSIG" and SUPPSR.QLABEL="Clinically Significant". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A	If this level of information is needed, it may be added to the CRF.

Assumptions for the CDASHIG SR - Skin Response Domain

1. The SR domain is to be used when the skin response is the primary response that is being assessed (e.g., allergy test kits, tuberculosis skin test), rather than it being a secondary response to the actual injection.

2. The method of assessment is typically a skin-prick test.

Example CRFs for the CDASHIG SR - Skin Response Domain

Example 1

Title: Skin Test





CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTM Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
SRCAT	1	What was the category of the skin response?	Skin Response Category	Record the skin response category, if not pre-printed on the CRF.	Text	SRCAT				Sponsor Defined			Yes
SRPERF	2	Was a skin response test performed?	Skin Response Test Performed	Indicate if a skin response test as performed. If Yes, include the appropriate details where indicated on the CRF.	Text	SRSTAT		(NY)	Yes; No		prompt
SRREASND	3	What was the reason the test was not done?	Reason Not Done	Provide the reason why the test or examination was not done.	Text	SRREASND
SROBJ	4	What intervention was performed to elicit the skin response?	Intervention Performed	Record the name of the antigen administered to the skin to elicit the skin response.	Text	SROBJ				PURIFIED PROTEIN DERIVATIVE [PPD] INJECTION
SRRFTDAT	5	What was the date of the intervention performed to elicit the skin response?	Administration Date	Record date of the test material administration using this format (DD-MON-YYYY).	Date	SRRFTDTC					qtext
SRRFTTIM	6	What was the time of the intervention performed to elicit the skin response?	Administration Time	Record time of the test material administration using this format (hh:mm:ss).	Time	SRRFTDTC					qtext
SRDAT	7	What was the date of the skin response measurement?	Date	Record date of measurements using this format (DD- MON-YYYY).	Date	SRDTC					qtext
SRTIM	8	What was the time of the skin response measurement?	Time	Record time of measurement (as complete as possible).	Time	SRDTC					qtext
SRLOC	10	What was the anatomical location of the skin response measurement?	Anatomical Location	Record or select location on body where measurement was performed, if not preprinted on CRF.	Text	SRLOC		(LOC)	ARM; LEG		prompt
SRLAT	11	What was the side of the anatomical location of the skin response measurement?	Side	Record the side of the anatomical location where the test was performed.	Text	SRLAT		(LAT)	RIGHT; LEFT		prompt
SRDIR	12	What was the directionality of the anatomical location of the skin response measurement?	Directionality	Record the directionality of the anatomical location where the test was performed.	Text	SRDIR		(DIR)	UPPER; LOWER; ANTERIOR		prompt
SRTEST	13	What was the skin response test name?	Skin Response Test Name	Record the name of the skin response test if not preprinted on the CRF. If collected on the CRF, the sponsor may provide additional instructions to ensure the data is entered as intended.	Text	SRTEST		(SRTEST)	Flare Size; Flare Mean Diameter; Induration Longest Diameter; Wheal Size; Wheal Longest Diameter; Wheal Mean Diameter		prompt
SRORRES	14	What was the result of the skin response measurement?	Result	Record the skin response test result.	Float	SRORRES					prompt
SRORRESU	15	What was the unit of the skin response measurement?	Unit	Record or select the unit of measure associated with the test, if not preprinted on the CRF.	Text	SRORRESU		(UNIT)	mm; cm
SREVAL	16	Who was the evaluator?	Evaluator	Select the role of the person who provided the evaluation (e.g., INVESTIGATOR, ADJUDICATION COMMITTEE, VENDOR).	Text	SREVAL		(EVAL)	INVESTIGATOR; HEALTH CARE PROFESSIONAL; STUDY SUBJECT

Example 2

Title: Skin Response



CRF Metadata

Order	Question Text	Prompt	CRF Completion Instructions	Type	CDASH Variable	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology CodeList Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
2	Was a skin response test performed?	Skin Response Test Performed	Indicate if a skin response test as performed. If Yes, include the appropriate details where indicated on the CRF.	Text	SRPERF	SRSTAT		NY	Yes; No		prompt
3	What was the reason the test was not done?	Reason Not Done	Provide the reason why the test or examination was not done.	Text	SRREASND	SRREASND					prompt
4	What was the category of the skin response?	[Skin Response Category]; NULL	Record the skin response category, if not pre-printed on the CRF.	Text	SRCAT	SRCAT				Sponsor Defined			Yes
5	What is the skin response identifier?	[Line Number/SR Number]	If collected on the CRF, sponsor may insert instructions to ensure each record has a unique identifier.	Text	SRSPID	SRSPID
6	What intervention was performed to elicit the skin response?	Intervention Performed	Record the name of the antigen administered to the skin to elicit the skin response.	Text	SROBJ	SROBJ				PURIFIED PROTEIN DERIVATIVE [PPD] INJECTION
7	What was the date of the [intervention] performed to elicit the skin response?	Administration Date	Record date of the test material administration using this format (DD- MON-YYYY).	Date	SRRFTDAT	SRRFTDTC
8	What was the time of the [intervention] performed to elicit the skin response?	Administration Time	Record time of the test material administration using this format (hh:mm:ss).	Time	SRRFTTIM	SRRFTDTC
9	What was the anatomical location of the skin response measurement?	Anatomical Location	Record or select location on body where measurement was performed, if not pre-printed on CRF.	Text	SRLOC	SRLOC		LOC	ARM; SHOULDER; LEG		prompt
10	What was the side of the anatomical location of the skin response measurement?	Side	Record the side of the anatomical location where the test was performed.	Text	SRLAT	SRLAT		LAT	RIGHT; LEFT		prompt
11	What was the result of the flare size measurement?	Flare Size	Record the test result.	float	FLARESZ_SRORRES	SRORRES;SRTEST;SRTESTCD	SRORRES where SRTESTCD = "FLARESZ"				prompt
12	What was the unit of the flare size measurement?	Flare Size Unit	Record or select the original units in which these data were collected, if not pre-printed on CRF.	text	FLARESZ_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "FLARESZ"	Unit	cm; mm		prompt
13	What was the result of the flare longest diameter measurement?	Flare Longest Diameter	Record the test result.	float	FLRLDIAM_SRORRES	SRORRES; SRTEST; SRTESTCD	SRORRES where SRTESTCD = "FLRLDIAM"				prompt
14	What was the unit of the flare longest diameter measurement?	Flare Longest Diameter Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	text	FLRLDIM_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "FLRLDIAM"	Unit	cm; mm		prompt
15	What was the result of the flare mean diameter measurement?	Flare Mean Diameter	Record the test result.	float	FLRMDIAM_SRORRES	SRORRES; SRTEST;SRTESTCD	SRORRES where SRTESTCD = "FLRMDIAM"				prompt
16	What was the unit of the flare mean diameter measurement?	Flare Mean Diameter Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	text	FLRMDIM_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "FLRMDIAM"	Unit	cm; mm		prompt
17	What was the result of the induration longest diameter measurement?	Induration Longest Diameter	Record the test result.	float	IDRLDIAM_SRORRES	SRORRES;SRTEST; SRTESTCD	SRORRES where SRTESTCD = "IDRLDIAM"				prompt
18	What was the unit of the induration longest diameter measurement?	Induration Longest Diameter Unit	Record or select the original unit in which these data were collected, if not pre-printed on CRF.	text	IDRLDIAM_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "IDRLDIAM"	Unit	cm; mm		prompt
19	What was the result of the wheal size measurement?	Wheal Size	Record the test result.	float	WHEALSZ_SRORRES	SRORRES; SRTEST; SRTESTCD	SRORRES where SRTESTCD = "WHEALSZ"				prompt
10	What was the unit of the wheal size measurement?	Wheal Size Unit	Record or select the original units in which these data were collected, if not pre-printed on CRF.	text	WHEALSZ_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "WHEALSZ"	Unit	cm; mm		prompt
11	What was the result of the wheal longest diameter measurement?	Wheal Longest Diameter	Record the test result.	float	WHLLDIAM_SRORRES	SRORRES; SRTEST;SRTESTCD	SRORRES where SRTESTCD = "WHLLDIAM"				prompt
12	What was the unit for the wheal longest diameter measurement?	Wheal Longest Diameter Unit	Record or select the original units in which these data were collected, if not pre-printed on CRF.	text	WHLLDIM_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "WHLLDIAM"	Unit	cm; mm		prompt
13	What was the result of the wheal mean diameter measurement?	Wheal Mean Diameter	Record the test result.	float	WHLMDIAM_SRORRES	SRORRES;SRTEST;SRTESTCD	SRORRES where SRTESTCD = "WHLMDIAM"				prompt
14	What was the unit of the wheal mean diameter measurement?	Wheal Mean Diameter Unit	Record or select the original units in which these data were collected, if not pre-printed on CRF.	text	WHLMDIM_SRORRESU	SRORRESU	SRORRESU where SRTESTCD = "WHLMDIAM"	Unit	cm; mm		prompt

8.4 Associated Persons Domains

Description/Overview for the CDASHIG AP Domains

Data may be collected about persons other than the subject under study. Appropriate consent may be needed when collecting data about caregivers, study partners, organ donors, and so on. (Consent would not be needed to collect data about a subject's family medical history.) These persons could be associated with the study itself, a particular study subject, or a device used in the study. The term associated persons is used to classify data collected about persons who are not subject participants in a clinical study. An associated person (AP) may be a family member or may have a non-familial relationship to a study subject (e.g., the associated person might be a caregiver or an organ or blood donor). An AP may also be unrelated to any study subject, such as a study technician who is inadvertently exposed to a study-related substance and has to be followed for adverse events.

AP domains parallel general observation class domains as well as the Demographics (DM) and potentially the Comments (CO) domains. The structure of AP domains is therefore the same as those for study-subject domains, with the exception of variables that are only applicable to study subjects (e.g., the identifiers USUBJID and SPDEVID). Unless otherwise stated, all other general assumptions about CDASHIG variables and domains will apply to AP data.

Refer to the SDTMIG supplement for Associated Persons (SDTMIG-AP) for further details about representing data collected about people other than study subjects in SDTM.

8.4.1 Assumptions for the CDASHIG AP Domains

1. The DOMAIN for every CDASHIG AP domain has a 4-character code, beginning with "AP" and followed by the respective domain abbreviation; for example, APCM (Associated Persons Concomitant Medication), APDM (Associated Persons Demographics), APMH (Associated Persons Medical History).

2. Required Variables for SDTM

a. AP SDTM datasets must include the required topic variable for its associated class (e.g., --TRT for an Interventions class domain) plus the following required variables specific to AP domains: an Associated Person Identifier (APID) and a description of the associated person's relationship to one or more study subjects (SREL), if any. The CRF for the AP data may collect both APID and SREL, or just SREL. When only SREL is collected, the APID variable is populated when the SDTM datasets are created.

b. The AP domain variable RSUBJID (Identifier for the related study subject) may be collected on the CRF. However, because there is typically just 1 related study subject, RSUBJID is not required to be collected and may be populated in the SDTMIG dataset from the study subject's identifier.

c. AP domains should include the commonly used variables for their respective class.

3. Prohibited Variables for SDTM

a. The same variables that are listed as not being allowed for use within a given class are also prohibited from use in an AP domain for that class. For example, when creating an AP Interventions Class domain, --ORRES, --ORRESU, --PERF, and --TERM are prohibited.

b. Careful consideration should be given if/when creating AP CRFs with CDASHIG fields that may map to multiple SDTMIG classes.

4. Special Considerations

a. The AP domain name is created by adding the prefix "AP" to the CDASHIG domain letters associated with the data to be reported (e.g., "APMH" where "MH" is the parent CDASHIG domain of interest).

b. For non-supplemental qualifiers (i.e., parent domain variables) individual CDASHIG variable names use the same names as CDASHIG items in the parent domain (e.g., MHTERM, MHSTDAT) variable. They do not have the prefix "AP" appended.

c. For supplemental qualifier variables, individual CDASH items are mapped to an AP domain-specific supplemental qualifier variable. Supplemental Qualifier variables for AP domains begin with SQAP.QVAL. e.g., SQAPMH.QVAL where QNAM = MHNAM.

d. When any CRF includes the variables APID and/or SREL, the sponsor must ensure that the appropriate AP-- domain is used when the SDTM datasets are created. Sponsors may opt to include the CDASH variable "DOMAIN" which is prespecified to the applicable AP domain (e.g., APMH) to facilitate the creation of the SDTM datasets.

Specification for the CDASHIG AP Variables

Refer to the Identifier Variables at the end of the Domain Specific section of the CDASH Model for the CDASH attributes for variables APID, SREL, and RSUBJID.

Domain Specific

Observation Class	Domain	Order Number	CDASH Variable	CDASH Variable Label	DRAFT CDASH Definition	Question Text	Prompt	Data Type	SDTM Target	Mapping Instructions	Controlled Terminology Codelist Name	Implementation Notes
Domain Specific	AE	1	AEACNOYN	Any Other Actions Taken	An indication whether any other action(s) were taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatments given because of this adverse event.	Were any other actions taken in response to this adverse event?	Any Other Actions Taken	Char	N/A	Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the AEACNOTH field on the CRF was deliberately left blank.
Domain Specific	AE	2	AERLNSYN	Related to Non- Study Treatment	An indication whether in the investigator's opinion the event may have been due to a treatment other than study treatment.	[Is/Was] this adverse event due to treatment other than study treatment?	Related to Non-Study Treatment	Char	N/A	Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the CDASH AERELNST field on the CRF was deliberately left blank.
Domain Specific	AE	3	AESCAN	Involves Cancer	An indication the serious event was associated with the development of cancer.	[Is/Was] the adverse event associated with the development of cancer?	Cancer	Char	AESCAN	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	Although deprecated, this variable is included for illustrative purposes if the sponsor is continuing to collect legacy data. If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	4	AESCONG	Congenital Anomaly or Birth Defect	An indication the serious adverse event was associated with a congenital anomaly or birth defect.	[Is/Was] the adverse event associated with a congenital anomaly or birth defect?	Congenital Anomaly/Birth Defect	Char	AESCONG	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	5	AESDISAB	Persist or Signif Disability/Incapacity	An indication the serious adverse event was associated with a persistent or significant disability or incapacity.	Did the adverse event result in disability or permanent damage?	Disability or Permanent Damage	Char	AESDISAB	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. his information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	6	AESDTH	Results in Death	An indication the serious adverse event resulted in death.	Did the adverse event result in death?	Death	Char	AESDTH	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015). Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	7	AESHOSP	Requires or Prolongs Hospitalization	An indication the serious adverse event resulted in an initial or prolonged hospitalization.	Did the adverse event result in initial or prolonged hospitalization of the subject?	Hospitalization (Initial or Prolonged)	Char	AESHOSP	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	8	AESI	Adverse Event of Special Interest	An adverse event of special interest (serious or non-serious) is one of scientific and medical concern specific to the sponsor's product or program, for which ongoing monitoring and rapid communication by the investigator to the sponsor can be appropriate. Such an event might warrant further investigation in order to characterize and understand it. Depending on the nature of the event, rapid communication by the trial sponsor to other parties (e.g., regulators) might also be warranted.	[Is/Was] this event of special interest?	Adverse Event of Special Interest	Char	N/A	Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.	(NY)	This CDASH field may be used just to trigger other CRF pages, or populate a value in AECAT or AESCAT. If submitted, this information could be submitted in a SUPP- -.QVAL dataset where SUPP--.QNAM= "AESI" and SUPP--.QLABEL = "Adverse Event of Special Interest". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.
Domain Specific	AE	9	AESINTV	Needs Intervention to Prevent Impairment	An indication an adverse event required medical or surgical intervention to preclude permanent impairment of a body function, or prevent permanent damage to a body structure, due to the use of a medical product.	Did the adverse event require intervention to prevent permanent impairment or damage resulting from the use of a medical product?	Needs Intervention to Prevent Impairment	Char	SUPPAE.QVAL	This does not map directly to an SDTM variable. This information could be submitted in a SUPPAE dataset as the value of SUPPAE.QVAL where SUPPDS.QNAM = "AESINTV" and SUPPAE.QLABEL= "Needs Intervention to Prevent Impairment". Sponsors should see requirements for the reporting of adverse events involving medical devices.	(NY)	This criteria is used for serious adverse events associated with a medical product (e.g., device). SDTM does not contain a variable to report this criteria of seriousness. Sponsor could submit this in the SUPPAE dataset. Sponsors should see requirements for the reporting of adverse events involving medical devices to health authorities.
Domain Specific	AE	10	AESLIFE	Is Life Threatening	An indication the serious adverse event was life threatening.	[Is/Was] the adverse event life threatening?	Life Threatening	Char	AESLIFE	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	11	AESMIE	Other Medically Important Serious Event	An indication additional categories for seriousness apply.	[Is/Was] the adverse event a medically important event not covered by other "serious" criteria?	Other Serious (Important Medical Events)	Char	AESMIE	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable be defined for each Serious AE type. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	AE	12	AESOD	Occurred with Overdose	An indication the serious event occurred with an overdose.	Did the adverse event occur with an overdose?	Overdose	Char	AESOD	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(NY)	Although deprecated, this variable is included for illustrative purposes if the sponsor is continuing to collect legacy data. If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states "The entry of a "Y" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs".
Domain Specific	DM	1	RACEOTH	Race Other	A free-text field to be used when none of the pre-printed values for RACE are applicable or if another, unprinted selection should be added to those pre-printed values.	What was the other race?	Specify Other Race	Char	SUPPDM.QVAL	This does not map directly to an SDTMIG variable. This information could be submitted in a SUPPDM dataset as the value of SUPPDM.QVAL where SUPPDM.QNAM = "RACEOTH" and SUPP.QLABEL="RACE OTHER". See the SDTMIG Section 5-DM Domain. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	N/A	When creating the Demographics form, it is suggested that you include the five standard race categories. If you choose, you might include another value of Specify, other with a free text field for extending the list of values. The RACEOTH variable contains the free text added by the site. The value(s) added in the optional variable might or might not "collapse up" into one of the five categories specified by the FDA Guidance. See SDTMIG V3.2 for examples of reporting this implementation.
Domain Specific	DS	1	DSCONT	Subject Continue	The plan for subject continuation to the next phase of the study or another study at the time of completion of the CRF.	Will the subject continue?	Subject Continue	Char	SUPPDS.QVAL	This information could be submitted in a SUPPDS dataset as the value of SUPPDS.QVAL where SUPPDS.QNAM= "DSCONT" and SUPPDS.QLABEL="Subject Continue". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains.	(NY)	N/A
Domain Specific	DS	2	DSNEXT	Next EPOCH	Identifies the study epoch or new study in which the subject will participate.	What [is/was] the next [Period/Epoch/Trial] the subject will [continue to/enter/enroll]?	Next [Period/Epoch/Trial]	Char	N/A	This variable does not map to an SDTM variable. The CRF is annotated to indicate that this field is NOT SUBMITTED.	N/A	Typically this is used as General prompt question to aid in monitoring, data cleaning and subject tracking. This information could be submitted in a SUPP--.QVAL dataset where SUPP--.QNAM = "--DSNEXT" and SUPP-- .QLABEL = "Next EPOCH". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains.
Domain Specific	DS	3	DSUNBLND	Unblinded	An indication the subject's treatment information was revealed to any unauthorized site personnel during the trial.	[Is/Was] treatment (unblinded/unmasked) by the site?	Unblinded	Char	DSTERM	This does not map directly to an SDTM variable. If the CDASH field DSUNBLIND = "Y", then the SDTMIG variables DSDECOD and DSTERM = "TREATMENT UNBLINDED" and "DSCAT" = "OTHER EVENT". If DSUNBLIND = "N", then the CRF should be annotated to indicate that this value is NOT SUBMITTED.	(NY)	There may be multiple rows in the SDTM DS dataset to represent this information; each with the appropriate DSCAT values. One row could indicate the treatment was unblinded using DSCAT= "OTHER EVENT" and another row could indicate the status of the subject at the end of their participation in the trial using DSCAT = "DISPOSTION". If DSUNBLND is yes and information was collected about the reason for the unblinding, populate DSCAT with "OTHER EVENT" and the SDTMIG variables DSTERM with the free text and DSDECOD with the sponsor-defined standardized text (e.g., TREATMENT UNBLINDED). If DSUNBLND is yes, and the unblinding also resulted in the subject discontinuing the trial prematurely, populate DSCAT with "DISPOSTION" and use the SDTM IG variables DSTERM and DSDECOD to capture the applicable discontinuation details. If the unblinding occurred due to an Adverse Event, DSTERM contains the text of the Adverse Event, and in the AE domain the SDTMIG variable AEACNOTH ( "Were any other actions taken in response to this adverse event?" ) may include text of "Treatment Unblinded". DSUNBLND may also be used to document intentional unblinding at a protocol defined point in the trial.
Domain Specific	MH	1	MHEVDTYP	Medical History Event Date Type	Specifies the aspect of the medical condition or event by which MHSTDTC and/or the MHENDTC is defined.	What was the medical history event date type?	Medical History Event Date Type	Char	SUPPMH.QVAL	This field does not map directly to an SDTM variable. This information could be submitted in a SUPPMH dataset as the value of SUPPMH.QVAL when SUPPMH.QNAM = "MHEVDTYP" and SUPPMH.QLABEL= "Medical History Event Date Type".	N/A	It is not related to the trials condition. It cannot be a value of PRIMARY DIAGNOSIS or SECONDARY DIAGNOSIS. The event date type may the date of DIAGNOSIS, SYMPTOMS, RELAPSE, INFECTION.
Identifiers	AP--	1	APID	Associated Persons Identifier	The identifier for a single associated person.	What is the associated person's identifier?	Associated Persons Identifier	Char	APID	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	N/A	N/A
Identifiers	AP--	2	SREL	Subject, Device or Study Relationship	The relationship of the associated person to the study subject / participant.	What is the associated person's relationship to the (study) [subject/participant]?	Relationship to (Study) [Subject/Participant]	Char	SREL	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	(RELSUB)	N/A
Identifiers	AP--	3	RSUBJID	Related Subject	The identifier for the study subject / participant.	What [is/was] the related (study) [subject/participant] identifier?	Related [Subject/Participant] (Identifier)	Char	RSUBJID	Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".	N/A	This may be derived/populated from the study subject's identifier as recorded on the subject Demographics CRF.

Example CRFs for the CDASHIG AP Domains

Example

This example CRF represents a use case where the study subject is an infant and the biological mother and biological father are associated persons.

Title: Associated Persons Demographics



CRF Metadata

CDASH Variable	Order	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre- Populated Value	Query Display	List Style	Hidden
DOMAIN	1	Domain	Domain	N/A	Text	DOMAIN		(DOMAIN)		APDM			Yes
RSUBJID	1	What is the related study subject's identifier?	Related Subject Identifier	Record the identifier for the study subject/participant. This may be derived/populated from the study subject's identifier as recorded on the subject Demographics CRF.	Text	RSUBJID							Yes
SREL	1	What is the associated person's relationship to the subject?	Relationship to Subject	Record the relationship of the associated person to the study subject.	Text	SREL		RELSUB	Mother, Biological; Father, Biological
APID	2	What is the associated persons identifier?	Associated Persons Identifier	Record the identifier for a single associated person.	Text	APID					Prompt
BRTHDAT	3	What is the subject's date of birth?	Birth Date	Record the date of birth to the level of precision known (e.g., day/month/year, year, month/year) in this format (DD-MON-YYYY).	Date	BRTHDTC					Prompt
SEX	4	What is the sex of the subject?	Sex	Record the appropriate sex.	Text	SEX		(SEX)	Male; Female		Prompt	radio
ETHNIC	5	Do you consider yourself Hispanic/Latino or not Hispanic/Latino?	Ethnicity	Study participants should self-report ethnicity, with ethnicity being asked about before race.	Text	ETHNIC		(ETHNIC)	Hispanic or Latino; Not Hispanic or Latino; Not Reported			radio
RACE	6	Which of the following five racial designations best describes you? (More than one choice is acceptable.)	Race	Study participants should self-report race, with race being asked about after ethnicity.	Text	RACE		(RACE)	American Indian or Alaska Native; Asian; Black or African American; Native Hawaiian or Other Pacific Islander; White			check

Example 2

This example CRF represents a use case where the study subject is an infant and the biological mother is an associated person and data about her medications during breastfeeding are being collected.

Title: Concomitant Medications During Breastfeeding



CRF Metadata

CDASH Variable	Order Number	Question Text	Prompt	CRF Completion Instructions	Type	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology Code List Name	Permissible Values	Pre-Populated Value	Query Display	List Style	Hidden
DOMAIN	0	Domain	Domain	N/A	Text	DOMAIN		(DOMAIN)		APCM			Yes
CMCAT	1	What is the category for the concomitant medication?	Concomitant Medication Category	Record the concomitant medication category, if not pre-printed on the CRF.	text	CMCAT				MEDICATION DURING BREASTFEEDING			Yes
SREL	2	What is the associated person's relationship to the subject?	Relationship to Subject	Record the relationship of the associated person to the study subject.	Text	SREL		(RELSUB)		MOTHER, BIOLOGICAL			Yes
RSUBJID	3	What is the related study subject's identifier?	Related Subject Identifier	Record the identifier for the study subject/participant. This may be derived/populated from the study subject's identifier as recorded on the subject Demographics CRF.	Text	RSUBJID							Yes
APID	4	What is the associated persons identifier?	Associated Persons Identifier	Record the associated persons identifier for the mother, using the same value as noted on the Associated Persons Demographics CRF.	Text	APID					prompt
CMYN	5	Were any concomitant medication(s) taken while breastfeeding?	Any Concomitant Medication(s)	Indicate if any concomitant medications were taken. If Yes, include the appropriate details where indicated on the CRF.	text			(NY)	Yes; No		prompt	Radio
CMTRT	6	What was the concomitant medication name?	Concomitant Medication	Record only 1 medication per line. Provide the full trade or proprietary name of the medication; otherwise, the generic name may be recorded.	text	CMTRT
CMSCAT	7	What is the subcategory for the concomitant medication?	Concomitant Medication Subcategory	Record the concomitant medication subcategory.	text	CMSCAT			ANTIRETROVIRAL; GENERAL
CMDOSE	8	What was the individual dose of the concomitant medication per administration?	Dose per administration	Record the dose of concomitant medication taken per administration (e.g., 200).	text	CMDOSE
CMDOSU	9	What is the unit?	(Dose) Unit	Record the dose unit of the dose of concomitant medication taken (e.g., mg).	text	CMDOSU		(UNIT)
CMDOSFRQ	10	What was the frequency of the concomitant medication?	Frequency	Record how often the concomitant medication was taken (e.g., BID, PRN).	text	CMDOSFRQ		(FREQ)
CMROUTE	11	What was the route of administration of the concomitant medication?	Route	Provide the route of administration for the concomitant medication.	text	CMROUTE		(ROUTE)
CMSTDAT	12	What was the concomitant medication start date?	Start Date	Record the date the concomitant medication was first taken, using this format: DD- MON-YYYY. If the subject has been taking the concomitant medication for a considerable amount of time prior to the start of the study, it is acceptable to have an incomplete date. Any concomitant medication taken during the study is expected to have a complete start date. Any prior concomitant medication that is exclusionary should have both a start and end date.	text	CMSTDTC
CMONGO	13	Was the concomitant medication ongoing?	Concomitant Meds Ongoing	Record the concomitant medication/treatment as ongoing if the subject has not text stopped taking the concomitant medication/treatment at the time of data collection and the end date should be left blank.	text	CMENRF; CMENRTPT	CMENRF/CMENRTPT	(NY)	Yes			Checkbox
CMENDAT	14	What was the concomitant medication end date?	End Date	Record the date the concomitant medication was stopped, using this format: DD- text MON-YYYY. If the subject has not stopped taking the concomitant medication, leave this field blank.	text	CMENDTC

Example 3

This example CRF represents a use case where the study subject is a child and the biological parents are associated persons.

Title: Associated Persons STI Medical History and Risk Factors



CRF Metadata

CDASH Variable	Order Number	Question Text	Prompt	Type	CRF Completion Instructions	SDTMIG Target Variable	SDTMIG Target Mapping	Controlled Terminology CodeList Name	Permissible Values	Pre- Populated Value	Displayed Query	List	Hidden
DOMAIN	0	Domain	Domain	text	N/A	DOMAIN		(DOMAIN)		APMH			Yes
MHCAT	1	What was the category of the medical history?	Medical History Category	text	Indicate the category of the medical history event or condition.	MHCAT				RISK FACTORS			Y
MHSCAT	2	What was the subcategory of the medical history?	Medical History Subcategory	text	Indicate the subcategory of the medical history event or condition.	MHSCAT				HISTORY OF STI			Y
RSUBJID	3	What is the related study subject's identifier?	Related Subject Identifier	text	Record the identifier for the study subject/participant. This may be derived/populated from the study subject's identifier as recorded on the subject Demographics CRF.	RSUBJID							Y
SREL	4	What is the associated person's relationship to the subject?	Relationship to Subject	text	Record the relationship of the associated person to the study subject.	SREL		RELSUB	Mother, Biological; Father, Biological
APID	5	What is the associated person's identifier?	Associated Persons Identifier	text	Record the identifier for the associated person using the same value as noted on the Associated Persons Demographics CRF.	APID
HIV_MHTERM	6	N/A	Medical History Term	text	N/A	MHTERM				HIV			Y
HIV_MHOCCUR	7	Has the associated person been diagnosed with HIV?	HIV Occurrence	text	Indicate if the associated person has ever been diagnosed with HIV.	MHOCCUR	MHOCCUR where MHTERM = "HIV"	(NY)	Yes;No			Radio Buttons
HIV_MHSTDAT	8	What was the medical condition or event diagnosis date?	Diagnosis Date	text	Record the diagnosis date of the medical event or condition.	MHSTDTC		N/A			Prompt
HIV_DIAG_MHEVDTYP	9	What was the medical history event date type?	Medical History Event Date Type	text	The instructions depend upon the format of the CRF. Sponsors may pre-print these values on the CRF or use them as defaulted or hidden text.	SQAPMH.QVAL	SQAPMH.QVAL where SQAPMH.QNAM = "MHEVDTYP" and SQAPMH.QLABEL = "Medical History Event Date Type"			DIAGNOSIS			Y
GONORRHEA_MHTERM	10	N/A	Medical History Term	text	N/A	MHTERM				GONORRHEA			Y
GONORRHEA_MHOCCUR	11	Has the associated person ever had gonorrhea?	Medical History Term	text	Indicate if the associated person has ever been diagnosed with gonorrhea.	MHOCCUR	MHOCCUR where MHTERM = "GONORRHEA"	(NY)	Yes;No			Radio Buttons
GONORRHEA_MHSTDAT	12	What was the medical condition or event start date?	Start Date	text	Record the start date of the medical event or condition.	MHSTDTC
GONORRHEA_MHONGO	13	Is the event ongoing at the time of collection of this history?	Ongoing	text	Indicate if the condition is ongoing at the time the MHENRF history is collected.	MHENRF	MHENRTPT where MHENTPT = Date of Collection	(NY)	Yes			checkbox
GONORRHEA_MHENDAT	14	What was the medical condition or event end date?	End Date	text	Record the end date of the medical event or condition.	MHENDTC
CHLAMYDIA_MHTERM	15	N/A	Medical History Term	text	N/A	MHTERM				CHLAMYDIA			Y
CHLAMYDIA_MHOCCUR	16	Has the associated person ever had chlamydia?	Medical History Term	text	Indicate if the associated person has ever been diagnosed with chlamydia.	MHOCCUR	MHOCCUR where MHTERM = "CHLAMYDIA"	(NY)	Yes;No			Radio Buttons
CHLAMYDIA_MHSTDAT	17	What was the medical condition or event start date?	Start Date	text	Record the start date of the medical event or condition.	MHSTDTC
CHLAMYDIA_MHONGO	18	Is the event ongoing at the time of collection of this history?	Ongoing	text	Indicate if the condition is ongoing.	MHENRTPT	MHENRTPT where MHENTPT = Date of Collection	(NY)	Yes;			checkbox
CHLAMYDIA_MHENDAT	19	What was the medical condition or event end date?	End Date	text	Record the end date of the medical event or condition.	MHENDTC

9 Appendices

Appendix A: CDASH Model and CDASHIG Team Contributors

The following table lists volunteers who actively contributed to the development of the CDASH Model 1.1 and CDASHIG 2.1:

Name	Institution/Organization
Melissa Binz	Pfizer
Jorge Torres Borrero	Lung Biotechnology PBC
Tammy Burns	EMD Serono
Robert Butler	Gilead Sciences
Dan Crawford	Veeva
Carolyn Famatiga-Fay	CFSQUARED Solutions, LLC
Nikki Flores	Gilead Sciences
Erica Gonzales	PRA Health Sciences
Kit Howard	CDISC
Dawn Kaminski	eClinical Solutions
Natalia Khelmer	Johnson & Johnson
Joanna Kuzmicz	AstraZeneca
Shannon Labout	Data Science Solutions LLC
Kathleen Mellars	CDISC
Valerie Paxton	Synteract
Deborah Rittenhouse	CSL Behring
Jerry Salyers	Data Standards Consulting
Tisanna J. Shelton	Eli Lilly & Company
Sheetal Sheth	KCT Data Inc.
Benjamin C. Shim	Eli Lilly & Company
Lauren Shinaberry	Abbvie Inc.
Trisha Simpson	UCB
Lorraine P. Spencer, Co-chair	Abbvie
Alana St. Clair	CDISC
Judy Tran	Merck
Kim Truett	KCT Data Inc.
Gary Walker	Gary G Walker, LLC
Guang-Liang Wang	Otsuka
Michael J. Ward, Co-chair	Eli Lilly & Company

Appendix B: Glossary and Abbreviations

The following abbreviations and terms are used in this document. Additional definitions can be found in the CDISC Glossary (available at https://www.cdisc.org/standards/semantics/glossary).

ADaM	Analysis Data Model
AE	Adverse event; also refers to the Adverse Events domain.
ATC code	Anatomic Therapeutic Chemical code (from WHODrug)
CDASH	Clinical Data Acquisition Standards Harmonization Project; the name for the project that delivers basic data collection fields.
CDASHIG	Clinical Data Acquisition Standards Harmonization Implementation Guide for Human Clinical Trials; the associated implementation guide intended to be paired with CDASH Model.
CDISC	Clinical Data Interchange Standards Consortium
CDM	Clinical data management
Clinical database	A repository of the study results data collected in a clinical trial. The format and structure of this repository may vary across sponsors and vendors.
Collected	Within this document, collected refers to information that is recorded and/or transmitted to the sponsor. This includes data entered by the site on CRFs/eCRFs as well as vendor data such as core lab data. This term is a synonym for captured.
CRF	Case report form (sometime case record form); a printed, optical, or electronic document designed to record all required information to be reported to the sponsor for each trial subject.
CTCAE	Common Terminology Criteria for Adverse Events Dictionary
Databased	To put (data) into a database.
Dataset	A collection of structured data in a single file.
Denormalized	The organization of data such that multiple observations (results) are presented in a single row of data. For example, the result values for PULSE, HEIGHT, WEIGHT would be presented in the same row of data with PULSE, HEIGHT, and WEIGHT as column headers. This is also called a horizontal data structure.
Derived	Within this document, derived refers to information that is not directly entered into the specific data field by the investigator site or by a core lab. This category includes auto-encoded data, calculated data, and similar electronically generated data, but not pre-populated fields.
Domain	A domain is a collection of data points related by a common topic, such as adverse events or demographics.
eCOA	Electronic clinical outcome assessment
eCRF	Electronic case report form
ECG	Electrocardiogram
EDC	Electronic data capture
EHR	Electronic healthcare record
Epoch	Interval of time in the planned conduct of a study. An epoch is associated with a purpose (e.g., screening, randomization, treatment, follow-up), which applies across all arms of a study.
FDA	Food and Drug Administration; part of the US Department of Health and Human Services. The FDA is the regulatory authority for all pharmaceuticals (including biologics and vaccines) and medical devices in the US.
GCDMP	Good Clinical Data Management Practices (GCDMP); SCDM publication on CDM processes
HL7	Health Level 7; standards for the exchange, integration, sharing, and retrieval of electronic health information
ICD9	International Classification of Diseases, Ninth Revision
ICH	International Conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use
ICH E2A	ICH guidelines on Clinical Safety Data Management: Definitions and Standards for Expedited Reporting
ICH E2B	ICH guidelines on Clinical Safety Data Management: Data Elements For Transmission Of Individual Case Safety Reports
ICH E2C	ICH guidelines on Clinical Safety Data Management: Periodic Safety Update Reports For Marketed Drugs
ICH E3	ICH guidelines on Structure and Content of Clinical Study Reports
ICH E4	ICH guidelines on Dose-response Information to Support Drug Registration
ICH E5	ICH guidelines on Ethnic Factors in the Acceptability of Foreign Clinical Data
ICH E6 (R1)	ICH guideline for Good Clinical Practice
ICH E9	ICH guidelines on Statistical Principles for Clinical Trials
ICH E11	ICH guidelines on Clinical Investigation of Medicinal Products in the Pediatric Population
ICH E14	ICH guidelines on the Clinical Evaluation Of QT/QTc Interval
ISO 8601	International Organization for Standardization document of character representation of dates, date/times, intervals, and durations of time
MedDRA	Medical Dictionary for Regulatory Activities; global standard medical terminology designed to supersede other terminologies (e.g., COSTART, ICD9) used in the medical product development process.
MHLW	Japanese Ministry of Health, Labor and Welfare
MRI	Magnetic resonance imaging
N/A	Not applicable
NCI	National Cancer Institute (NIH)
NCI EVS	National Cancer Institute (NIH) Enterprise Vocabulary Services
NIH	National Institutes of Health
Normalized	The organization of data such that only 1 observation (result) is presented per row. For example, PULSE, HEIGHT, WEIGHT would be presented as values in individual rows (with the column header VSTESTCD) with each result presented in another column (same row) called VSORRES. This is also called a vertical data structure.
PK	Pharmacokinetics; the study of the absorption, distribution, metabolism, and excretion of a drug.
Preprinted (pre-printed)	Items that are part of the original printing on a paper CRF. For example, the unit required for a response, such as “years” for an age question. These data may or may not be stored in the database.
Prepopulated (pre-populated)	Items that are part of the eCRF (or data collection device) that are not entered and cannot be modified. (Also see Preprinted). These data are stored in the study database.
PRO	Patient-reported outcome
Protocol deviation	A variation from processes or procedures defined in a protocol. Deviations usually do not preclude the overall evaluability of subject data for either efficacy or safety, and are often acknowledged and accepted in advance by the sponsor. Good clinical practice recommends that deviations be summarized by site and by category as part of the report of study results so that the possible importance of the deviations to the findings of the study can be assessed (cf Protocol violation; see also ICH E3).
Protocol violation	A significant departure from processes or procedures that were required by the protocol. Violations often result in data that are not deemed evaluable for a per-protocol analysis, and may require that the subject(s) who violate the protocol be discontinued from the study (cf. Protocol deviation).
SAP	Statistical analysis plan
SCDM	Society for Clinical Data Management
SDTM	Study Data Tabulation Model
SDTMIG	Study Data Tabulation Model Implementation Guide
SME	Subject matter expert
SNOMED	Systematically organized computer processable collection of medical terms providing codes, terms, synonyms, and definitions used in clinical documentation and reporting.
SOCs	System Organ Classes (from MedDRA)
SOP	Standard Operating Procedure
Study Treatment	The drug, device, therapy, or process under investigation in a clinical trial which has an effect on outcome of interest in a study (e.g., health-related quality of life, efficacy, safety, pharmacoeconomics; synonyms: intervention, therapeutic intervention, medical product)
TAUG	Therapeutic area user guide
Uncoded	Not coded; not having or showing a code.
Variable naming fragment	A reusable pattern of characters in variable names that convey an equivalent meaning when applied to multiple variable names across classes and domains.
WHO	World Health Organization
WHO ART	World Health Organization Adverse Reaction Terminology has been developed over more than 30 years to serve as a basis for rational coding of adverse reaction terms.
WHODrug (WHO-DD)	World Health Organization Drug Dictionary

Appendix C: Revision History - Changes from CDASHIG v2.0 to CDASHIG v2.1

The release of the CDASHIG v2.1 and CDASH Model v1.1 entail changes from and supersedes prior versions of the CDASHIG v2.0 and CDASH Model v1.0, respectively. The most significant changes include:

• Inclusion of remaining SDTMIG v3.2 domains that were not published in CDASHIG v2.0 (i.e., MB, MS, TU, TR, RS, AP--)

• Conversion of all CRF examples to metadata table-defined aCRFs using the CRF Maker Tool

• Resolution of Jira issues submitted for enhancements and error corrections identified in CDASHIG v2.0 and CDASH Model v1.0

• Changed CDASHIG and CDASH Model Variable Labels, where needed, to more closely align with SDTMIG and SDTM Variable Labels, respectively

• Resolution of Jira issues submitted during Public Review

Appendix D: Representations 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

"CDISC grants open public use of this User Guide (or Final Standards) under CDISC's copyright."

Each Participant in the development of this standard 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 of the CDISC Intellectual Property Policy ("the Policy")); or (iii) distributed at no charge, except as set forth in Sections 3, 5.1, and 4.2 of the Policy. 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 OF THE CDISC INTELLECTUAL PROPERTY POLICY, 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.

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: https://www.cdisc.org/system/files/all/article/application/pdf/cdisc_policy_003_intellectual_property_v201408.pdf.