Clinical Data Acquisition Standards Harmonization Model

Version 1.0

Prepared by the CDISC CDASH Team

Notes to Readers

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

Revision History

Date	Version
2017-09-20	1.0 Final

1 Introduction

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

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

Sponsors may implement any CDASH variable defined by a Class within one of its respective CDASHIG domains. Any variable found in a data class in the CDASH Model may be implemented in any CDASHIG domain within that class. For example, the Interventions class variable --ROUTE, although not defined in the Substance Use (SU) domain, may be added to SU if needed. The domain-specific section of the CDASH Model defines variables that may not be reused across multiple Domains for a given Class.

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

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

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

2 The CDASH Model

2.1 Interventions

Interventions

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

2.2 Events

Events

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

2.3 Findings

Findings

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

2.4 Identifiers

Identifiers

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

2.5 Timing

Timing

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

2.6 Special Purpose

Special Purpose

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

2.7 Domain-Specific

Domain-Specific

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

Appendices

Appendix A: Representations and Warranties, Limitations of Liability, and Disclaimers

CDISC Patent Disclaimers

It is possible that implementation of and compliance with this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any claim or of any patent rights in connection therewith. CDISC, including the CDISC Board of Directors, shall not be responsible for identifying patent claims for which a license may be required in order to implement this standard or for conducting inquiries into the legal validity or scope of those patents or patent claims that are brought to its attention.

Representations and Warranties

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

Each Participant in the development of this standard shall be deemed to represent, warrant, and covenant, at the time of a Contribution by such Participant (or by its Representative), that to the best of its knowledge and ability: (a) it holds or has the right to grant all relevant licenses to any of its Contributions in all jurisdictions or territories in which it holds relevant intellectual property rights; (b) there are no limits to the Participant's ability to make the grants, acknowledgments, and agreements herein; and (c) the Contribution does not subject any Contribution, Draft Standard, Final Standard, or implementations thereof, in whole or in part, to licensing obligations with additional restrictions or requirements inconsistent with those set forth in this Policy, or that would require any such Contribution, Final Standard, or implementation, in whole or in part, to be either: (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works (other than as set forth in Section 4.2 of the CDISC Intellectual Property Policy ("the Policy")); or (iii) distributed at no charge, except as set forth in Sections 3, 5.1, and 4.2 of the Policy. If a Participant has knowledge that a Contribution made by any Participant or any other party may subject any Contribution, Draft Standard, Final Standard, or implementation, in whole or in part, to one or more of the licensing obligations listed in Section 9.3, such Participant shall give prompt notice of the same to the CDISC President who shall promptly notify all Participants.

No Other Warranties/Disclaimers. ALL PARTICIPANTS ACKNOWLEDGE THAT, EXCEPT AS PROVIDED UNDER SECTION 9.3 OF THE CDISC INTELLECTUAL PROPERTY POLICY, ALL DRAFT STANDARDS AND FINAL STANDARDS, AND ALL CONTRIBUTIONS TO FINAL STANDARDS AND DRAFT STANDARDS, ARE PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, AND THE PARTICIPANTS, REPRESENTATIVES, THE CDISC PRESIDENT, THE CDISC BOARD OF DIRECTORS, AND CDISC EXPRESSLY DISCLAIM ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR OR INTENDED PURPOSE, OR ANY OTHER WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, FINAL STANDARDS OR DRAFT STANDARDS, OR CONTRIBUTION.

Limitation of Liability

IN NO EVENT WILL CDISC OR ANY OF ITS CONSTITUENT PARTS (INCLUDING, BUT NOT LIMITED TO, THE CDISC BOARD OF DIRECTORS, THE CDISC PRESIDENT, CDISC STAFF, AND CDISC MEMBERS) BE LIABLE TO ANY OTHER PERSON OR ENTITY FOR ANY LOSS OF PROFITS, LOSS OF USE, DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS POLICY OR ANY RELATED AGREEMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

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

CDASH Model v1.0