CDASH 2.1

Clinical Data Acquisition Standards Harmonization Model

Version 1.1 (Final)

Prepared by the CDISC CDASH Team

Notes to Readers

  • This is Version 1.1 of the Clinical Data Acquisition Standards Harmonization Model.

Revision History

DateVersion
2019-11-011.1 Final
2017-09-201.0 Final

See Appendix A for Representations and Warranties, Limitations of Liability, and Disclaimers.

1 Introduction

The Clinical Data Acquisition Standards Harmonization (CDASH) Model describes the foundational structure for the organization, naming, and description of variables and associated attributes to support data collection in clinical trials. The CDASH Model provides naming conventions for the CDASH Implementation Guide (CDASHIG) variables along with additional metadata to help facilitate mapping collected data to their respective SDTM Implementation Guide (SDTMIG) variables.

The CDASH Model aligns with and is structured similarly to the SDTM Model. The CDASH Model organizes data into classes, which represent meaningful groupings of data in clinical research. It defines CDASH metadata for identifier variables, timing variables, general observation class variables (Events, Interventions, and Findings), domain-specific variables, and special-purpose domain variables, (e.g., Demographics, Comments).

Sponsors may implement any CDASH variable found in a specific data class in the CDASH Model into any CDASHIG domain within that class. For example, the Interventions class variable --ROUTE, although not defined in the Substance Use (SU) domain, may be added to SU if needed because it exists in the Interventions general observation class, of which SU is a member. The domain-specific section of the CDASH Model defines variables that may not be reused across multiple Domains for a given Class.

Similar to the SDTM Model and SDTMIG, not all CDASH Model variables are replicated in each CDASHIG domain. Commonly used CDASH Model variables are included within their respective CDASHIG Domains.

Attributes defined for each Model variable are: Class, Name, Label, Question Text, Prompt, Data Type, SDTM Target, SDTM Mapping Instructions, Definition, Controlled Terminology Codelist Name, and Implementation Notes.

Reference the CDASHIG for more information about using this Model to implement each of the domain classes (including Findings About) and creating custom domains.

2 The CDASH Model

2.1 Interventions

Observation Class Domain Order NumberCDASH Variable CDASH Variable LabelDRAFT CDASH Definition Question TextPrompt Data TypeSDTM Target Mapping Instructions Controlled Terminology Codelist NameImplementation Notes
Interventions N/A 1 --YN Any [Intervention] An indication whether or not any data was collected for the intervention topic. Has the subject had any [intervention topic(s)] (after/before) [study-specific time frame] (after/before [study-specific time frame] )?; [Was/Were] (there) any [intervention topic(s)] [taken/performed/used/collected] (after/before) [study-specific time frame]? Any [Intervention Topic] 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) 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 N/A 2 --TRT Name of Treatment The topic for the intervention observation, usually the reported name of the treatment, drug, medicine, or therapy given during the dosing interval for the observation. What [is/was] the (type of) [treatment/investigational product/ intervention topic]?; [If other is selected], [explain/specify/provide more details] [Treatment/Investigational Product/Intervention Name]; [Specify Other/Explain/Specify Details] [Treatment/Investigational Product/Intervention Name] Char --TRT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A If --TRT is preprinted/pre-specified, the value should also be mapped into the --TRT variable. E.g., if Oral Steroid is preprinted on a CM CRF, "Oral Steroid" should be stored in CMTRT. The CDASH field --TRT can also be used to collect any free text values linked to the sponsor standardized value collected in the CDASH field --DECOD. For example, the CDASH field --DECOD may have a value of "OTHER" and the associated free text intervention topic is collected in the CDASH field -- TRT. In this scenario, the Item prompt "Specify Other" may be used.
IInterventions N/A 3 --DECOD Standardized Treatment Name The dictionary or sponsor-defined standardized text description of the topic variable, --TRT, or the modified topic variable (-- MODIFY), if applicable. What [is/ was] the [treatment/intervention topic]? [Intervention Topic] Char --DECOD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A When populated by a coding dictionary (e.g., WHO Drug or MedDRA), Question Text and Prompt are not applicable. WHO Drug may be used for coding treatment names and MedDRA may be used for coding procedures. When these dictionaries are used, --DECOD is equivalent to those dictionaries' Preferred Term. The CDASH field --DECOD may be used to collect standardized pre- specified values (CDISC Controlled Terminology or sponsor-defined) on a CRF. The CDASH field --TRT can be used to collect any free text values linked to the sponsor standardized value. For example, the CDASH field --DECOD may have a value of "OTHER" and the associated free text intervention topic is collected in CDASH field --TRT.
Interventions N/A 4 --MOOD Mood The mode or condition of the record that specifies whether the intervention (activity) is intended to happen or has happened. Does this record describe scheduled treatment or performed treatment? [Scheduled/Performed] Char --MOOD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (BRDGMOOD) "SCHEDULED" is used when collecting subject-level intended dose records. "PERFORMED" is used when collecting subject-level actual dose records. This would most commonly be a heading on the CRF and not a question to which the site would provide an answer. If collecting both the scheduled and performed dosing in the same horizontal record, the sponsor may append "_SCHEDULED" to the variable name to capture the scheduled dose.
Interventions N/A 5 --CAT Category A grouping of topic-variable values based on user-defined characteristics. What [is/was] the category (of the [intervention])? [Category/Category Value]; NULL Char --CAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. -- SCAT can only be used if there is a -- CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG. 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 are provided in the CDASHIG Metadata Table or in the SDTMIG.
Interventions N/A 6 --SCAT Subcategory A sub-division of the --CAT values based on user-defined characteristics. What [is/was] the subcategory (of the [intervention])? [Subcategory/Subcategory Value]; NULL Char --SCAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. -- SCAT can only be used if there is a -- CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG. 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. --SCAT can only be used if there is a --CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG.
Interventions N/A 7 --PRESP Pre-Specified Intervention An indication that a specific intervention or a group of interventions is pre-specified on a CRF . N/A N/A Char --PRESP Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) For pre-specified interventions, a hidden field on a CRF defaulted to Y, or added during the SDTM dataset creation. If a study collects both pre- specified interventions as well as free-text interventions, the value of -- PRESP should be Y for all pre- specified interventions and null for interventions reported as free-text.
Interventions N/A 8 --OCCUR Occurrence An indication that the pre-specified intervention happened or was administered when information about the occurrence of the specific intervention is solicited. Was [--TRT/ intervention] [taken/performed/administered/consumed] (after/before [study-specific time frame])?;Has the subject [had/taken/performed/administered/consumed] the [--TRT/ intervention]? [--TRT/ Intervention] [Had/Taken/Performed/Administered/Consum ed] Char --OCCUR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) Used for specific interventions that are collected as defined by the protocol. If the term is preprinted/pre- specified, the value should also be mapped into the --TRT variable. E.g., if Oral Steroid is preprinted on a CM CRF, "Oral Steroid" should be stored in CMTRT. The CDASH field -- OCCUR is not used for spontaneously free text reported -- TRT. Should not be used to indicate data was not collected. Used only when the value can be collected using values from the CDISC CT (NY) codelist. --OCCUR is a Yes/No variable and in the SDTM submission datasets, --OCCUR is populated when --PRESP is "Y" and --OCCUR is null when --PRESP is null.
Interventions N/A 9 --PERF [Observation] Performed The variable used to indicate whether data are available by having the site recording the value as "Yes" or "No". (Were/Was) (the) [intervention topic] [answered/done/assessed/evaluated/available]? ([intervention topic]) [Answered/Done/Assessed/Evaluated/Availab le] Char --STAT (NY) Using --PERF, a negative response can be collected as "N" and mapped to the --STAT variable in SDTM as "NOT DONE". --PERF can be used instead of -- STAT when a YN response list is needed for implementation. Examples: Were prior medications assessed? Were medications of interest assessed?
Interventions N/A 10 --STAT Completion Status The variable used to indicate that data are not available by having the site recording the value as "Not Done". Was the [intervention topic] not [answered/done/assessed/evaluated/available]?; Indicate if ([intervention topic] was) not [answered/done/assessed/evaluated/available]. Not [Answered/Done/Assessed/Evaluated/Availab le] Char --STAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". If collected, the Origin (column in the Define-XML) = "CRF", if populated from other sources such as a free text or sponsor-defined listing for --REASND, the Origin ="DERIVED". (ND) The value of "Not Done" indicates the data are not available or the question was not asked. Do not use this CDASH field when information on whether or not a pre-specified intervention was performed is collected as this should be collected using the CDASH field --OCCUR.
Interventions N/A 11 -- REASND Reason Not Done An explanation of why the data are not available. What [is/was] the reason that the [Interventions topic/data/information/sponsor-defined phrase] was not [collected/answered/done/assessed/evaluated/available]? Reason Not [Collected/Answered/Done/Assessed/Evaluat ed/Available] Char --REASND Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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 dataset.
Interventions N/A 12 --INDC Indication The condition, disease, symptom or disorder that the intervention was used to address or investigate (e.g., why the therapy was taken or administered or the procedure performed). For what indication was the [--TRT] [taken/performed/administered/consumed]? Indication Char --INDC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This additional information is collected on the CRF when the sponsor wants to capture the indication(s)/medical problem(s) why a subject took/had an intervention. This information can then be used as deemed appropriate for coding, analysis, or for reconciling the interventions as part of the data clean-up and monitoring process, etc.
Interventions N/A 13 --DOSE Dose The amount of substance (e.g., -- TRT) given at one time represented as a numeric value. What [is/ was] the (individual) (intended) [dose/amount] (of [-- TRT] [taken/performed/administered/consumed/per administration])? (Intended) [Dose/Amount] (per Administration) Num --DOSE Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Used when the dose/amount taken/administered/consumed has only numeric entries. If non-numeric entries are possible, use the CDASH field --DSTXT.
Interventions N/A 14 --DSTXT Dose Description The amount of substance ( e.g., -- TRT) given at one time represented in text format. What [is/was] the (individual) (intended) [dose/amount] (of [-- TRT] [taken/performed/administered/consumed/per administration])? (Intended) [Dose/Amount] (per Administration) Char --DOSE; -- DOSTXT Does not directly map to SDTM.. Maps to either -- DOSE or DOSTXT. N/A Defining this data collection field as a dose text field allows for flexibility in capturing dose entries as numbers, text or ranges.
Interventions N/A 15 --DOSU Dose Units The unit for --DOSE, --DOSTOT, or - -DOSTXT. What [is/was] the unit (for the dose/amount of [--TRT])? ([Dose/Amount]) Unit Char --DOSU Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (UNIT) When possible, is pre-printed on the CRF with the associated treatment. Dose unit may be derived via other methods (e.g., derived from protocol, data). When collected, the unit is pre- printed on the CRF or a field provided on the CRF to capture it.
Interventions N/A 16 -- DOSFRM Dose Form The form in which the --TRT is physically presented. What [is/was] the dose form (of the [--TRT])? Dose Form Char --DOSFRM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (FRM) N/A
Interventions N/A 17 -- DOSFRQ Dosing Frequency per Interval The number of doses given/administered/taken during a specific interval. What [is/was] the frequency (of the [--TRT])? Frequency Char --DOSFRQ Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (FREQ) 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., --DOSE ,--DOSEU,--DOSFRQ) for specific and consistent data collection and to enable programmatically utilizing these data.
Interventions N/A 18 -- DOSTOT Total Daily Dose The total amount of --TRT taken over a day using the units in -- DOSU. What [is/was] the total [dose/amount] (of the [-- TRT/Intervention] [taken/performed/administered/consumed])? Total Daily [Dose/Amount] Num --DOSTOT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Used when dosing is collected as Total Daily Dose.
Interventions N/A 19 -- DOSRGM Intended Dose Regimen The text description of the intended dosing schedule for the administration of the Intervention. What [is/was] the intended dose regimen (of the [--TRT])? Intended Dose Regimen Char --DOSRGM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A When possible, the options for intended dose regimen are pre- printed on the CRF. The sponsor may wish to create a codelist to collect this data consistently. Example: TWO WEEKS ON, TWO WEEKS OFF.
Interventions N/A 20 --ROUTE Route of Administration The route of administration of the intervention. What [is/was] the route of administration (of the [--TRT])? Route Char --ROUTE Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (ROUTE) N/A
Interventions N/A 21 --LOT Lot Number Lot number of the intervention product. What [is/was] the lot number (of the [--TRT])? Lot Number Char --LOT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The Lot Number identifies the manufacturing batch of the interventional product. In open label studies, the reference number on the product container may represent an actual Lot Number and should be submitted using --LOT. This variable may be populated during the process of creating the SDTM submission datasets. Do not collect other identification variables in this field.
Interventions N/A 22 --LOC Location of Dose Administration The anatomical location of an intervention, such as an injection site. What [is/was] the anatomical location (of the administration/where the [intervention] was taken/performed)? Anatomical Location Char --LOC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LOC) This may be pre-printed or collected. --LOC is used only to specify the anatomical location. --LAT, --DIR, -- PORTOT are used to further describe the anatomical location.
Interventions N/A 23 --LAT Laterality Qualifier for anatomical location further detailing side of intervention administration. What [is/was] the side (of the anatomical location of the administration)? Side Char --LAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LAT) Further detailing the laterality of the location where the --TRT was administered/taken. This may be pre- printed or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Interventions N/A 24 --DIR 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 administration)? Directionality Char --DIR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (DIR) Further detailing the directionality of the location where the --TRT was administered/taken (e.g., ANTERIOR, LOWER, PROXIMAL). This may be pre-printed or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Interventions N/A 25 -- PORTOT 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 administration)? Portion or Totality Char --PORTOT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (PORTOT) Further detailing the portion or totality of the location where the --TRT was administered/taken. This may be pre- printed or collected.
Interventions N/A 26 --FAST 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 study treatment [being taken/administered/given])? Fasting Char --FAST Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) N/A
Interventions N/A 27 --PSTRG Pharmaceutical Strength The amount of an active ingredient expressed quantitatively per dosage unit, per unit of volume, or per unit of weight, according to the pharmaceutical dose form. What [is/was] the pharmaceutical strength (of the [--TRT])? Pharmaceutical Strength Num --PSTRG Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Interventions N/A 28 -- PSTRGU Pharmaceutical Strength Units The unit for --PSTRG. What [is/was] the unit (of the pharmaceutical strength (of the [- -TRT]))? Unit Char --PSTRGU Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (UNIT) The unit is pre-printed on the CRF or a field provided on the CRF to capture it.
Interventions N/A 29 --TRTV Treatment Vehicle The vehicle for administration of treatment, such as a liquid in which the treatment drug is dissolved. Treatment Vehicle Char --TRTV Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Interventions N/A 30 --VAMT Treatment Vehicle Amount The amount of the prepared product (treatment + vehicle) administered or given. What [is/was] the amount (of the prepared product (treatment + vehicle) [administered/taken])? Treatment + Vehicle Amount Char --VAMT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Note: should not be diluent amount alone.
Interventions N/A 31 --VAMTU Treatment Vehicle Amount Units The unit of measurement for the prepared product (treatment + vehicle). What [is/was] the unit? Unit Char --VAMTU Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (UNIT) The unit is pre-printed on the CRF or a field provided on the CRF to capture it.
Interventions N/A 32 --FLRT [ --TRT] Infusion Rate The flow rate for the total amount of drug + vehicle administered to the subject. What [is/was] the ([--TRT] infusion) rate? ([--TRT] Infusion) Rate Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- FLRT" and SUPP--.QLABEL = "Infusion Rate". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. N/A Infusion rate can be used to derive dose.
Interventions N/A 33 --FLRTU [--TRT] Infusion Rate Unit The unit of measure for the flow rate for the total amount of drug + vehicle administered to the subject. What [is/was] the ([--TRT] infusion rate) unit? ([ --TRT ] Infusion Rate) Unit Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM= "--FLRTU" and SUPP.QLABEL= "Infusion Rate Unit". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (UNIT) The infusion rate unit (e.g., mL/min)is pre-printed on the CRF or a field provided on the CRF to capture it.
Interventions N/A 34 --ADJ Reason for Dose Adjustment Description or explanation of why a dose/amount of the intervention is adjusted. What [is/was] the reason the (study treatment/procedure) [dose/amount] was adjusted? Reason Adjusted Char --ADJ Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The implementer may choose to create sponsor-defined controlled terminology such as, Adverse Event, Insufficient response, Non-Medical Reason, etc.
Interventions N/A 35 --DOSADJ Dose Adjusted An indication whether or not the dose was adjusted. [Is/was] the (study treatment/procedure) [dose/amount] adjusted? (Dose) Adjusted Char N/A Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.If the Reason for Dose Adjustment is not collected, the sponsor might chose to submit this as a supplemental qualifier. (NY) 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 was deliberately left blank. However, the sponsor may collect whether the intervention was adjusted, without collecting the reason for the change.
Interventions N/A 36 --ITRPYN Intervention Interrupted An indication whether of not the intervention was interrupted. [Is/was] the [--TRT/Intervention] interrupted? [--TRT/Intervention] Interrupted 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 when the actual duration of the interruption is collected using the CDASH field --CINTD. In some situations, if the actual duration of the interruption is not collected, or not derived, this information could be submitted in a SUPP--.QVAL dataset where SUPP--.QNAM = "--ITRPYN" and SUPP--.QLABEL = "Intervention Interrupted".
Interventions N/A 37 -- REASOC Reason for Occur Value An explanation of why the scheduled intervention did or did not occur. What was the reason that the [intervention topic] was (not) [performed/taken/done/administered]? Reason (Not) [Performed/Taken/Done/Administered] Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- REASOC" and SUPP-- .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 The reason the intervention did not occur may be chosen from a sponsor-defined codelist (e.g., SUBJECT MISTAKE, SUBJECT REFUSED, etc.) or entered as free text. When --REASOC is used, -- OCCUR must also be populated in the SDTM dataset with a value of "N".
Interventions N/A 38 --ITRPRS Reason Intervention Interrupted An indication why the intervention was interrupted. Why was the [--TRT/Intervention] interrupted? Reason [--TRT/Intervention] Interrupted Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- ITRPRS" and SUPP-- .QLABEL ="Reason Intervention Interrupted". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. N/A This CDASH field is use to collected the reason why an intervention was interrupted. The sponsor may define their own controlled terminology.
Interventions N/A 39 --CINTD Interruption Duration The collected duration of the intervention interruption. What was the duration of the [--TRT/Intervention] interruption?; How long was the [--TRT/Intervention] interruption? (Interruption) Duration Char SUPP-- .QVAL This does not map directly to an SDTM variable. This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--ITRPD" and SUPP--.QLABEL= "Interruption Duration". Concatenate the collected intervention interruption duration and the duration unit components and create --ITRPD 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 This CDASH field is use to collected the duration of an intervention interruption. In some situations, the duration of the interruption may not be collected but calculated from the intervention start and end times recorded elsewhere in the CRF.
Interventions N/A 40 --CINTDU Interruption Duration Unit The unit for the collected duration of intervention interruption. What [is/was] the (interruption duration) unit? (Interruption Duration) Unit Char SUPP-- .QVAL This does not map directly to an SDTM variable. This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--ITRPD" and SUPP--.QLABEL= "Interruption Duration". Concatenate the collected intervention interruption duration and the duration unit components and create --ITRPD using ISO 8601 Period format. Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (UNIT) The unit is pre-printed on the CRF or a field provided on the CRF to capture it.
Interventions N/A 41 -- TRTCMP Completed Treatment An indication of whether or not the subject completed the intended regimen. Did the subject complete [treatment/ the full course/sponsor provided phrase] (of the [--TRT/Intervention])? Completed [--TRT/Intervention] Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- TRTCMP" and SUPP-- .QLABEL ="Completed Treatment". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (NY) This could be used when treatment is given as a fixed number of cycles and the sponsor needs a flag to indicate that the treatment has been completed as planned.
Interventions N/A 42 --NCF Never Current Former Usage An indication of whether the substance was used and when it was used. Has the subject ever [used/consumed] [--TRT/Intervention]? Usage Char --OCCUR; -- STRTPT; -- STRF; -- ENRTPT; -- ENRF This does not map directly to an SDTM variable. May be used to populate a value into the SDTM variable --OCCUR. If --NCF = "Never", the value of -- OCCUR will be "N". If -- NCF = "Current" or "Former", the value of -- OCCUR will be "Y". May also be used to populate a value into an SDTM relative timing variable such as --STRTPT or -- STRF. If the value of --NCF is "Former", the value of ""BEFORE" may be used. If the value of --NCF is "current", the value of "ONGOING" may be used. When populating -- STRTPT, if the value of -- NCF is "Former", the value of "BEFORE" may be used. Note: --STRTPT must refer to a time point anchor described in --STTPT. This variable may also be used to populate the SDTM ending relative timing variables. (NCF) The preferred SDTM mapping is provided. This information is usually not submitted in a SUPP--.QVAL dataset. 
Interventions N/A 43 --ONGO Ongoing Intervention An indication whether the intervention is ongoing as of a given timepoint when no End Date is provided. [Is/Was] the [--TRT/Intervention] ongoing (as of [the study- specific timepoint or period])? Ongoing (as of the [Study-Specific Timepoint or Period]) Char --ENRTPT; -- ENRF This does not map directly to an SDTM variable. May be used to populate a value into an SDTM relative timing variable such as --ENRF or -- ENRTPT. When populating --ENRF, or --ENRTPT, if the value of the CDASH field --ONGO is "Y" a value from the CDISC CT (STENRF) may be used.When --ONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable --ENRF should be populated. When --ONGO is compared to another timepoint, the SDTM variables --ENRTPT and -- ENTPT should be used.Note: --ENRTPT must refer to the time point anchor described in -- ENTPT. (NY) The CDASH field --ONGO allows specific question text/prompt about interventions ending after the study or after a given timepoint. Select the appropriate text when designing the CRF. This may also be included in the CRF title or instructions. Used in conjunction with either a reference timepoint (--ENTPT, --ENRTPT) or in conjunction with the Study Reference Period (described as RFSTDTC to RFENDTC). May also be used as a tick/checkbox. See the CDASH IG Section 3.7 for more information.
Interventions N/A 44 COVAL Comment A free text comment. [Protocol-specified Targeted Question]? [Abbreviated version of the protocol-specified targeted question] Char CO.COVAL This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable --COVAL maps to the SDTM variable COVAL (COVAL2, COVAL3) in the CO domain. Associate the free text comment in the CO domain with the original record using RDOMAIN, IDVAR, IDVARVAL, COREF. N/A If an additional free text field is needed to provide a comment about a particular record, use the COVAL(n) field to collect the free text, and associate the free text comment with the original record using SDTM variables RDOMAIN, IDVAR, IDVARVAL, COREF. See the SDTMIG for more information.
Interventions N/A 45 --MODIFY Modified Treatment Name If the value for --TRT is modified for coding purposes, then the modified text is placed here. N/A N/A Char --MODIFY Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. 
Interventions N/A 46 --CLAS Class The class for the intervention, often obtained from a coding dictionary. N/A N/A Char --CLAS Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the interventions utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). This would generally be the class used for analysis.
Interventions N/A 47 --CLASCD Class Code The assigned dictionary code for the class for the intervention. N/A N/A Char --CLASCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the interventions utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). This would generally be the class used for analysis.
Interventions N/A 48 --ATC1 ATC Level 1 Description The first level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the anatomical main group. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM= "--ATC1" and SUPP--QLABEL= "ATC Level 1 Description". 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 49 --ATC1CD ATC Level 1 Code The assigned 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 SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- ATC1CD" and SUPP-- .QLABEL="ATC Level 1 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 50 --ATC2 ATC Level 2 Description The second level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic main group. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = --ATC2 and SUPP--QLABEL="ATC Level 2 Description". 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 51 --ATC2CD ATC Level 2 Code The assigned 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 SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = -- ATC2CD and SUPP-- .QLABEL="ATC Level 2 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 52 --ATC3 ATC Level 3 Description The third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharmacological subgroup. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--ATC3" and SUPP--QLABEL="ATC Level 3 Description". 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 53 --ATC3CD ATC Level 3 Code The assigned Dictionary Code denoting the third level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the therapeutic/pharmacological subgroup. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- ATC3CD" and SUPP-- .QLABEL="ATC Level 3 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 54 --ATC4 ATC Level 4 Description The fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeutic/pharmacologic al subgroup. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--ATC4" and SUPP--QLABEL="ATC Level 4 Description". 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 55 --ATC4CD ATC Level 4 Code The assigned Dictionary Code denoting the fourth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical/therapeutic/pharmacologic al subgroup. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- .QVAL dataset where SUPP--.QNAM = "-- ATC4CD" and SUPP-- .QLABEL="ATC Level 4 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 56 --ATC5 ATC Level 5 Description The fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical substance. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--ATC5" and SUPP-- .QLABEL="ATC Level 5 Description". 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 57 --ATC5CD ATC Level 5 Code The assigned Dictionary Code denoting the fifth level of hierarchy within the Anatomical Therapeutic Chemical Classification System. Indicates the chemical substance. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- ATC5CD" and SUPP-- .QLABEL="ATC Level 5 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 This is not a data collection field that will appear on the CRF itself. Sponsors will populate this through the coding process (e.g., WHO Drug). Rationale for adding coding variables to CDASH is to provide a more complete Data Management package. This is an example of variables that could be used in the CM domain for coding. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 58 --INGRD Active Ingredients A description of the active ingredients used in the medication taken or administered. What [are/were] the active ingredients? Active Ingredients Char SUPP-- .QVAL This information could be submitted in a SUPP-- .QVAL dataset where SUPP--.QNAM = "-- INGRID" and SUPP-- .QLABEL= "Active Ingredients". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. N/A This may be collected in addition to the Medication/Therapy Name. Collecting this provides more detailed information when coding to a medication dictionary like WHO Drug Enhanced format C which now codes to the ingredient level for many trade named medications.
Interventions N/A 59 --LLT Lowest Level Term MedDRA Dictionary text description of the Lowest Level Term. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = " --LLT" and SUPP--.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 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 dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 60 --LLTCD Lowest Level Term Code MedDRA Dictionary Lowest Level Term code. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM= "--LLTCD" and SUPP--.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 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 dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 61 --PTCD Preferred Term Code MedDRA Dictionary code for the Preferred Term. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- .QVAL dataset where SUPP--.QNAM = "--PTCD" and SUPP--.QLABEL= "Preferred 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 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 dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 62 --HLT High Level Term MedDRA Dictionary text description of the High Level Term from the primary path. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "--HLT" and SUPP--.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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 63 --HLTCD High Level Term Code MedDRA Dictionary High Level Term code from the primary path. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- .QVAL dataset where SUPP--.QNAM= "--HLTCD" and SUPP-- .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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 64 --HLGT High Level Group Term MedDRA Dictionary text description of the High Level Group Term from the primary path. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- HLTGT" and SUPP-- .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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 65 -- HLGTCD High Level Group Term Code MedDRA High Level Group Term code from the primary path. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- HLTGTCD" and SUPP-- .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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 66 --SOC Primary System Organ Class MedDRA Primary System Organ Class description associated with the intervention. N/A N/A Char SUPP-- .QVAL This information could be submitted in a SUPP-- .QVAL dataset where SUPP--.QNAM = "--SOC" and SUPP--.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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.
Interventions N/A 67 --SOCCD Primary System Organ Class Code MedDRA primary System Organ Class code. N/A N/A Num SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM = "-- SOCCD" and SUPP-- .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 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. Other dictionaries can be used and the appropriate coding elements added, if appropriate, in the SUPP--.QVAL dataset.

2.2 Events

Observation ClassDomainOrder Number  CDASH Variable  CDASH Variable Label  DRAFT CDASH Definition Question Text Prompt Data Type SDTM Target Mapping Instructions Controlled Terminology Codelist Name Implementation Notes
Events N/A 1 --YN Any [Event] An indication whether or not any data was collected for the event topic. Has the subject had any [event topic(s)/term/name] ([study specific time frame])?; [Was/Were] (there) any [event topic(s)] (reported) ([study specific time frame])? Any [Event Topic] ([study specific time frame]) 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 is a field that can be used on any events 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. If the response of YES/NO, is planned to be submitted in the SDTM submission datasets, this CDASH variable should not be used and the appropriate CDASH variable should be used instead (e.g., -- OCCUR).
Events N/A 2 --TERM Reported Term The topic variable for an event observation, which is the reported or pre-specified name of the event. What [is/was] the [event topic/term/name]?; If -- DECOD (is selected), [explain/specify/provide (more) detail(s)]? [Event Topic]; [Specify/Specify Other/Explain/Provide Details (for [Event Topic])] Char --TERM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Typically, --TERM collects the verbatim text for an Event. If the term is preprinted/pre-specified, the value can be populated into the --TERM variable as a hidden field e.g., if Headache is preprinted on an AE CRF, "Headache" should be stored in AETERM. The CDASH field --TERM can also be used to collect any free text values linked to the sponsor-standardized value collected in the CDASH field --DECOD. For example, --DECOD may have a value of "OTHER" and the associated free text event topic is collected in --TERM. In this scenario, the Item prompt "Specify Other" may be used.
Events N/A 3 --DECOD Dictionary- Derived Term The dictionary or sponsor-defined standardized text description of the topic variable, --TERM, or the modified topic variable (-- MODIFY), if applicable. What [is/was] the [event/event topic] (at the EPOCH/study specific time frame)? (Standardized) [Event/Event Topic] (at the EPOCH/Study Specific Time Frame) Char --DECOD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". If the sponsor uses a dictionary to code the --TERM, it expected that the dictionary name and version is provided in the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A When populated by the a coding dictionary such as MedDRA, Question Text and Prompt may not be applicable. This is equivalent to the Preferred Term (PT) in MedDRA. The CDISC Controlled terminology (NCOMPLT) is used for the DS Domain only. The CDASH field -- DECOD may be used to collect standardized pre-specified values (CDISC Controlled Terminology or Sponsor-defined Terminology) on a CRF. The CDASH field --TERM can be used to collect any free text values linked to the sponsor-standardized value. For example, the CDASH field --DECOD may have a value of "OTHER" and the associated free text event topic is collected in the CDASH field --TERM.
Events N/A 4 --CAT Category A grouping of topic-variable values based on user-defined characteristics. What [is/was] the category (of the [--TERM/event topic])? [Category/Category Value]; NULL Char --CAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. - -SCAT can only be used if there is a -- CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG. 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 are provided in the CDASHIG Metadata Table or in the SDTMIG.
Events N/A 5 --SCAT Subcategory A sub-division of the --CAT values based on user-defined characteristics. What [is/was] the subcategory (of the [-- TERM/event topic])? [Subcategory/Subcategory Value]; NULL Char --SCAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. - -SCAT can only be used if there is a -- CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG.
Events N/A 6 --PRESP Pre-Specified An indication that a specific event, or group of events, is pre-specified on a CRF. N/A N/A Char --PRESP Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) For pre-specified events a hidden field on a CRF defaulted to Y, or added during the SDTM dataset creation. If a study collects both pre-specified events as well as free-text events, the value of --PRESP should be Y for all pre-specified events and null for events reported as free-text.
Events N/A 7 --OCCUR Occurrence An indication whether the pre- specified event or the group of events occurred when the occurrence of the specific event or group of events is solicited. [Did/Does] the subject have [--TERM] (after/before [study-specific time frame])?; Is the [pre-specified medical occurring]? [--TERM] Char --OCCUR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) If the term is preprinted/pre-specified, then the value is mapped into the --TERM variable. (e.g., if Headache is preprinted on an AE CRF, "Headache" should be stored in AETERM.)
Events N/A 8 --PERF [Observation] Performed The variable used to indicate whether data are available by having the site recording the value as "Yes" or "No". (Were/Was) (the) [event topic] [answered/done/assessed/evaluated/available]? ([event topic]) [Answered/Done/Assessed/Evaluated/Available] Char --STAT This field does not map directly to an SDTM variable. May be used to populate a value into the SDTM variable --STAT to indicate when a pre-specified Event was not assessed. For use with prespecified events, when the CDASH variable --PERF="N", the value of the STDM variable --STAT is "NOT DONE". If --PERF= "Y", --STAT is null. (NY) Using --PERF, a response of "Y" or "N" can be collected. A negative response can be collected as "N" and mapped to the --STAT variable in SDTM as "NOT DONE". --PERF can be used instead of -- STAT when a YN response list is needed for implementation. Example: Were medical history conditions assessed?
Events N/A 9 --STAT Completion Status The variable used to indicate that data are not available by having the site recording the value as "Not Done". Was the [event topic] not [answered/done/assessed/evaluated]?; Indicate if ([event topic] was) not [answered/assessed/done/evaluated]. Not Done Char --STAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". If collected, the Origin (column in the Define-XML) "CRF", if populated from other sources such as a free text or sponsor-defined listing for --REASND, the Origin "DERIVED". (ND) A "Not Done" check box, which indicates the data is not available/question was not asked. Typically, there would be one check box for each pre-specified event. This field can be useful when multiple questions are asked to confirm that a blank result field is meant to be blank.
Events N/A 10 -- REASND Reason Not Done An explanation of why the assessment/evaluation/question was not answered/collected/done, etc. What [is/was] the reason that the ([data/information/sponsor-defined phrase]) was not [answered/collected/done/evaluated/assessed]? Reason Not [Answered/Collected/Done/Evaluated/ Assessed/Available] Char --REASND Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology may be used. The reason the data was not done/not collected may be chosen from a select list (for example, broken equipment, subject refused, etc.) or entered as free text. When --REASND is used, --STAT should also be populated in the SDTM dataset.
Events N/A 11 --LOC Location of Event A description of the anatomical location relevant for the event. What [is/was] the anatomical location (of the [-- TERM/event topic])? Anatomical Location Char --LOC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LOC) This may be pre-printed or collected. -- LOC is used only to specify the anatomical location. --LAT, --DIR, -- PORTOT are used to further describe the anatomical location.
Events N/A 12 --LAT Laterality Qualifier for anatomical location further detailing the side of the body relevant for the event. What [is/was] the side (of the anatomical location of the event)? Side Char --LAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LAT) Further detailing the laterality of the location of the --TERM. This may be pre- printed or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Events N/A 13 --DIR 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)? Directionality Char --DIR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (DIR) Further detailing the directionality of the location of the --TERM (e.g., ANTERIOR, LOWER, PROXIMAL). This may be pre- printed or collected. Sponsors may collect the data using a subset list of CT on the CRF .
Events N/A 14 -- PORTOT 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) involved? Portion or Totality Char --PORTOT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (PORTOT) Further detailing the portion or totality of the location of the --TERM. This may be pre-printed or collected.
Events N/A 15 --PARTY Accountable Party The party accountable for the transferable object (e.g., device, specimen) as a result of the activity performed in the associated --TERM variable. Who [is/was] the accountable party? Accountable Party Char --PARTY Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. The party could be an individual (e.g., subject), an organization (e.g., sponsor), or a location that is a proxy for an individual or organization (e.g., site). It is usually a somewhat general term that is further identified in the -- PRTYID variable (e.g., SITE, SPONSOR, SUBJECT).
Events N/A 16 --PRTYID Identification of Accountable Party Identification of the specific party accountable for the transferable object (e.g., device, specimen) after the action in -- TERM is taken. What [is/was] the accountable party identifier? Accountable Party ID Char --PRTYID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Used in conjunction with --PARTY. This identifier is defined by the sponsor.
Events N/A 17 --SEV Severity/Intensity The severity or intensity of the event. What [is/was] the severity (of the event topic)? Severity Char --SEV Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A In the AE domain, AESEV uses CDISC Controlled Terminology (AESEV).
Events N/A 18 --ACN 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 --ACN Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (ACN) How to handle multiple actions taken is sponsor-specific decision. This variable is not to be used for actions taken with devices.See the SDTM Device IG for information on reporting multiple actions, or actions with multiple devices.
Events N/A 19 --SER Serious Event An indication whether or not this event met the definition of serious. [Is/Was] [the event topic/it] serious? Serious Char --SER Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) N/A
Events N/A 20 -- ACNOTH Other Action T aken A description of other action(s) taken as a result of the event that are unrelated to dose adjustments of the study treatment. What other action(s) [were/was] taken? Other Actions Taken Char --ACNOTH Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Events N/A 21 -- ACNDEV Action 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 the device used in the study? Action Taken with Device Char --ACNDEV Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This variable is intended to be used like -- ACN, but is about the device rather than the study treatment. See the SDTM Device IG for information on reporting multiple actions, or actions with multiple devices.
Events N/A 22 --REL Causality The investigator's opinion as to the relationship of the event to the study treatment. [Is/Was] this event related to study treatment? Relationship to Study Treatment Char --REL Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. ICH E2A and E2B examples include NOT RELATED, UNLIKELY RELATED, POSSIBLY RELATED, RELATED.
Events N/A 23 -- RELNST Relationship to Non-Study Treatment A description of the investigator's opinion as to whether the event may have been due to a treatment other than study treatment. What [is/was] the relationship to non-study treatment? Relationship to Non-Study Treatment Char --RELNST Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A May be reported as free text. Example: "MORE LIKELY RELATED TO ASPIRIN USE.
Events N/A 24 --PATT Pattern of Event A description of the pattern of the event over time. What [is/was] the pattern of the event over time? Pattern Char --PATT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology.
Events N/A 25 --OUT Outcome of Event A description of the outcome of an event. What [is/was] the outcome (of the event/event topic)? Outcome Char --OUT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A CDISC Controlled Terminology (OUT) is used in the AE domain.
Events N/A 26 -- CONTRT 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 [event])? Concomitant or Additional Trtmnt Given Char --CONTRT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) N/A
Events N/A 27 --TOX Toxicity A description of toxicity quantified by --TOXGR such as NCI CTCAE Short Name. N/A N/A Char --TOX Maps directly to the SDTM variable listed in the column with the heading "SDTM 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 If used, --TOX would be populated with the decoded value from --TOXGR. For example, if the --TERM is HYPERTENSION, and the --TOXGR is "1", --TOX is populated with "Prehypertension (systolic BP 120 - 139 mm Hg or diastolic BP 80 - 89 mm Hg)"
Events N/A 28 --TOXGR Toxicity Grade The toxicity grade using a standard toxicity scale (such as the NCI CTCAE). What [is/was] the [NCI CTCAE/Name of Scale] grade? [NCI CTCAE Toxicity] Grade Char --TOXGR Maps directly to the SDTM variable listed in the column with the heading "SDTM 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 Refer to ICH E3 guidelines for CSR Section 12.2.4. CTCAE grade is commonly used in oncology studies although it can also be used elsewhere. Other published "toxicity" like scales may be used.
Events N/A 29 --ONGO Ongoing Event An indication whether the event is ongoing as of a given timepoint when no End Date is provided. [Is/Was] the [--TERM/event topic] ongoing (as of [the study-specific timepoint or period])? Ongoing (as of the [Study-Specific Timepoint or Period]) Char --ENRTPT; --ENRF This does not map directly to an SDTM variable. May be used to populate a value into an SDTM relative timing variable such as --ENRF or --ENRTPT. When populating --ENRF, or -- ENRTPT, if the value of the CDASH field --ONGO is "Y" a value from the CDISC CT (STENRF) may be used. When --ONGO refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable --ENRF should be populated. When --ONGO is compared to another timepoint, the SDTM variables --ENRTPT and --ENTPT should be used. Note: --ENRTPT must refer to the "time point anchor" described in --ENTPT. (NY) The CDASH field --ONGO allows specific question text/prompt about events ending prior to the given timepoint. Select the appropriate text when designing the CRF. This may also included in the CRF title or instructions. Used in conjunction with either a reference timepoint (--ENTPT, -- ENRTPT) or in conjunction with the Study Reference Period (described as RFSTDTC to RFENDTC). May also be used as a tick/checkbox. See the CDASH IG Section 3.7 for more information.
Events N/A 30 --DIS Caused Study Discontinuation An indication whether the event caused the subject to discontinue from the study. Did the [--TERM/event topic] cause the subject to be discontinued from the study? Caused Study Discontinuation Char SUPP-- .QVAL Does not map directly to an SDTM variable For the SDTM submission datasets, may be used to create a RELREC to link the Event to the Disposition record. The sponsor could submit "--DIS" in a SUPP-- dataset as a value of SUPP--.QVAL where SUPP- -.QNAM is "--DIS" and SUPP-- .QLABEL is "Caused Study Discontinuation", if appropriate. (NY) May be used to create a RELREC to link the record to a Disposition record. See section 8.2 in the SDTMIG V3.2 for information on RELREC. The sponsor could submit "--DIS" in a SUPP-- dataset as a value of SUPP--.QVAL where SUPP--.QNAM is "--DIS" and SUPP-- .QLABEL is "Caused Study Discontinuation", if appropriate.
Events N/A 31 --CTRL Disease or Symptom Under Control An indication that the disease/symptoms are under control at the time of data collection. [Is/Was] the [--TERM/event topic] under control? [--TERM/Event Topic] Under Control Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM is "--CTRL" and SUPP--.QLABEL is "Disease or Symptom Under Control". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (NY) The conditions would typically be defined in the protocol. For example, a sponsor may ask the site to indicate whether the subject's hypertension is under control at enrollment into the study.
Events N/A 32 --REAS Reason for the Event A description of the reason for the event. What [is/was] the reason (for the [--TERM/event topic])? Reason for the [--TERM/Event Topic] Char SUPP-- .QVAL This information could be submitted in a SUPP-- dataset as the value of SUPP--.QVAL where SUPP--.QNAM is "--REAS" and SUPP--.QLABEL is "Reason for the Event". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains. N/A To ensure data quality, it is recommended that the sponsor develop controlled terminology. Reason for Health Care Encounters could include LACK OF EFFICACY, ADVERSE EVENT, CHEMOTHERAPY, PHYSICAL THERAPY, INDICATION UNDER STUDY, NOT INDICATION UNDER STUDY.
Events N/A 33 COVAL Comment A free text comment. [Protocol-specified Targeted Question]? [abbreviated version of the protocol-specified targeted question] Char CO.COVAL This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable --COVAL maps to the SDTM variable COVAL (COVAL2, COVAL3) in the CO domain. Associate the free text comment in the CO domain with the original record using RDOMAIN, IDVAR, IDVARVAL, COREF. N/A If an additional free text field is needed to provide a comment about a particular record, use the COVAL(n) field to collect the free text, and associate the free text comment with the original record using SDTM variables RDOMAIN, IDVAR, IDVARVAL, COREF. See the SDTMIG for more information.
Events N/A 34 -- MODIFY Modified Reported Term If the value for --TERM is modified for coding purposes, then the modified text is placed here. N/A N/A Char --MODIFY Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This is not a data collection fieldthat will appear on the CRF itself. Sponsors will populate this through the coding process. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 35 --LLT Lowest Level Term MedDRA Dictionary text description of the Lowest Level Term. N/A N/A Char --LLT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 36 --LLTCD Lowest Level Term Code MedDRA Dictionary Lowest Level Term code. N/A N/A Num --LLTCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 37 --PTCD Preferred Term Code MedDRA Dictionary code for the Preferred Term. N/A N/A Num --PTCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event 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 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.
Events N/A 38 --SOC Primary System Organ Class MedDRA Primary System Organ Class description associated with the event. N/A N/A Char --SOC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". 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.
Events N/A 39 --SOCCD Primary System Organ Class Code MedDRA primary System Organ Class code. N/A N/A Num --SOCCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". 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.
Events N/A 40 --HLT High Level Term MedDRA Dictionary text description of the High Level Term from the primary path. N/A N/A Char --HLT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 41 --HLTCD High Level Term Code MedDRA Dictionary High Level Term code from the primary path. N/A N/A Num --HLTCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 42 --HLGT High Level Group Term MedDRA Dictionary text description of the High Level Group Term from the primary path. N/A N/A Char --HLGT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Events N/A 43 -- HLGTCD High Level Group Term Code MedDRA Dictionary High Level Group Term code from the primary path. N/A N/A Num --HLGTCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The sponsor is expected to provide the dictionary name and version used to code the event utilizing the Define-XML external codelist attributes. Sponsors should include an Origin column in the define metadata document to indicate that the data was "ASSIGNED". N/A This field does not typically appear on the CRF. Sponsors will populate this through the coding process. This variable is applicable when using the MedDRA coding dictionary. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.

2.3 Findings

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
Findings About Events or Interventions FA 1 --OBJ Object of the Observation Describes the event or intervention whose property is being measured in -- TESTCD/--TEST. N/A N/A Char --OBJ Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The --OBJ will usually be pre-printed or hidden, and not solicited as an actual question. These FA domains are usually created by each sponsor. CDASH has used this variable in the SR domain.
Findings N/A 1 --YN Any [Finding] An indication whether or not any data was collected for the finding topic. Has the subject had any [Findings topic(s)] ([study specific time frame])?; [Was/Were/Is] (there) [a/any] [Findings topic(s)] (reported/available) ([study specific time frame])?; Were all eligibility criteria met? Any [Findings topic(s)] ([study specific time frame]) 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 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 or to dynamically drive EDC form functionality. This provides verification that all other fields on the CRF were deliberately left blank. For example, this is used in the 1. DD domain to indicate no information on any death details are being provided, 2. IE domain to indicate whether the subject met all the eligibility requirements for this study at the time the subject was enrolled. --PERF should be used to capture a response about whether planned measurements, tests, observations were done.
Findings N/A 2 --PERF [Observation] 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)] [--TEST/topic] ([measurement(s)/test(s)/examination(s)/question( s)/assessment(s)/ specimen(s) /sample(s)]) [performed/collected]? [--TEST/topic] ([Measurement (s)/Test(s)/Examination(s)/Specimen(s)/Assessment(s)/ Question(s) Sample(s)]) [Performed/Collected] Char --STAT This field does not map directly to an SDTM variable. May be used to populate a value into the SDTM variable --STAT. If the CDASH variable --PERF="N", the value of the STDM variable - -STAT is "NOT DONE". If -- PERF= "Y", --STAT is null. A combination of SDTM variables (e.g., --CAT and --SCAT, --TPT ) is used to indicate that multiple tests were not done. In this situation, the SDTM variable -- TESTCD would be populated with --ALL and an appropriate test name (--TEST) provided. See SDTMIG for the section on "Tests Not Done". (NY) 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 -- STAT variable in SDTM as "NOT DONE".
Findings N/A 3 -- TESTCD Short Name of Measurement, Test or Examination Short character value code for the test being performed. N/A N/A Char --TESTCD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The SDTM variable --TESTCD may be determined from the value collected in --TEST. The SDTMIG variables --TESTCD and --TEST are required in SDTM. (--TESTCD) May be used as a column name when converting from a vertical dataset format to a horizontal dataset format. --TESTCD is most useful as a variable name, or variable naming fragment (e.g., [-- TESTCD_--ORRES]) for the clinical database or EDC system for the field in which the result is collected for that test. The short value can be up to 8 characters. The domain-specific -- TESTCD codelists names (e.g., EGTESTCD, FATESTCD) are provided in the CDASHIG Metadata Table.
Findings N/A 4 --TEST Name of Measurement, Test or Examination Descriptive name for the test being performed. Examples: Platelet, Systolic Blood Pressure, Summary (Min) RR Duration, Eye Examination. What [is/was] the name (of the [measurement/test/examination/question/assessm ent])? [Measurement/Test/Examination/Question/Assessment] (Name) Char --TEST Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". The SDTM variable --TESTCD may be determined from the value collected in --TEST. The SDTMIG variables --TESTCD and --TEST are required in SDTM. (--TEST) The test name will usually be pre-printed on the CRF, and not solicited as a question. If the form is laid out as a grid, then words such as Test or Test Name can be included as the column header. -- TEST is most useful as the PROMPT on the field in which the RESULT for that test is collected. The domain-specific TEST codelists names (e.g., EGTEST, FATEST ) are provided in the CDASHIG Metadata Table.
Findings N/A 5 -- TSTDTL Measurement, Test or Examination Detail A further description of --TESTCD and -- TEST. What [is/was] the [measurement/test/examination/question/assessm ent] detail name? [Measurement/Test/Examination/Question/Assessment] Detail (Name) Char --TSTDTL Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A It is recommended that the test detail name be pre-printed 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 N/A 6 --CAT Category A grouping of topic- variable values based on user-defined characteristics. What [is/was] the [type/category/name] (of the [measurement/test/examination/question/assessm ent/specimen/sample])? [Category/Category Value]; NULL Char --CAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. --SCAT can only be used if there is a --CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG. 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 are provided in the CDASHIG Metadata Table or in the SDTMIG. Note: CDISC Controlled terminology (IECAT) is used for the IE domain.
Findings N/A 7 --SCAT Subcategory A sub-division of the -- CAT values based on user-defined characteristics. What [is/was] the [type/subcategory/name] (of the [measurement/test/examination/question/assessm ent/specimen/sample])? [(Domain Name/Name) Subcategory]; NULL Char --SCAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. This would most commonly be a heading on the CRF or screen, not a question to which the site would provide an answer. --SCAT can only be used if there is a --CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG. 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. --SCAT can only be used if there is a --CAT. Examples are provided in the CDASHIG Metadata Table or in the SDTMIG.
Findings N/A 8 --ORRES 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/question/assessm ent])? ([Result/Amount]of) [value from --TEST] Char --ORRES Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A In most cases, the Question Text and Item Prompt for the --ORRES are specific to the --TEST. The value of -- TEST 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. On CRFs used for the drug accountability, the prompt and question text can reflect that the "amount" of study drug dispensed/returned is collected rather than a result.
Findings N/A 9 -- ORRESU Original Units The unit of the result as originally received or collected. What [is/was] the unit (of the [measurement/test/examination/question/assessm ent])? Unit Char --ORRESU Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (UNIT) The Question Text and Item Prompt for the --ORRESU may be specific to the -- TEST. Should be pre-printed on the CRF with the associated test when possible, rather than collected in a field that requires the site to enter text. Note: CDISC Controlled Terminology (PKUNIT) is used for the SDTMIG PP domain, and (VSRESU) is used for the VS domain.
Findings N/A 10 --CRESU Collected Non- Standard Unit The unit of the result if it were collected as a non-standard unit. Unit Char SUPP-- .QVAL This does not map directly to an SDTM variable. The collected, non-standard unit(s) may be submitted in a submitted in a SUPP--dataset as the value of SUPP--.QVAL when SUPP-- .QNAM = --CRESU and SUPP.QLABEL= "Collected Non-Standard Unit". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. N/A The collected, non-standard unit(s) should be reported as an equivalent standard unit in --ORRESU.
Findings N/A 11 --DESC Description of Finding Text description of any findings. What [is/was] the (description) of the [(abnormality/observed finding/Sponsor-defined)]? (Abnormal) Findings Char --ORRES This does not map directly to an SDTM variable. For the SDTM submission dataset, if the CDASH field -- RES = "NORMAL/ABSENT", populate the SDTM variables --ORRES and --STRESC with the value of the CDASH field --RES. If the value of the CDASH field --RES is "ABNORMAL/PRESENT", populate the SDTM variable -- ORRES with the CDASH field -- DESC. If the reported findings in --DESC are coded using a dictionary, then the SDTM variable --STRESC is populated with the dictionary preferred term and --MODIFY is populated with the modified text used for coding. If the reported findings in --DESC are not coded, then the SDTM variable --STRESC is populated with the CDASH -- DESC field. The SDTM variable, --NRIND, may be populated with "NORMAL" or "ABNORMAL" if appropriate. N/A --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.. See CDASH General Finding Assumptions
Findings N/A 12 --RES Collected Result or Finding The result of the measurement or finding as originally received or collected. What [is/was] the [result/amount] (of the [measurement/test/examination/question/assessm ent])?; [Is/Was] the result [normal/abnormal/absent/present/ sponsored defined response]? ([Result/Amount]of) [value from --TEST] Char --ORRES This does not map directly to an SDTM variable. See CDASH variables --DESC, or --RESOTH for mapping information. N/A The CDASH field --RES is used when the collected results are not mapped directly to the SDTM variable --ORRES. --RES is typically used in conjunction with --DESC, or --RESOTH.
Findings N/A 13 -- RESOTH Result Other A free text result which provides further information about the original received or collected result. If other is selected, [explain/specify/provide more detail]? [Specify Other/Explain/Specify Details] Char --ORRES When using this CDASH field, the "OTHER" value collected in the CDASH field --RES is mapped to the SDTM variable -- STRESC and the value in the CDASH field --RESOTH is mapped to the SDTM variable -- ORRES. See section 4.1.2.7.2 in the SDTMIG. N/A --RES and ---RESOTH are used when a question is asked that allows the selection of a pre-specified finding, with a follow-up question to ask about the pre-specified response "OTHER". See CDASH General Finding Assumptions
Findings N/A 14 -- RESCAT Result Category A categorization of the result of a finding. What [is/was] the result category (of the [measurement/test/examination/question/assessm ent])? [--TEST] Result Category Char --RESCAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor-defined Controlled Terminology. Example: MALIGNANT or BENIGN for tumor findings. RESISTANCE VARIANT for genetic variation. Note: CDISC Controlled terminology (MSRESCAT) is used for the MS domain.
Findings N/A 15 -- ORNRLO Normal Range Lower Limit- Original Units 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/question/assessm ent])? Normal Range Lower Limit Char --ORNRLO Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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 N/A 16 -- ORNRHI Normal Range Upper Limit- Original Units 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/question/assessm ent])? Normal Range Upper Limit Char --ORNRHI Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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 N/A 17 -- CSTNRC Collected Character/Ordinal Normal Range The normal references ranges that are expressed as characters ("Negative to Trace") or ordinal (-1 to 1). What [is/was] the normal reference range (for this [measurement/test/examination/question/assessm ent])? Normal Reference Range Char --STNRC This does not map directly to an SDTM variable. For the SDTM submission dataset, maps to -- STNRC. N/A Should be populated for normal ranges that are reported as character in ordinal scale or if categorical ranges were supplied. 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 N/A 18 --NRIND Normal/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 --NRIND Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NRIND) Reference ranges may be defined by -- ORNRLO, --ORNRHI, --STNRC or other objective criteria. Reference Range Indicator (e.g., Y, N; HIGH, LOW; NORMAL; ABNORMAL) may be included if not derived or determined programmatically after data collection. Should not be used to indicate clinical significance. Should not be used to indicate clinical significance.
Findings N/A 19 --STAT 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/assessed/evaluated]?; Indicate if (the [--TEST] was) not [answered/assessed/done/evaluated/performed]. Not Done Char --STAT Maps directly to the SDTM variable listed in the column with the heading "SDTM 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 --REASND, the Origin ="DERIVED". (ND) Used only when the response value is collected as NOT DONE or NULL in lieu of or in addition to the CDASH --PERF 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 N/A 20 -- REASND Reason Not Done An explanation of why the data are not available. What [is/was] the reason that the [Findings topic/data/information/sponsor-defined phrase] was not [collected/answered/done/assessed/evaluated]? Reason Not [Answered/Collected/Done/Evaluated/Assessed/Available] Char --REASND Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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 N/A 21 --NAM Laboratory/Vendor Name 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 --NAM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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.
Findings N/A 22 --LOINC LOINC Code The Logical Observation Identifiers Names and Codes (LOINC) code for the topic variable such as a lab test. What [is/was] the LOINC code? LOINC Code Char --LOINC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Findings N/A 23 --SPEC Specimen Material Type The type of specimen used for a measurement. What [is/was] the specimen (material) type? Specimen (Material) Type Char --SPEC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (SPECTYPE) N/A
Findings N/A 24 -- ANTREG Anatomical Region The specific anatomical or biological region of a tissue, organ specimen or the region from which the specimen is obtained, as defined in the protocol, such as a section or part of what is described in the -- SPEC variable. What [is/was] the anatomical or biological region (of the [organ specimen/tissue])? [Specimen/Organ/Tissue] Anatomical Region Char --ANTREG Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The SDTM variable --ANTREG is defined as a variable qualifier of the SDTM variable --SPEC.
Findings N/A 25 -- SPCCND Specimen Condition The condition of the specimen. What [is/was] the condition of the specimen? Specimen Condition Char --SPCCND Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (SPECCOND) Standardized text describing the condition of the sample (e.g., Hemolyzed, Lipemic).
Findings N/A 26 -- CSPUFL Collected Specimen Usability Flag An indication about the usability of the specimen for obtaining the test result. What is/was the usability (of this specimen)?; [Is/Was] the specimen usable? Specimen Usability Char --SPCUFL This does not map directly to an SDTM variable. For the SDTM dataset, if the CDASH variable - -CSPUFL= "Y", the value of the STDM variable --CSPUFL is "Y". If CSPULF= "N", --CSPULF is null. (NY) N/A
Findings N/A 27 --POS Position of Subject During Observation The position of the subject during a measurement or examination. In what position was the subject during the [measurement/test/examination/question/assessm ent/specimen collection/sample collection]?; What was the position of the subject (during the [measurement/test/examination/question/assessm ent/specimen collection/sample collection])? Position Char --POS Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (POSITION) Note: CDISC Controlled Terminology (VSPOS) is used in the VS domain.
Findings N/A 28 --LOC Location Used for the Measurement The anatomical location of the subject relevant to the collection of the measurement. What [is/was] the anatomical location (of the [measurement/test/examination/question/assessm ent])?; What [is/was] the anatomical location where the [measurement/specimen/question/assessment] was [taken/collected]? Anatomical Location Char --LOC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LOC) This may be pre-printed or collected. -- LOC is used only to specify the anatomical location. --LAT, --DIR, -- PORTOT are used to further describe the anatomical location.
Findings N/A 29 --LAT Laterality 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/question/assessm ent])? Side Char --LAT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (LAT) Further detailing the laterality of the location of the --TEST. This may be pre- printed or collected.
Findings N/A 30 --DIR 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/question/assessm ent])? Directionality Char --DIR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (DIR) Further detailing the directionality of the location of the --TEST (e.g., ANTERIOR, LOWER, PROXIMAL). This may be pre- printed or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Findings N/A 31 -- LOCDTL Location Detail A detail description of the location of the identified finding. What [were/are] additional details on the exact location of the [finding] so that it can be distinguished from other [findings] in the same anatomical location? [Finding] Location Detail Char SUPP-- .QVAL This does not map directly to an SDTM variable. This information could be submitted in a SUPP-- dataset as the value of SUPP-- .QVAL where SUPP--.QNAM="-- LOCDTL" and SUPP-- .QLABEL= "Location Detail". N/A Use if --LOC and --LAT and/or --DIR values cannot provide uniqueness from other identified findings. --LOCDTL is not meant to replace --LOC, --LAT, and/or -- DIR or serve as the free-text description field for --LOC (e.g., Location, Other).
Findings N/A 32 -- PORTOT 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/question/assessm ent])? Portion or Totality Char --PORTOT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (PORTOT) Further detailing the portion or totality of the location of the --TEST. This may be pre-printed or collected.
Findings N/A 33 -- METHOD Method of Test or Examination The method of the test or examination. What was the method (used for the [measurement/test/examination/question/assessm ent])?; What was the method (used to [measure/test/examine/question/assess/evaluate/i dentify] the [finding])? Method Char --METHOD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (METHOD) Note: CDISC Controlled Terminology (EGMETHOD) is used in the EG domain.
Findings N/A 34 --LEAD Lead Identified to Collect Measurements 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/question/assessm ent])? Lead Char --LEAD Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Note: CDISC Controlled Terminology (EGLEAD) is used in the EG domain.
Findings N/A 35 -- CSTATE Consciousness State The consciousness state of the subject at the time of measurement. What [is/was] the consciousness state of the subject (at the time of the [measurement/test/examination/question/assessm ent])? Consciousness State Char --CSTATE Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Findings N/A 36 --FAST 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 --FAST Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) N/A
Findings N/A 37 --EVAL Evaluator The role of the person who provided the evaluation. Who provided the (sponsor-defined phrase) information?; Who was the evaluator? [Evaluator/Reporter] Char --EVAL Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (EVAL) Used only for results that are subjective (e.g., assigned by a person or a group). May be a pre-printed, or collected. Sponsors may collect the data using a subset list of CT on the CRF.
Findings N/A 38 --EVALID Evaluator Identifier An identifier used to distinguish multiple evaluators with the same role recorded in - -EVAL. What [is/was] the identifier of the [evaluator name/reporter name] (providing the-sponsor- defined phrase- information)? [Evaluator/Reporter] Identifier Char --EVALID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (MEDEVAL) N/A
Findings N/A 39 -- ACPTFL Accepted Record Flag An indication that the evaluation is considered, by an independent assessor, to be the accepted or final evaluation. [Is/Was] this record considered to be the [accepted/final] evaluation? [Accepted/Final] Evaluation Char --ACPTFL Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) Used where more than one assessor provides an evaluation of a result or response. Typically a check box with the value of "Y" or "NULL" which indicates the evaluation was accepted.
Findings N/A 40 --TOX Toxicity The description of toxicity quantified by -- TOXGR such as NCI CTCAE Short Name. What [is/was] the description of the [NCI CTCAE/scale name] toxicity? [NCI CTCAE/Scale Name ] Toxicity Char --TOX Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor may choose to not collect -- TOX. If collected, sponsors should specify which scale and version is used in the Sponsor Comments column of the Define-XML document.
Findings N/A 41 --TOXGR Toxicity Grade The toxicity grade using a standard toxicity scale (such as the NCI CTCAE). What [is/was] the [NCI CTCAE Toxicity/scale name] grade? [NCI CTCAE Toxicity/scale name] Grade Char --TOXGR Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Sponsor may choose to not collect -- TOXGR. If collected, sponsors should specify which scale and version is used in the Sponsor Comments column of the Define- XML document. Note: CDISC Controlled Terminology (TOXGRV3) or (TOXGRV4) may be used for this variable
Findings N/A 42 --SEV Severity The severity or intensity of a particular finding. What [is/was] the severity (of the finding)? Severity Char --SEV Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Findings N/A 43 -- DTHREL Relationship to Death An indication of the relationship of a particular finding to the death of a subject. [Is/Was] this findings related to the death of the subject? Related to Death Char --DTHREL Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (NY) N/A
Findings N/A 44 --CLLOQ Collected Lower Limit of Quantitation The collected lower limit of quantitation for an assay, represented in text format or as a range, such as less than a specified numeric value. What [is/was] the lower limit of quantification (for the [measurement/test/examination])? Lower Limit of Quantification Num --LLOQ This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable, -- CLLOQ maps to the SDTM variable --LLOQ. The units will be those used for --STRESU. N/A These data may be obtained directly from the lab or the electronic equipment and not collected on the CRF. The units are those used for the SDTM variable -- STRESU. This is not the lower limit of normal of the reference range for the test. The SDTM variable --LLOQ must be populated as a numeric.
Findings N/A 45 --CULOQ Collected Upper Limit of Quantitation The collected upper limit of quantitation for an assay, represented in text format or as a range, such as greater than a specified numeric value. What [is/was] the upper limit of quantification (for the [measurement/test/examination])? Upper Limit of Quantification Num --ULOQ This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable, -- CULOQ maps to the SDTM variable --ULOQ. The units will be those used for --STRESU. N/A These data may be obtained directly from the lab or the electronic equipment and not collected on the CRF. The units are those used for the SDTM variable -- STRESU. This is not the upper limit of normal of the reference range for the test. The SDTM variable --ULOQ must be populated as a numeric.
Findings N/A 46 --COND Test Condition Met An indication whether the testing conditions defined in the protocol were met (e.g., Low fat diet). [Are/Were] the protocol-defined testing conditions met? Defined Testing Condition Met Char SUPP-- .QVAL This information could be submitted in a SUPP--dataset as the value of SUPP--.QVAL when SUPP--.QNAM = --COND and SUPP.QLABEL=" Test Condition Met". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (NY) N/A
Findings N/A 47 --CLSIG Clinical Significance An indication whether the test results were clinically significant. [Is/Was] the ([measurement/test/examination/question/assess ment]) result clinically significant? ([Measurement/Test/Examination/])/Clinically Significant Char SUPP-- .QVAL This information could be submitted in a SUPP--dataset as the value of SUPP--.QVAL when SUPP--.QNAM = "CLSIG" and SUPP--.QLABEL = "Clinical Significance". Refer to the current SDTM and SDTMIG for instructions on placement of non-standard variables in SDTM domains. (NY) N/A
Findings N/A 48 -- REPNUM 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 or within a visit. What was the repetition number within (the) [time point/visit/timeframe] (for this [measurement/test/examination/question/assessm ent])? Repetition Number within (the) [time point/visit/timeframe] Char SUPP-- .QVAL This does not map directly to an SDTM variable. This information could be submitted in a SUPP-- dataset as the value of SUPP-- .QVAL where SUPP--.QNAM = "--REPNUM" and SUPP-- .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 The repetition number of the test/measurement within the time point may be pre-printed on the CRF, e.g., multiple measurements of blood pressure or multiple analyses of a sample.
Findings N/A 49 --DATFL Same as Previous Sample Collection Date A flag indicating that the date (or start date) is the same as the previous specimen collection date (or start date). [Is/Was] this specimen/sample collected on the same date as the (last/previous specimen/sample) (collected/collection ended)? Same as ([Last/Previous]) ([Specimen/Sample]) ([Collection/Collection End]) Date Char N/A Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED. N/A When a series of specimen are recorded on a single CRF 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). Usually a Checkbox, or tick box on the CRF. This would typically be used in the PC domain.
Findings N/A 50 -- ENDATF Same as Current Sample Collection Start Date A flag indicating that the specimen/sample collection ended on the same date as the current/previous specimen collection started. [Is/Was] this specimen/sample collection ended on the same day as the current specimen's/sample's start date? Same as Current (Specimen's/Sample Collection) Start Date Char N/A Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED. N/A When a series of interval sample/specimen collections are recorded on a single CRF form, this field is tied to the start of the current collection to allow for the flag to be used as a surrogate for the date field. Its selection means that the end date of this specimen/sample collection is the same as the start date of the current specimen/sample collected. Usually a Checkbox, or tick box on the CRF. This would typically be used in the PC domain.
Findings N/A 51 COVAL Comment A free text comment. [Protocol-specified Targeted Question]? [abbreviated version of the protocol-specified targeted question] Char CO.COVAL This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable -- COVAL maps to the SDTM variable COVAL (COVAL2, COVAL3) in the CO domain. Associate the free text comment in the CO domain with the original record using RDOMAIN, IDVAR, IDVARVAL, COREF. N/A If an additional free text field is needed to provide a comment about a particular record, use the COVAL(n) field to collect the free text, and associate the free text comment with the original record using SDTM variables RDOMAIN, IDVAR, IDVARVAL, COREF. See the SDTMIG Section 5 for more information.
Findings N/A 52 -- MODIFY Modified Term If the value for -- ORRES is modified for coding purposes, then the modified text is placed here. N/A N/A Char --MODIFY Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This is not a data collection fieldthat will appear on the CRF itself. Sponsors will populate this through the coding process. Rationale for adding coding variables to CDASH is to provide a more complete Data Management package.
Findings N/A 53 -- BODSYS 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 --BODSYS Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A --BODSYS should be assigned using a coding system. If included on the CRF, it is prepopulated and must be paired by the sponsor with specific pre-specified verbatim terms. If not included on the CRF, --BODSYS is assigned through the coding process.

2.4 Special Purpose

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
Special- Purpose CO 1 COVAL Comment A free text comment. [Protocol -specified Targeted Question]? [abbreviated version of the protocol- specified targeted question] Char CO.COVAL This does not map directly to an SDTM variable. For the SDTM dataset, the CDASH variable COVAL maps to the SDTM variable COVAL (COVAL2, COVAL3) in the CO domain. Associate the free text comment in the CO domain with the original record using RDOMAIN, IDVAR, IDVARVAL, COREF. N/A If an additional free text field is needed to provide a comment about a particular record, use the COVAL(n) field to collect the free text, and associate the free text comment with the original record using SDTM variables RDOMAIN, IDVAR, IDVARVAL, COREF. See the SDTMIG for more information.
Special- Purpose DM 1 SITEID Study Site Identifier Unique identifier for a site within a study. What is the site identifier? Site Identifier Char SITEID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Special- Purpose DM 2 INVID Investigator Identifier An identifier to describe the Investigator for the study. May be used in addition to SITEID. Not needed if SITEID is equivalent to INVID. What is the investigator identifier? Investigator Identifier Char INVID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Special- Purpose DM 3 INVNAM Investigator Name The name of investigator for a site. What is the investigator's name? Investigator Name Char INVNAM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Special- Purpose DM 4 RFICDAT Informed Consent Date The date the informed consent is signed in an unambiguous date format. What date did the subject sign informed consent? Informed Consent Date Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 5 RFICDD Informed Consent Day Day informed consent signed in an unambiguous date format. (e.g., DD). What day did the subject sign informed consent? Informed Consent Day Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 6 RFICMO Informed Consent Month Month informed consent signed in an unambiguous date format. (e.g., MON). What month did the subject sign informed consent? Informed Consent Month Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 7 RFICYY Informed Consent Year Year informed consent signed in an unambiguous date format (e.g., YYYY). What year did the subject sign informed consent? Informed Consent Year Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 8 RFICTIM Informed Consent Time Time informed consent signed in an unambiguous date format (e.g., hh:mm). What time did the subject sign informed consent? Informed Consent Time Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 9 RFICHR Informed Consent Hour Hour informed consent signed in an unambiguous time format (e.g., hh). What hour did the subject sign informed consent? Informed Consent Hour Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 10 RFICMI Informed Consent Minute Minute informed consent signed in an unambiguous time format (e.g., mm). What minute did the subject sign informed consent? Informed Consent Minute Char RFICDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable RFICDTC in ISO 8601 format. N/A This will be the same information on informed consent used in the SDTM Disposition Domain
Special- Purpose DM 11 BRTHDAT Birth Date A subject's date of birth (with or without the time of birth). The complete Date of Birth is made from the temporal components of Birth Year, Birth Month, Birth Day and Birth Time. What [is/was] the subject's date of birth? Birth Date Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 12 BRTHDD Birth Day Day of birth of the subject in an unambiguous date format (e.g., DD). What [is/was] the subject's day of birth? Birth Day Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 13 BRTHMO Birth Month Month of birth of the subject in an unambiguous date format (e.g., MMM). What [is/was] the subject's month of birth? Birth Month Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 14 BRTHYY Birth Year The year of birth of the subject in an unambiguous date format (e.g., YYYY). What [is/was] the subject's year of birth? Birth Year Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 15 BRTHTIM Birth Time The time of birth of the subject in an unambiguous time format (e.g., hh:mm). What [is/was] the subject's time of birth? Birth Time Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 16 BRTHHR Birth Hour The hour of birth of the subject in an unambiguous time format (e.g., hh). What [is/was] the subject's hour of birth? Birth Hour Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 17 BRTHMI Birth Minute The minute of birth of the subject in an unambiguous time format (e.g., mm). What [is/was] the subject's minute of birth? Birth Minute Char BRTHDTC This does not map directly to an SDTM variable. For the SDTM submission dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable BRTHDTC in ISO 8601 format. N/A N/A
Special- Purpose DM 18 AGE Age The age of the subject expressed in AGEU. What [is/was] the subject's age? Age Num AGE Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A If Age is collected, it should be collected as a number and, to be correctly interpreted, the age value should be associated to a variable for the Age Unit. It may be necessary to know when the age was collected as an age may need to be recalculated for analysis, such as deriving age at a reference start time (RFSTDTC for SDTM). BRTHDTC may not be available in all cases (due to subject privacy concerns). If AGE is collected, then it is recommended that the date of collection also be recorded, either separately or by association to the date of the visit.
Special- Purpose DM 19 AGEU Age Units Those units of time that are routinely used to express the age of a person. What [is/was] the age unit used? Age Unit Char AGEU Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (AGEU) If Age is captured on the CRF, the age unit must be known to make the age value meaningful. The age unit might be collected on the CRF, in those cases where the protocol allows for any age group, or it may be pre-printed on the CRF (typically with the unit of "years").
Special- Purpose DM 20 SEX Sex Sex of the subject as determined by the investigator. What [is/was] the sex of the subject? Sex Char SEX Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (SEX) Collect the subject's sex or gender, as reported by the investigator. This is a phenotypic assessment and not a genotypic assessment.
Special- Purpose DM 21 RACE Race An arbitrary classification based on physical characteristics; a group of persons related by common descent or heredity (U.S. Center for Disease Control). Which of the following five racial designations best describes you? (More than one choice is acceptable.) Race Char RACE Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (RACE) Use RACE when the five designations for race used by the FDA are collected (American Indian or Alaska Native; Asian; Black or African American*; Native Hawaiian or Other Pacific Islander; White). *For studies where data are collected outside the US, the recommended categories are the same except for Black instead of Black or African American. If multiple races are collected, an alternate sponsor-defined variable structure would be required. Sponsors may record multiple self-reported races for a subject by appending a suffix to denote multiple collected races (e.g., RACE1, RACE2) and populate RACE with the value MULTIPLE. Sponsors should refer to the "Collection of Race and Ethnicity Data in Clinical Trials" (FDA, September 2016). See the SDTMIG Section 5-DM Domain.
Special- Purpose DM 22 CRACE Collected Race An arbitrary classification based on physical characteristics; a group of persons related by common descent or heredity (U.S. Center for Disease Control). Which of the following racial designations best describes you? (More than one choice is acceptable.) 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 when SUPPDM.QNAM = "CRACE" and SUPPDM.QLABEL="Collected Race".See the SDTMIG Section for the DM Domain. (RACEC) Use CRACE when more detailed race categorizations are desired (e.g., more than the five minimum designations for race used by the FDA). The use of race and vocabulary tables located within Health Level Seven's Reference Information Model Structural Vocabulary Tables is recommended, as they are designed to collapse up to the SDTM variable RACE with CT (e.g., American Indian or Alaska Native Asian; Black or African American*; Native Hawaiian or Other Pacific Islander; White ). *For studies where data are collected outside the US, the recommended categories are the same except for Black instead of Black or African American. If multiple races are collected, an alternate sponsor- defined variable structure would be required. Sponsors may record multiple self- reported races for a subject by appending a suffix to denote multiple collected races (e.g., CRACE1, CRACE2) and populate CRACE with the value MULTIPLE. If sponsors choose to map the extended Race codelist values to the RACE CT (e.g., Japanese to Asian ), then this mapped variable would be reported using the SDTMIG variable RACE. Sponsors should refer to the "Collection of Race and Ethnicity Data in Clinical Trials" (FDA, September 2016).
Special- Purpose DM 23 ETHNIC Ethnicity A social group characterized by a distinctive social and cultural tradition maintained from generation to generation, a common history and origin and a sense of identification with the group; members of the group have distinctive features in their way of life, shared experiences and often a common genetic heritage; these features may be reflected in their experience of health and disease. Do you consider yourself Hispanic/Latino or not Hispanic/Latino? Ethnicity Char ETHNIC Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (ETHNIC) For use when values are being collected using the exact non-extensible ETHNIC codelist (C66790) values. Sponsors should refer to "Collection of Race and Ethnicity Data in Clinical Trials" (FDA, September 2016) for guidance regarding the collection of ethnicity (http://www.fda.gov/ucm/groups/fdagov- public/@fdagov-afda-gen/documents/document/ucm126396.pdf) 
Special- Purpose DM 24 CETHNIC Collected Ethnicity A social group characterized by a distinctive social and cultural tradition that is maintained from generation to generation. Members share a common history and origin and a sense of identification with the group. They have similar and distinctive features in their lifestyle habits and shared experiences. They often have a common genetic heritage which may be reflected in their experience of health and disease. When submitting to the FDA, the collected values must be rolled up to the permissible values in ETHNIC. What [is/was] the ethnicity of the subject? Ethnicity Char SUPPDM.QVAL This information could be submitted in a SUPPDM dataset as the value of SUPPDM.QVAL when SUPPDM.QNAM = "CETHNIC" and SUPPDM.QLABEL = "Collected Ethnicity". Refer to the current SDTM and SDTMIG for instructions on placement of non- standard variables in SDTM domains. (ETHNICC) Use when values are collected using the NCI Thesaurus codelist for Ethnicity As Collected (C128690), the extended HL7 hierarchy of codelist values, or other Regulatory Agency specific controlled terminology for Ethnic Group. Sponsors may append a suffix to denote multiple collected ethnicities (e.g., CETHNIC1, CETHNIC2).
Special- Purpose DM 25 AGETXT Age Text The age of the subject at study start expressed as an range. What [is/was] the subject's age (range)? Age (Range) Char AGETXT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A If an numeric age value is available, then populate the AGE variable instead. Either the AGE or AGETXT field should be populated, not both. See the CDASHIG for more information.
Special- Purpose DM 26 CAGETXT Collected Age Text The age of the subject at study start expressed as descriptive text and not a range. What [is/was] the subject's age (description)? Age (Description) Char AGETXT; SUPPDM.QVAL If the collected value is a range, then the result maps directly to AGETXT. If the collected is value is a description, the result maps to SUPPDM.QVAL where SUPPDM.QNAM = "CAGETXT" and SUPPDM.QLABEL = "Collected Age Text". N/A If only collected age ranges (e.g., 0-3, 18 -25, >65) are expected, those should be collected using AGETXT. If collecting age descriptions (e.g., Neonate, Adolescent, Adult), those must be collected using CAGETXT.

2.5 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 T aken 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 T aken 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 n 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.

2.6 Identifiers

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
Identifiers N/A 1 SPONSOR Sponsor An identifier for the entity with the overall regulatory responsibility for the Protocol. What is the sponsor identifier? Sponsor Char TSVAL For the SDTM dataset, the value in the CDASH field SPONSOR maps to the SDTM variable TSVAL. The SDTM variable TSPARMCD is populated with "SPONSOR" and the SDTM variable TSPARM is populated with "Clinical Study Sponsor". N/A In some cases, the combination of Sponsor ID with Study ID and Site ID might be needed by external parties (e.g., CRO or for a multi-sponsor study) to uniquely identify sites belonging to the study for the given sponsor.
Identifiers N/A 2 DOMAIN Domain Abbreviation A two-character abbreviation for the domain most relevant to the observation. N/A N/A Char DOMAIN Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (DOMAIN) This field can be derived into the database or created during SDTM dataset creation before submission. The Domain abbreviation is also used as a prefix for variables to ensure uniqueness when datasets are merged.
Identifiers N/A 3 STUDYID Study Identifier A unique identifier for a study. What [is/was] the study identifier? [Protocol/Study] Char STUDYID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". 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.
Identifiers N/A 4 SITEID Study Site Identifier A unique identifier for a site within a study. What [is/was] the site identifier? Site (Identifier) Char DM.SITEID For the SDTM dataset, the value in the CDASH field SITEID maps to the SDTM variable DM.SITEID. 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.
Identifiers N/A 5 INVID Investigator Identifier An identifier to describe the Investigator for the study. What [is/was] the investigator identifier? Investigator (Identifier) Char DM.INVID For the SDTM dataset, the value in the CDASH field SITEID maps to the SDTM variable DM.INVID. N/A May be used in addition to the SITEID. Not needed if SITEID is equivalent to INVID.
Identifiers N/A 6 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 DM.SUBJID For the SDTM dataset, the value in the CDASH field SUBJID maps to the SDTM variable DM.SUBJID. N/A This CDASH variable is typically collected in all CDASH domains. However, this CDASH variable is populated only in the SDTMIG DM domain. The recording of multiple SUBJID for the same subject is a known SDTM issue. If a subject is screened more than once, there may be more than one SUBJID per instance of being screened within the trial. Refer to FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.2.
Identifiers N/A 7 FOCID Focus of Study Specific Interest An identifier used for the identification of a focus of study-specific interest on or within a subject or specimen as described in the protocol for which a measurement, test, or examination was performed, such as a drug application site, e.g., "Injection site 1", "Biopsy site 1", "Treated site 1", or a more specific focus, e.g., "OD" (right eye) or "Upper left quadrant of the back". The value in this variable should have inherent semantic meaning. [Protocol specific question]? [Protocol Specific Prompt] Char FOCID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This SDTM variable has been defined in SDTM 1.5, but was not included in SDTMIG 3.2. Sponsors should consider the SDTM version being used when the submission datasets are created. In pre SDTM 1.5, the CDASH to SDTM mapping may need to be defined by the sponsor because FOCID is not a valid SDTM variable in these versions.
Identifiers N/A 8 --SPID Sponsor- Defined Identifier A sponsor-defined identifier. In CDASH, This is typically used for pre- printed 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 --SPID 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 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 pre-printed number (e.g., line number, record number) on the CRF. This field may be populated by the sponsor's data collection system.
Identifiers N/A 9 --GRPID 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 --GRPID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Used to link together a block of related records in a single domain for a subject. This group identifier may be used to tie together all the tests collected in a Findings domain using a de-normalized approach (See CDASHIG Section 8.3 - General CDASH Assumptions for Findings Domains). This field may be populated by the sponsor's data management system.
Identifiers N/A 10 --LNKID Link ID An identifier used to link related records across domains. What [is/was] the [test/procedure/observation] identifier? [Domain/Observation] Link Identifier Char --LNKID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This may be a one-to- one or a one-to- many relationship. For Example: A single tumor may have multiple measurements/assessments performed at each study visit.
Identifiers N/A 11 --LNKGRP An identifier used to link related records across domains. What [is/was] the [domain/observation] link group ID? [Domain/Observation] Link Group Identifier Char --LNKGRP Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This will usually be a many-to-one relationship. For example: Multiple tumor measurements/assessments will contribute to a single response to therapy determination record.
Identifiers N/A 12 --REFID Reference ID An internal or external identifier such as lab specimen ID, or UUID for an ECG waveform or a medical image. What [is/was] the [test/procedure/domain/observation/specimen/sample/report] [reference identifier/accession number/identifier]? [Test/Procedure/Domain/Observation/Specimen/Sample/ Report] [Reference/Accession Number/Identifier] Char --REFID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A N/A
Identifiers N/A 13 --AENO Related Adverse Event ID A numerical identifier for the adverse event that is associated with/related to this intervention/finding/event. What [is/was] the identifier for the adverse event(s) [associated with/related to this intervention/finding/event]? Related Adverse Event Identifier Char N/A This does not map directly to an SDTM variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the associated Adverse Experience domain. N/A Name of the identifying variable is stored in the SDTM variable IDVAR (e.g., -- AENO) and the value of the SDTM variable IDVAR is stored in SDTM variable IDVARVAL. Example question text: What was the identifier for the adverse event associated with this concomitant medication?
Identifiers N/A 14 --MHNO Related Medical History Event ID A numerical identifier for the medical history event that is associated with/related to this intervention/finding/event. What [is/was] the identifier for the medical history event(s) [associated with/related to this intervention/finding/event]? Related Medical History Event Identifier Char N/A This does not map directly to an SDTM variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the associated Medical History domain. N/A Name of the identifying variable is stored as a value in the SDTM variable IDVAR (e.g., "--MHNO") and the value of the IDVAR is stored in the STDM variable IDVARVAL. Example question text prompt: What was the identifier for the medical history event associated with this concomitant medication?
Identifiers N/A 15 --PRNO Related Procedure ID A numerical identifier for the procedure that is associated with/related to this intervention/finding/event. What [is/was] the identifier for the procedure(s) [associated with/related to this intervention/finding/event]? Related Procedure Identifier Char N/A This does not map directly to an SDTM variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the associated Procedures domain. N/A Name of the identifying variable is stored as a value in the SDTM variable IDVAR (e.g., "--PRNO") and the value of the IDVAR is stored in the SDTM variable IDVARVAL. Example question text for an Adverse Event CRF: What was the identifier for the procedure associated with this adverse event?
Identifiers N/A 16 --CENO Related Clinical Event ID A numerical identifier for the clinical event that is associated with/related to this intervention/finding/event. What [is/was] the identifier for the clinical event(s) [associated with/related to this intervention/finding/event]? Related Clinical Event Identifier Char N/A This does not map directly to an SDTM variable. For the SDTM submission datasets, may be used to create RELREC to link this record with a record in the associated Clinical Events domain. N/A Name of the identifying variable is stored as a value in the SDTM variable IDVAR ("- -CENO") and the value of the IDVAR is stored in the SDTM variable IDVARVAL Example question text: What was the identifier for the clinical event associated with this procedure?
Identifiers N/A 17 SPDEVID Sponsor Device Identifier A sponsor-defined identifier for a device. What [is/was] the sponsor identifier for the device? Sponsor Device Identifier Char SPDEVID Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A SPDEVID is a constructed variable consisting of elements that may not be available at the time of data capture, such as device type, manufacturer, and other elements. Other device identifiers, such as serial number, may instead be used on the CRF. If this is the case, sponsors should use the controlled terminology for the SPDEVID elements as variable names where possible. Sponsors should also ensure that, when necessary, those elements required for deriving SPDEVID are captured.

2.7 Timing

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
Timing N/A 1 VISITNUM Visit Number Clinical encounter number. Numeric version of VISIT can be used for sorting. What is the visit number? Visit Number Num VISITNUM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A This is not a data collection field that will appear on the CRF itself. This field may be populated by the sponsor's data collection system or derived from the variable VISIT. 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.
Timing N/A 2 VISIT Visit Name Protocol-defined description of the clinical encounter. May be used in addition to VISITNUM and/or VISITDY as a text description of the clinical encounter. What [is/was] the visit name? [Visit] Char VISIT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The name of the visit is typically pre- printed 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.
Timing N/A 3 VISDAT Visit Date Date the clinical encounter occurred (or started). What [is/was] the date of the visit? (Visit) Date Char N/A This field does not map directly to an SDTM variable. For the SDTMIG SV dataset, the SDTMIG variable SVSTDTC may be derived by concatenating all collected CDASH VISDAT and VISTIM components and populating the SDTM variable SVSTDTC in ISO 8601 format. N/A This may be recorded in either the header of the CRF or in the body of the CRF. A date/time can be collected once for the whole visit using the Visit Date/Time field and applying that date/time to all of the observations at that visit. The date (--DTC) 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 STDMIG variable --DTC in ISO 8601 format.
Timing N/A 4 VISTIM Visit Time Time the clinical encounter took place (or started). What [is/was] the (start) time of the visit? (Visit) Time Char N/A This field does not map directly to an SDTM variable. For the SDTMIG SV dataset, the SDTMIG variable SVSTDTC may be derived by concatenating all collected CDASH VISDAT and VISTIM components and populating the SDTM variable SVSTDTC in ISO 8601 format. N/A This may be recorded in either the header of the CRF or in the body of the CRF. A date/time can be collected once for the whole visit using the Visit Date/Time field and applying that date/time to all of the observations at that visit. The date (--DTC) of a measurement, test, observation can be determined from the date/time of visit (VISDAT/VISTIM). For the SDTM submission datasets, concatenate CDASH VISDAT/VISTIM components, and populate the STDMIG variable -- DTC in ISO 8601 format. May be used to populate SVSTDTC, and SVENDTC in the SDTMIG SV domain.
Timing N/A 5 VISENDAT Visit End Date Date the clinical encounter ended. What [is/was] the end date of the visit? (Visit) End Date Char N/A This field does not map directly to an SDTM variable. For the SDTM SV dataset, the SDTMIG variable SVENDTC may be derived by concatenating all collected CDASH VISENDAT and VISENTIM components and populating the SDTM variable SVENDTC in ISO 8601 format. N/A This may be recorded in either the header of the CRF or in the body of the CRF. This is the end date of the visit. This may be useful when a study extends over 2 or more days.
Timing N/A 6 VISENTIM Visit End Time Time the clinical encounter ended. What [is/was] the end time of the visit? (Visit) End Time Char N/A This field does not map directly to an SDTM variable. For the SDTM SV dataset, the SDTMIG variable SVENDTC may be derived by concatenating all collected CDASH VISENDAT and VISENTIM components and populating the SDTM variable SVENDTC in ISO 8601 format. N/A This may be recorded in either the header of the CRF or in the body of the CRF. This is the end time of the visit.This may be useful when a study extends over 2 or more days.
Timing N/A 7 EPOCH Epoch Name of the Trial Epoch with which this Element of the Arm is associated. What [is/was] the [study/trial] [period/phase/sponsor- defined phrase] (for this [event/intervention/finding])? [Study/Trial] Period Char EPOCH Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". (EPOCH) 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 pre-printed on the CRF as the title of the page. See SDTMIG for further information regarding EPOCH.
Timing N/A 8 --DAT Collection Date Collection date of an observation. What [is/was] the date the [event or intervention] [is/was] collected?; What [is/was] the (start) date (of the [Finding])? [Event/Intervention] Collection Date; [Finding] (Start) Date Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic DATE field that can be implemented in a system that will store partial dates. Use this for: 1. Date of data collection, 2. Visit date, 3. Visit start date, 4. Point in time collection (e.g., vital signs measurements, lab sample collection date), 5. Start date for interval collection of measurements or tests (e.g., start date of a 24-hour urine collection). Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) are included in the SDTM
Timing N/A 9 --DATDD Collection Day Collection day of an observation. What [is/was] the day the [event or intervention] [is/was] collected?; What [is/was] was the (start) day (of the [Finding])? [Event/Intervention] Collection Day; [Finding] (Start) Day Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic DAY (DD) field that can be implemented in a system that will not store partial dates. Use this for: 1. Date of data collection, 2. Visit date, 3. Visit start date, 4. Point in time collection (e.g., vital signs measurements, lab sample collection date), 5. Start date for interval collection of measurements or tests (e.g., start date of a 24-hour urine collection)
Timing N/A 10 --DATMO Collection Month Collection month of an observation. What [is/was] the month the [event or Intervention] [is/was] collected?; What [is/was] the (start) month (of the [Finding])? [Event/Intervention] Collection Month; [Finding] (Start) Month Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic MONTH (MO) field that can be implemented in a system that will not store partial dates. Use this for: 1. Date of data collection, 2. Visit date, 3. Visit start date, 4. Point in time collection (e.g., vital signs measurements, lab sample collection date), 5. Start date for interval collection of measurements or tests (e.g., start date of a 24-hour urine collection)
Timing N/A 11 --DATYY Collection Year Collection year of an observation. What [is/was] the year the [event or intervention] [is/was] collected?; What [is/was] the (start) year (of the [Finding])? [Event/Intervention] Collection Year; [Finding] (Start) Year Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic YEAR (YY) field that can be implemented in a system that will not store partial dates. Use this for: 1. Date of data collection, 2. Visit date, 3. Visit start date, 4. Point in time collection (e.g., vital signs measurements, lab sample collection date), 5. Start date for interval collection of measurements or tests (e.g., start date of a 24-hour urine collection)
Timing N/A 12 --TIM Collection Time Collection time of an observation. What [is/was] the time the [event or intervention] [is/was] collected?; What [is/was] the (start) time (of the [Finding])? [Event/Intervention] Collection Time; [Finding] (Start) Time Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic TIME (TIM) field that can be implemented in a system that will store partial times. Use this for: 1. Time of data collection, 2. Visit time, 3. Visit start time, 4. Point in time collection (e.g., vital signs measurements, lab sample collection time), 5. Start time for interval collection of measurements or tests (e.g., start time of a 24-hour urine collection)
Timing N/A 13 --TIMHR Collection Hour Collection hour of an observation. What [is/was] the hour the [event or intervention] [is/was] collected?; What [is/was] the (start) hour (of the [Finding])? [Event/Intervention] Collection Hour; [Finding] (Start) Hour Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic HOUR (HR) field that can be implemented in a system that will not store partial times. Use this for: 1. Time of data collection, 2. Visit time, 3. Visit start time, 4. Point in time collection (e.g., vital signs measurements, lab sample collection time), 5. Start time for interval collection of measurements or tests (e.g., start time of a 24-hour urine collection)
Timing N/A 14 --TIMMI Collection Minute Collection minute of an observation. What [is/was] the minute the [event or intervention] [is/was] collected?; What [is/was] the (start) minute (of the [Finding])? [Event/Intervention] Collection Minute; [Finding] (Start) Minute Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic MINUTE (MI) field that can be implemented in a system that will not store partial times. Use this for: 1. Time of data collection, 2. Visit time, 3. Visit start time, 4. Point in time collection (e.g., vital signs measurements, lab sample collection time), 5. Start time for interval collection of measurements or tests (e.g., start time of a 24-hour urine collection)
Timing N/A 15 --TIMSS Collection Second Collection second of an observation. What [is/was] the second the [event or intervention] [is/was] collected?; Or What [is/was] the (start) second (of the [Finding])? [Event/Intervention] Collection Second; [Finding] (Start) Second Char --DTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --DTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic SECONDS (SS) field that can be implemented in a system that will not store partial times Use this for: 1. Time of data collection, 2. Visit time, 3. Visit start time, 4. Point in time collection (e.g., vital signs measurements, lab sample collection time), 5. Start time for interval collection of measurements or tests (e.g., start time of a 24-hour urine collection)
Timing N/A 16 --STDAT Observation Start Date Start date of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) date (of the observation)? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/ Admission) Date Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START DATE field that can be implemented in a system that will store partial dates. Use this for: 1. Start date of events or interventions (e.g., AE start date, Substance Use start date), 2. Start date of interval dosing (e.g., date/time of infusion start), 3. Date of Protocol Milestones (e.g., informed consent date), 4. Date of Disposition events (e.g., date of study completion, date of discontinuation)
Timing N/A 17 --STDD Observation Start Day Start day of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) day? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Day Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable--STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START DAY (STDD) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start date of events or interventions (e.g., AE start date, Substance Use start date), 2. Start date of interval dosing (e.g., date/time of infusion start), 3. Date of Protocol Milestones (e.g., informed consent date), 4. Date of Disposition events (e.g., date of study completion, date of discontinuation)
Timing N/A 18 --STMO Observation Start Month Start month of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) month? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Month Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable --STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START MONTH (STMO) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start date of events or interventions (e.g., AE start date, Substance Use start date), 2. Start date of interval dosing (e.g., date/time of infusion start), 3. Date of Protocol Milestones (e.g., informed consent date), 4. Date of Disposition events (e.g., date of study completion, date of discontinuation)
Timing N/A 19 --STYY Observation Start Year Start year of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) year? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Year Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START YEAR (STYY) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start date of events or interventions (e.g., AE start date, Substance Use start date), 2. Start date of interval dosing (e.g., date/time of infusion start), 3. Date of Protocol Milestones (e.g., informed consent date), 4. Date of Disposition events (e.g., date of study completion, date of discontinuation)
Timing N/A 20 --STTIM Observation Start Time Start time of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) time? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Time Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START TIME field that can be implemented in a system that will store partial dates. Use this for: 1. Start time of events or interventions (e.g., AE start time, Substance Use start time), 2. Start time of interval dosing (e.g., time of infusion start), 3. Time of Protocol Milestones (e.g., informed consent time), 4. Time of Disposition events (e.g., Time of study completion, Time of discontinuation)
Timing N/A 21 --STHR Observation Start Hour Start hour of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) hour? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Hour Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START HOUR (STHR) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start time of events or interventions (e.g., AE start time, Substance Use start time), 2. Start time of interval dosing (e.g., time of infusion start), 3. Time of Protocol Milestones (e.g., informed consent time), 4. Time of Disposition events (e.g., Time of study completion, Time of discontinuation)
Timing N/A 22 --STMI Observation Start Minute Start minute of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) minute? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Minute Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START MINUTE (STMI) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start time of events or interventions (e.g., AE start time, Substance Use start time), 2. Start time of interval dosing (e.g., time of infusion start), 3. Time of Protocol Milestones (e.g., informed consent time), 4. Time of Disposition events (e.g., Time of study completion, Time of discontinuation)
Timing N/A 23 --STSS Observation Start Second Start second of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention]) ([MHEVDTYP]/start/admission) second? ([Intended/Planned/Actual]) ([MHEVDTYP]/Start/Admission) Second Char --STDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH START DATE and TIME components and populate the SDTM variable -- STDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, --STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic START SECOND (STSS) field that can be implemented in a system that will not store partial dates. Use this for: 1. Start time of events or interventions (e.g., AE start time, Substance Use start time), 2. Start time of interval dosing (e.g., time of infusion start), 3. Time of Protocol Milestones (e.g., informed consent time), 4. Time of Disposition events (e.g., Time of study completion, Time of discontinuation)
Timing N/A 24 --ENDAT Observation End Date End date of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) date (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Date Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END DATE field that can be implemented in a system that will store partial dates. Use this for: 1. End date of events (e.g., AE end date) or Interventions (e.g., CM end date), 2. End date of interval dosing (e.g., date of infusion end), 3. End visit date, 4. End date for interval collection of measurements or tests (e.g., end date of 24-hour urine collection)
Timing N/A 25 --ENDD Observation End Day End day of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) day (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Day Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END DAY (ENDD) field that can be implemented in a system that will not store partial dates. Use this for: 1. End date of events (e.g., AE end date) or Interventions (e.g., CM end date), 2. End date of interval dosing (e.g., date of infusion end), 3. End visit date, 4. End date for interval collection of measurements or tests (e.g., end date of 24-hour urine collection)
Timing N/A 26 --ENMO Observation End Month End month of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) month (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Month Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END MONTH (ENMO) field that can be implemented in a system that will not store partial dates. Use this for: 1. End date of events (e.g., AE end date) or Interventions (e.g., CM end date), 2. End date of interval dosing (e.g., date of infusion end), 3. End visit date, 4. End date for interval collection of measurements or tests (e.g., end date of 24-hour urine collection)
Timing N/A 27 --ENYY Observation End Year End year of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) year (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Year Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END YEAR (ENYY) field that can be implemented in a system that will not store partial dates. Use this for: 1. End date of events (e.g., AE end date) or Interventions (e.g., CM end date), 2. End date of interval dosing (e.g., date of infusion end), 3. End visit date, 4. End date for interval collection of measurements or tests (e.g., end date of 24-hour urine collection)
Timing N/A 28 --ENTIM Observation End Time End time of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) time (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Time Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END TIME (ENTIM) field that can be implemented in a system that will store partial times. Use this for: 1.End time of events (e.g., AE end time) or Interventions (e.g., CM end time), 2. End time of interval dosing (e.g., time of infusion end), 3. End visit time, 4. End time for interval collection of measurements or tests (e.g., end time of 24-hour urine collection)
Timing N/A 29 --ENHR Observation End Hour End hour of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) hour (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Hour Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END HOUR (ENHR) field that can be implemented in a system that will not store partial times. Use this for: 1.End time of events (e.g., AE end time) or Interventions (e.g., CM end time), 2. End time of interval dosing (e.g., time of infusion end), 3. End visit time, 4. End time for interval collection of measurements or tests (e.g., end time of 24-hour urine collection)
Timing N/A 30 --ENMI Observation End Minute End minute of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) minute (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Minute Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END MINUTE (ENMI) field that can be implemented in a system that will not store partial times. Use this for: 1.End time of events (e.g., AE end time) or Interventions (e.g., CM end time), 2. End time of interval dosing (e.g., time of infusion end), 3. End visit time, 4. End time for interval collection of measurements or tests (e.g., end time of 24-hour urine collection)
Timing N/A 31 --ENSS Observation End Second End second of an observation. What [is/was] the ([intended/planned/actual]) ([event/intervention/finding]) ([end/discharge/stop]) second (of the observation)? ([Intended/Planned/Actual]) ([End/Discharge/Stop]) Second Char --ENDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH End DATE and TIME components and populate the SDTM variable --ENDTC in ISO 8601 format. Refer to the FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015): Section 4.1.4.1 which indicates that when dates have the role of a timing variable, the matching Study Day variables (--DY, -- STDY, or --ENDY, respectively) should be included in the SDTM dataset. N/A This is a generic END SECOND (ENSS) field that can be implemented in a system that will not store partial dates. Use this for: 1.End time of events (e.g., AE end time) or Interventions (e.g., CM end time), 2. End time of interval dosing (e.g., time of infusion end), 3. End visit time, 4. End time for interval collection of measurements or tests (e.g., end time of 24-hour urine collection)
Timing N/A 32 --CDUR Collected Duration Collected duration of an event, intervention, or finding. Used only if collected on the CRF and not derived. What [is/was] the duration of the [event/intervention]? Duration Char --DUR This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate the collected CDASH duration and the CDASH duration unit components and populate the SDTM variable --DUR in ISO 8601 Period format. N/A Used only if collected on the CRF and not derived.
Timing N/A 33 --CDURU Collected Duration Unit The unit of time associated with the collected duration of an event, intervention, or finding. What [is/was] the duration unit of the [event/intervention]? [Duration Unit] Char --DUR This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate the collected CDASH duration and the CDASH duration unit components and populate the SDTM variable --DUR in ISO 8601 Period format. (UNIT) Used only if collected on the CRF and not derived.
Timing N/A 34 --PRIOR Prior An indication whether or not the [event/intervention/finding] started or occurred prior to a specified timepoint. Was the [--TRT/Intervention] [taken/performed/used/administered/consumed/started/ occurred] prior to a [specified timepoint]?; Did the [-- TERM/event topic/--TRT/Intervention/Finding] [start/occur] prior to [specified timepoint]? [T aken/Performed/Used/Administered/Consumed/Started/ Occurred] Prior to a [specified timepoint] Char --STRTPT; -- STRF This does not map directly to an SDTM variable. May be used to populate a value into an SDTM relative timing variable such as --STRF or -- STRTPT. When populating -- STRF, or --STRTPT, if the value of the CDASH field -- PRIOR is "Y" a value from the CDISC CT (STENRF) may be used. When --PRIOR refers to the Study Reference Period (defined in DM.RFSTDTC to DM.RFENDTC) the SDTM variable --STRF should be populated. When --PRIOR is compared to another timepoint, the SDTM variables --STRTPT and --STTPT should be used. Note: -- STRTPT must refer to the time point anchor described in --STTPT. (NY) The CDASH field --PRIOR allows specific question text and prompt about interventions, events or findings that were prior to a specified timepoint. -- PRIOR is used in conjunction with either a reference timepoint (--STTPT, --ENTPT) or the Study Reference Period (described as RFSTDTC to RFENDTC). See the CDASH IG Section 3.7 for more information.
Timing N/A 35 --TPT Planned Time Point Name Text description of time when a measurement or observation should be taken as defined in the protocol. This may be represented as an elapsed time relative to a fixed reference point, such as time of last dose. See --TPTNUM and -- TPTREF. What [is/was] the planned time point [of the/for the] [measurement/observation/collection]? [Planned Time Point Name] Char --TPT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". See SDTMIG for additional information on representing time points. SDTM Time point anchors -- TPTREF (text description) and --RFTDTC (date/time) may be needed, as well as SDTM variables --TPTNUM, -- ELTM. N/A Planned time point names are needed to differentiate multiple sequential assessments. It is recommended that time point names be pre-printed 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. In the SDTM submission dataset, time points can be represented using the time point variables --TPT, --TPTNUM,-- ELTM. See SDTMIG Section 4.1.4.10.
Timing N/A 36 --TPTNUM Planned Time Point Number Numeric version of planned time point used in sorting. What [is/was] the planned time point number [of the/for the] [measurement/observation/collection]? [Planned Time Point Number] Num --TPTNUM Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". See SDTMIG for additional information on representing time points. SDTM Time point anchors -- TPTREF (text description) and --RFTDTC (date/time) may be needed, as well as SDTM variables --TPTNUM, -- ELTM. N/A Planned time point numbers may be needed to differentiate multiple sequential assessments. If collected, it is recommended that time point numbers pre-printed on the CRF. In the SDTM submission dataset, time points can be represented using the time point variables --TPT, --TPTNUM,-- ELTM. See SDTMIG Section 4.1.4.10
Timing N/A 37 --TPTREF Time Point Reference Description of the fixed reference point referred to by --ELTM, --TPTNUM, and --TPT. What is the description of the fixed reference point? [Reference Time Point] Char --TPTREF Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A Planned reference point referred to by time point variables --TPT, TPTNUM, -- ELTM. See SDTMIG Section 4.1.4.10 . This would most commonly be pre- specified on the CRF, and not a question to which the site would provide an answer.
Timing N/A 38 --RFTDAT Reference Time Point Date Date for a fixed reference time point defined by -- TPTREF. What was the date of the [Reference Time point]? [Reference Time point] Char --RFTDTC This field does not map directly to an SDTM variable. For the SDTM dataset, the SDTMIG variable --RFTDTC is derived by concatenating all collected CDASH --RFTDAT, and --RFTTIM components and populating the SDTM variable --RFTDTC in ISO 8601 format. N/A Date of the fix reference time point defined by --TPTREF.
Timing N/A 39 --RFTTIM Reference Time Point Time Time for a fixed reference time point defined by -- TPTREF. What was the time of the [Reference Time point]? [Reference Time point] Char --RFTDTC This field does not map directly to an SDTM variable. For the SDTM dataset, the SDTMIG variable --RFTDTC is derived by concatenating all collected CDASH --RFTDAT, and --RFTTIM components and populating the SDTM variable --RFTDTC in ISO 8601 format. N/A Time of the fix reference time point defined by --TPTREF.
Timing N/A 40 --CEVINT Collected Evaluation Interval The collected or pre- populated text description of an interval associated with an observation such as a finding --TESTCD. [Included as part of a protocol specified question] [Evaluation Interval] Char --EVLINT; -- EVINTX This field does not map directly to an SDTM variable. For the SDTM dataset, convert the collect evaluation interval into an ISO 8601 period format and populate the SDTM variable --EVLINT or if the interval can not be converted to an ISO format, populate the SDTM variable -- EVINTX. N/A The CDASH field --CEVINT (which is stored as free text) indicates a period of time during which an observation is being made or about which a question is being asked (e.g., "During the past six months what was the subject average sleep time?" or "Record any significant cardiovascular medical history over the subject lifetime?"). The evaluation interval free text is defaulted in the hidden CDASH field --CEVINT (e.g., PAST 6 MONTHS, LIFETIME). Intervals that can be converted to ISO format (e.g., PAST 6 WEEKS), are mapped to the SDTM variable -- EVLINT (-P6W), and free text interval are mapped to --EVINTX (LIFETIME). See the SDTMIG Section 4.1.4.3.
Timing N/A 41 --EVLINT Evaluation Interval Duration of interval associated with an observation such as a finding --TESTCD. N/A N/A Char --EVLINT Maps directly to the SDTM variable listed in the column with the heading "SDTM Target". N/A The CDASH field --EVLINT indicates a period of time during which an observation is being made or about which a question is being asked which is represented in an ISO format. This would be a hidden field on the CRF or screen, not a question to which the site would provide an answer. The evaluation interval is included in the question text and a hidden CDASH field --EVLINT is defaulted using the appropriate ISO format for the interval (e.g., "During the past six months what was the subject's average sleep time?" is the question text and the hidden CDASH field --EVLINT would be "- P6M".) See the SDTMIG Section 4.1.4.3.
Timing N/A 42 DTHDAT Death Date Date of death for any subject who died. What [is/was] the subject's date of death? Death Date Char DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It 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 SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 43 DTHDD Death Day Day of death for any subject who died. What [is/was] the subject's day of death? Death Day Char DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 44 DTHMO Death Month Month of death for any subject who died. What [is/was] the subject's month of death? Death Month Char DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 45 DTHYY Death Year Year of death for any subject who died. What [is/was] the subject's year of death? Death Year Char DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 46 DTHTIM Death Time Time of death for any subject who died. What [is/was] the subject's time of death? Death Time Char DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 47 DTHHR Death Hour Hour of death for any subject who died. What [is/was] the subject's hour of death? Hour of Death Num DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).
Timing N/A 48 DTHMI Death Minute Minute of death for any subject who died. What [is/was] the subject's minute of death? Minute of Death Num DM.DTHDTC This field does not map directly to an SDTM variable. For the SDTM dataset, concatenate all collected CDASH DATE and TIME components and populate the SDTM variable DM.DTHDTC in ISO 8601 format. N/A The CDASH model defines Death Date as a timing variable. It is not included as a timing variable in the SDTMIG. It may be collected on any CRF deemed appropriate by the Sponsor. The SDTM variable DTHDTC and DTHFL are mapped to the DM domain 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).

Appendix A: 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.

Note: The CDISC Intellectual Property Policy can be found at: cdisc_policy_003_intellectual_property_v201408.pdf.