CDASH Model 1.1 scraping for specifications

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,Seq. for Order
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.,1
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.",2
Interventions,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.",3
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.",4
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.",5
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.",6
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.",7
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/Consumed],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.",8
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/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 Intervention was not assessed. If 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 negative response can be collected as ""N"" and mapped to the --STAT variable in SDTM as ""NOT DONE"". \n --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? \n",9
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/Available],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.,10
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/Evaluated/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.",11
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.",12
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.",13
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.",14
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.",15
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,16
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.",17
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.,18
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.",19
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,20
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.",21
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.",22
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.,23
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.",24
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.,25
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,26
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,27
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.,28
Interventions,N/A,29,--TRTV,Treatment Vehicle,"The vehicle for administration of treatment, such as a liquid in which the treatment drug is dissolved.",What [is/was] the vehicle for administration of the [--TRT]?,Treatment Vehicle,Char,--TRTV,Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".,N/A,N/A,29
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.,30
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.,31
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.,32
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.",33
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.",34
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.",35
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"".",36
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"".",37
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.,38
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.",39
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.,40
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.,41
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.,42
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.",43
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.",44
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.,45
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.",46
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.",47
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.",48
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.",49
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.",50
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.",51
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.",52
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.",53
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/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 = "--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.",54
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/pharmacological 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.",55
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.",56
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.",57
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.,58
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.",59
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.",60
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.",61
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.",62
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.",63
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.",64
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.",65
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.",66
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.",67
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).",1
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.",2
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.",3
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.",4
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.",5
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.",6
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.)",7
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?",8
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.",9
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.",10
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.",11
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.,12
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.",13
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.,14
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).",15
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.,16
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).",17
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.",18
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,19
Events,N/A,20,--ACNOTH,Other Action Taken,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,20
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.",21
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.",22
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.,23
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.,24
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.,25
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,26
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)""",27
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.,28
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.",29
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.",30
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.",31
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.",32
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.",33
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.,34
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.,35
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.,36
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.,37
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.,38
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.,39
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.,40
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.,41
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.,42
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.,43
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.",1
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.",2
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"".",3
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.",4
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/assessment])?,[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.",5
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/assessment] 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.",6
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/assessment/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.",7
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/assessment/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.",8
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/assessment])?,([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.",9
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/assessment])?,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.",10
Findings,N/A,10,--CRESU,Collected Non-Standard Unit,The unit of the result if it were collected as a non-standard unit.,What [is/was] the unit (of the [measurement/test/examination/question/assessment])?,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.",11
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",12
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/assessment])?; [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.",13
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",14
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/assessment])?,[--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.,15
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/assessment])?,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.,16
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/assessment])?,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.,17
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/assessment])?,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.,18
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.",19
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.,20
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.",21
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.,22
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,23
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,24
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.,25
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).",26
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,27
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/assessment/specimen collection/sample collection]?; What was the position of the subject (during the [measurement/test/examination/question/assessment/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.,28
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/assessment])?; 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.",29
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/assessment])?,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.,30
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/assessment])?,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.",31
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).",32
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/assessment])?,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.,33
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/assessment])?; What was the method (used to [measure/test/examine/question/assess/evaluate/identify] 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.,34
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/assessment])?,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.,35
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/assessment])?,Consciousness State,Char,--CSTATE,Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".,N/A,N/A,36
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,37
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.",38
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,39
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.,40
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.",41
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.",42
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,43
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,44
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.,45
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.,46
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,47
Findings,N/A,47,--CLSIG,Clinical Significance,An indication whether the test results were clinically significant.,[Is/Was] the ([measurement/test/examination/question/assessment]) 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,48
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/assessment])?,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.",49
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.",50
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.",51
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.",52
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.,53
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.",54
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.",1
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,2
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,3
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,4
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,5
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,6
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,7
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,8
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,9
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,10
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,11
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,12
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,13
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,14
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,15
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,16
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,17
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,18
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.",19
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"").",20
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.",21
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.",22
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).",23
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)",24
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).",25
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.",26
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.",27
Domain Specific,AE,1,AEACNOYN,Any Other Actions Taken,An indication whether any other action(s) were taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatments given because of this adverse event.,Were any other actions taken in response to this adverse event?,Any Other Actions Taken,Char,N/A,Does not map to an SDTM variable. The SDTM Annotated CRF is annotated to indicate that this field is NOT SUBMITTED.,(NY),The intent/purpose of collecting this field is to help with data cleaning and monitoring. It provides verification that the AEACNOTH field on the CRF was deliberately left blank.,1
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.,2
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"".",3
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"".",4
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"".",5
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"".",6
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"".",7
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.",8
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.",9
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"".",10
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"".",11
Domain Specific,AE,12,AESOD,Occurred with Overdose,An indication the serious event occurred with an overdose.,Did the adverse event occur with an overdose?,Overdose,Char,AESOD,Maps directly to the SDTM variable listed in the column with the heading "SDTM Target".,(NY),"Although deprecated, this variable is included for illustrative purposes if the sponsor is continuing to collect legacy data. If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate Yes/No variable. Note for sponsors: The FDA Study Data Technical Conformance Guide v2.2 (June 12, 2015) Section 4.1.1.3 states ""The entry of a ""Y"" for the serious adverse event variable, AESER, should have the assessment indicated, (e.g., as a death, hospitalization, or disability/permanent damage). Frequently, sponsors omit the assessment information, even when it has been collected on the CRF. The criteria that led to the determination should be provided. This information is critical during FDA review to support the characterization of serious AEs"".",12
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.",13
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,14
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.",15
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.",16
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.",17
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,18
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,19
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.,20
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.",1
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.,2
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.",3
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.",4
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.,5
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.",6
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.",7
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.",8
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.,9
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.,10
Identifiers,N/A,11,--LNKGRP,Link Group ID,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.,11
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,12
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?",13
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?",14
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?",15
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?,16
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.",17
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.",1
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.",2
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.",3
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.",4
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.,5
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.,6
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.",7
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",8
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)",9
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)",10
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)",11
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)",12
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)",13
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)",14
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)",15
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)",16
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)",17
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)",18
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)",19
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)",20
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)",21
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)",22
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 \n,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)",23
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)",24
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)",25
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)",26
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)",27
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)",28
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)",29
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)",30
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)",31
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.,32
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.,33
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]?,[Taken/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.",34
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.",35
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",36
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.",37
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.,38
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.,39
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.",40
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.",41
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).",42
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).",43
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).",44
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).",45
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).",46
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).",47
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).",48